From nobody Sun May 1 00:54:12 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2265412B048 for ; Sun, 1 May 2016 00:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0_4xv1cQQ5_H for ; Sun, 1 May 2016 00:54:08 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.95]) (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 0C00612B00A for ; Sun, 1 May 2016 00:54:07 -0700 (PDT) Received: from [79.218.84.141] (helo=[192.168.71.101]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from ) id 1awmCb-0003e5-3G; Sun, 01 May 2016 09:54:05 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-393D196C-A53E-44A4-BC31-B664DD62032A Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (13E238) In-Reply-To: Date: Sun, 1 May 2016 09:54:04 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <571B60BA.8090301@lodderstedt.net> <49355f12-ef58-0637-47e0-7acd54e882d9@lodderstedt.net> To: Nat Sakimura X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2016 07:54:11 -0000 --Apple-Mail-393D196C-A53E-44A4-BC31-B664DD62032A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Nat, please explain the attack. I assume the attacker would need to control netwo= rk transmission or client device. kind regards, Torsten. > Am 01.05.2016 um 07:36 schrieb Nat Sakimura : >=20 > It actually depends on what risk level the transaction is at. For low risk= transactions, just having separate redirection endpoint may be adequate. On= the other hand, I can easily think of an attack that replaces iss on the au= thz response making the control invalid posing questions on whether it is wo= rth introducing it.=20 >> On Sun, May 1, 2016 at 14:21 Justin Richer wrote: >> I agree that we=E2=80=99re getting dangerously close to recommending sign= ed assertions at every step of the process, thereby bypassing HTTP. This was= the same mistake that WS-* and SOAP made, let=E2=80=99s not repeat it if we= can. >>=20 >> =E2=80=94 Justin >>=20 >>> On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt wrote: >>>=20 >>> Hi Nat, >>>=20 >>> sure, one could also authenticate and cryptographically protect the redi= rect response. Leveraging OIDC concepts is an idea worth considering but the= y should be adopted to the OAuth philosophy. The id token as used in the hyb= rid flows mixes an identity assertion with elements of transport security me= asures. A OAuth AS does not provide identity data to clients, so we only nee= d the transport security part.=20 >>> I personally would prefer a OAuth response object (similar to request ob= ject you have proposed) over the id token. Such a response object could cont= ain (and directly protect) state, code and other response values. I consider= this the more elegant design and it is easier to implement then having deta= ched signatures over hash values of codes or access tokens. Moreover, it wou= ld allow to encrypt the response as well.=20 >>> Generally, our threat analysis so far does not have provided justificati= on for cryptographically protected redirect responses. All proposals current= ly on the table stop mix up and code injection using simpler mechanisms.=20 >>> I think OAuth 2.0 is a huge success due to its balance of versatility, s= ecurity and _simplicity_. We definitely need to keep it secure, but we shoul= d also keep it as simple as possible. >>> kind regards, >>> Torsten. >>>> Am 29.04.2016 um 10:08 schrieb Nat Sakimura: >>>> As I look at it more and more, it started to look like the problem of a= ccepting tainted values without message authentication. To fix the root caus= e, we would have to authenticate response. ID Token was designed to also ser= ve as a solution anticipating it.=20 >>>>=20 >>>> Any concrete ideas?=20 >>>>=20 >>>>> On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt wrote: >>>>> Hi all, >>>>>=20 >>>>> discussion about Mix-Up and CnP seems to have stopped after the sessio= n >>>>> in BA - at least in the OAuth WG. There is a discussion about >>>>> mitigations in OpenId Connect going on at the OpenId Connect mailing l= ist. >>>>>=20 >>>>> I'm very much interested to find a solution within the OAuth realm as >>>>> I'm not interested to either implement two solutions (for OpenId Conne= ct >>>>> and OAuth) or adopt a OpenId-specific solution to OAuth (use id! token= s >>>>> in the front channel). I therefore would like to see progress and >>>>> propose to continue the discussion regarding mitigations for both thre= ats. >>>>>=20 >>>>> https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00 >>>>> proposes reasonable mitigations for both attacks. There are alternativ= es >>>>> as well: >>>>> - mix up: >>>>> -- AS specific redirect uris >>>>> -- Meta data/turi >>>>> (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5) >>>>> - CnP: >>>>> -- use of the nonce parameter (as a distinct mitigation beside state f= or >>>>> counter XSRF) >>>>>=20 >>>>> Anyone having an opinion? >>>>>=20 >>>>> best regards, >>>>> Torsten. >>>>>=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-393D196C-A53E-44A4-BC31-B664DD62032A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Nat,

please explain the attack. I assume the attacker would need to control= network transmission or client device.

kind regard= s,
Torsten.

Am 01.05.2016 um 07:36 schrieb Nat Sakim= ura <sakimura@gmail.com>:
It actually depends on what risk l= evel the transaction is at. For low risk transactions, just having separate r= edirection endpoint may be adequate. On the other hand, I can easily think o= f an attack that replaces iss on the authz response making the control inval= id posing questions on whether it is worth introducing it.
On Sun, May 1, 2016 at 14:21 Justin Richer &l= t;jricher@mit.edu> wrote:
I agree t= hat we=E2=80=99re getting dangerously close to recommending signed assertion= s at every step of the process, thereby bypassing HTTP. This was the same mi= stake that WS-* and SOAP made, let=E2=80=99s not repeat it if we can.
<= div style=3D"word-wrap:break-word">

 =E2=80=94 Justi= n

On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt <torsten@lodderstedt= .net> wrote:

=20

Hi Nat,

sure, one could= also authenticate and cryptographically protect the redirect response. Leveraging OIDC concepts is an idea worth considering but they should be adopted to the OAuth philosophy. The id token as used in the hybrid flows mixes an identity assertion with elements of transport security measures. A OAuth AS does not provide identity data to clients, so we only need the transport security part.

I personally would prefer a OAuth response object (similar to request object you have proposed) over the id token. Such a response object could contain (and directly protect) state, code and other response values. I consider this the more elegant design and it is easier to implement then having detached signatures over hash values of codes or access tokens. Moreover, it would allow to encrypt the response as well.

Generally, our threat analysis so far does not have provided justification for cryptographically protected redirect responses. All proposals currently on the table stop mix up and code injection using simpler mechanisms.

I think OAuth 2.0 is a huge success due to its balance of versatility, security and _simplicity_. We definitely need to keep it secure, but we should also keep it as simple as possible.

kind regards,
Torsten.

Am 29.04.2016 um 10:08 schrieb Nat Sakimura:
As I look at it more and more, it started to l= ook like the problem of accepting tainted values without message authentication. To fix the root cause, we would have to authenticate response. ID Token was designed to also serve as a solution anticipating it.

Any concrete ideas?

On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt <t= orsten@lodderstedt.net> wrote:
Hi all,

discussion about Mix-Up and CnP seems to have stopped after the session
in BA - at least in the OAuth WG. There is a discussion about
mitigations in OpenId Connect going on at the OpenId Connect mailing list.

I'm very much interested to find a solution within the OAuth realm as
I'm not interested to either implement two solutions (for OpenId Connect
and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens
in the front channel). I therefore would like to see progress and
propose to continue the discussion regarding mitigations for both threats.

https://tools.ietf.org/html= /draft-ietf-oauth-mix-up-mitigation-00
proposes reasonable mitigations for both attacks. There are alternatives
as well:
- mix up:
-- AS specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/ht= ml/draft-sakimura-oauth-meta-07#section-5)
- CnP:
-- use of the nonce parameter (as a distinct mitigation beside state for
counter XSRF)

Anyone having an opinion?

best regards,
Torsten.

_______________________________________________
OAuth mailing 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-393D196C-A53E-44A4-BC31-B664DD62032A-- From nobody Sun May 1 19:08:22 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B536412B05E for ; Sun, 1 May 2016 19:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-hVZMQyybhs for ; Sun, 1 May 2016 19:08:18 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A82012B05B for ; Sun, 1 May 2016 19:08:18 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id k142so175674493oib.1 for ; Sun, 01 May 2016 19:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SRCATVNdlK3KSQia5BvHN+S8NSkGreOyfUZaVKnwVZ8=; b=RVmO0lAZpd/eaJIkNdCl7S9T9VGn/j/lIjGugKQ9O9e13uEGTEayiN4WdPAsm37Ucz t40RRNYw+WiWXPRMAZzwiKEivmO3mUNX9q/nBi4yOAtvCCq9VRdiizDiCmtsWv5qLZNT mWXp9L3etCAk6skU0EyJSb0wbWOrcWTIdQnA/xcjc2nwtDAM8kRfCOxY5QQ1rfwh0gfx q4PjE1DLDr8wUI/kWQ49f2CiL/Q3edeD/Ylal8eCyBuko1WvS5eMxRdjje/cVozplTSt yjwqdCrWkyQ7asJFPaQI1HRWUYvHssuuV9lXanUi94W5/3XIJ31V8X1cGqtJYVBFYeBr EOEQ== 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; bh=SRCATVNdlK3KSQia5BvHN+S8NSkGreOyfUZaVKnwVZ8=; b=UxedIGIcyXfP4k6PytpF1nMhg4lry0c09GGXgHsy7H5W2wQ1YS9CPCNzfuL6cidg7A vGNu5+LN12nW61hc3tPuqibDLB0m5z7INY7cDZEtGIpjccm2RZbfz2BHiLw6VJ0UQwuC mg0OMVZfDl/sZyMUVAa/2uh5SMgR2ot/NQ/TdgIRb4tfdBu9TWBdNNhnZN7QXadk36NS AVWWcL/LuMByY7ZXib0og+dCetWr5JlYKJD4xuNkwjhxZ1Wrvx4zL7NSLri1q8KgQtzm Kc3Aig90jZcDhoMfwd3jCkHYCZhuNPfn8fFAsjIvo28s97KGVGEdZEID4cHwpCh4Kbh2 DRmA== X-Gm-Message-State: AOPr4FXEW1Sq1zODrcq24rzlFxMvrfYAB7hjyu1LO+9SZ3IMmVKbvyxBRQrzsz2+zQg1a43u0b/kB0YdVSIQ9zTU X-Received: by 10.202.104.213 with SMTP id o82mr12490935oik.165.1462154897210; Sun, 01 May 2016 19:08:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.179.42 with HTTP; Sun, 1 May 2016 19:07:57 -0700 (PDT) In-Reply-To: References: <571B60BA.8090301@lodderstedt.net> <49355f12-ef58-0637-47e0-7acd54e882d9@lodderstedt.net> From: William Denniss Date: Sun, 1 May 2016 19:07:57 -0700 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a1140a3d041a2ca0531d277c8 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 02:08:20 -0000 --001a1140a3d041a2ca0531d277c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm inclined to think that Nat's comment is right: "As I look at it more and more, it started to look like the problem of accepting tainted values without message authentication. To fix the root cause, we would have to authenticate response. ID Token was designed to also serve as a solution anticipating it." Even if we workaround the current issue with more unbound plain text params, will it solve the *next* issue? Personally I'm not convinced. I also wonder at what level of risk is the right solution "code id_token", which the researchers note *will* mitigate the attacks (when implemented correctly). If we absolutely must solve this without "id_token", I know John has a few ideas for lightweight binding of the request & response by hashing the request URL and some config. I wonder if a "lightweight crypto" approach is superior to "more unbound params" as the best non-id_token option. On Sat, Apr 30, 2016 at 10:36 PM, Nat Sakimura wrote: > It actually depends on what risk level the transaction is at. For low ris= k > transactions, just having separate redirection endpoint may be adequate. = On > the other hand, I can easily think of an attack that replaces iss on the > authz response making the control invalid posing questions on whether it = is > worth introducing it. > On Sun, May 1, 2016 at 14:21 Justin Richer wrote: > >> I agree that we=E2=80=99re getting dangerously close to recommending sig= ned >> assertions at every step of the process, thereby bypassing HTTP. This wa= s >> the same mistake that WS-* and SOAP made, let=E2=80=99s not repeat it if= we can. >> >> =E2=80=94 Justin >> >> On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >> Hi Nat, >> >> sure, one could also authenticate and cryptographically protect the >> redirect response. Leveraging OIDC concepts is an idea worth considering >> but they should be adopted to the OAuth philosophy. The id token as used= in >> the hybrid flows mixes an identity assertion with elements of transport >> security measures. A OAuth AS does not provide identity data to clients,= so >> we only need the transport security part. >> >> I personally would prefer a OAuth response object (similar to request >> object you have proposed) over the id token. Such a response object coul= d >> contain (and directly protect) state, code and other response values. I >> consider this the more elegant design and it is easier to implement then >> having detached signatures over hash values of codes or access tokens. >> Moreover, it would allow to encrypt the response as well. >> >> Generally, our threat analysis so far does not have provided >> justification for cryptographically protected redirect responses. All >> proposals currently on the table stop mix up and code injection using >> simpler mechanisms. >> >> I think OAuth 2.0 is a huge success due to its balance of versatility, >> security and _simplicity_. We definitely need to keep it secure, but we >> should also keep it as simple as possible. >> >> kind regards, >> Torsten. >> Am 29.04.2016 um 10:08 schrieb Nat Sakimura: >> >> As I look at it more and more, it started to look like the problem of >> accepting tainted values without message authentication. To fix the root >> cause, we would have to authenticate response. ID Token was designed to >> also serve as a solution anticipating it. >> >> Any concrete ideas? >> >> On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> Hi all, >>> >>> discussion about Mix-Up and CnP seems to have stopped after the session >>> in BA - at least in the OAuth WG. There is a discussion about >>> mitigations in OpenId Connect going on at the OpenId Connect mailing >>> list. >>> >>> I'm very much interested to find a solution within the OAuth realm as >>> I'm not interested to either implement two solutions (for OpenId Connec= t >>> and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens >>> in the front channel). I therefore would like to see progress and >>> propose to continue the discussion regarding mitigations for both >>> threats. >>> >>> https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00 >>> proposes reasonable mitigations for both attacks. There are alternative= s >>> as well: >>> - mix up: >>> -- AS specific redirect uris >>> -- Meta data/turi >>> (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5) >>> - CnP: >>> -- use of the nonce parameter (as a distinct mitigation beside state fo= r >>> counter XSRF) >>> >>> Anyone having an opinion? >>> >>> best regards, >>> Torsten. >>> >>> _______________________________________________ >>> OAuth mailing 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 > > --001a1140a3d041a2ca0531d277c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm inclined to think that Nat's comment is r= ight: "As I look at it more and more,= it started to look like the problem of accepting tainted values without me= ssage authentication. To fix the root cause, we would have to authenticate = response. ID Token was designed to also serve as a solution anticipating it= ."

Even if we workaround the current= issue with more unbound plain text params, will it solve the next i= ssue?=C2=A0 Personally I'm not convinced.

I also wonder at what level of risk is the right solution "code id_t= oken", which the researchers note will mitigate the attacks (wh= en implemented correctly).

If we=C2=A0absolut= ely=C2=A0must solve this without "id_token", I know=C2=A0John has= a few ideas for lightweight binding of the request & response by hashi= ng the request URL and some config. I wonder if a "lightweight crypto&= quot; approach is superior to "more unbound params" as the best n= on-id_token option.

On Sat, Apr 30, 2016 at 10:36 PM, Nat Sakimura <saki= mura@gmail.com> wrote:
It a= ctually depends on what risk level the transaction is at. For low risk tran= sactions, just having separate redirection endpoint may be adequate. On the= other hand, I can easily think of an attack that replaces iss on the authz= response making the control invalid posing questions on whether it is wort= h introducing it.
On Sun, May 1, 2016 at 14:21 Justin Richer &= lt;jricher@mit.edu= > wrote:
I agree that we=E2=80=99re getting dangerously close to recomm= ending signed assertions at every step of the process, thereby bypassing HT= TP. This was the same mistake that WS-* and SOAP made, let=E2=80=99s not re= peat it if we can.

=
=C2=A0=E2=80=94 Justin
=

On Apr 30, 2016, at 10:57 AM, = Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

=20

Hi Nat,

sure, one coul= d also authenticate and cryptographically protect the redirect response. Leveraging OIDC concepts is an idea worth considering but they should be adopted to the OAuth philosophy. The id token as used in the hybrid flows mixes an identity assertion with elements of transport security measures. A OAuth AS does not provide identity data to clients, so we only need the transport security part.

I personally would prefer a OAuth response object (similar to request object you have proposed) over the id token. Such a response object could contain (and directly protect) state, code and other response values. I consider this the more elegant design and it is easier to implement then having detached signatures over hash values of codes or access tokens. Moreover, it would allow to encrypt the response as well.

Generally, our threat analysis so far does not have provided justification for cryptographically protected redirect responses. All proposals currently on the table stop mix up and code injection using simpler mechanisms.

I think OAuth 2.0 is a huge success due to its balance of versatility, security and _simplicity_. We definitely need to keep it secure, but we should also keep it as simple as possible.

kind regards,
Torsten.

Am 29.04.2016 um 10:08 schrieb Nat Sakimura:
As I look at it more and more, it started to = look like the problem of accepting tainted values without message authentication. To fix the root cause, we would have to authenticate response. ID Token was designed to also serve as a solution anticipating it.

Any concrete ideas?

On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt <= torsten@lodderstedt.net> wrote:
Hi all,

discussion about Mix-Up and CnP seems to have stopped after the session
in BA - at least in the OAuth WG. There is a discussion about
mitigations in OpenId Connect going on at the OpenId Connect mailing list.

I'm very much interested to find a solution within the OAuth realm as
I'm not interested to either implement two solutions (for OpenId Connect
and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens
in the front channel). I therefore would like to see progress and
propose to continue the discussion regarding mitigations for both threats.

https://tools.ietf.org/ht= ml/draft-ietf-oauth-mix-up-mitigation-00
proposes reasonable mitigations for both attacks. There are alternatives
as well:
- mix up:
-- AS specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/= html/draft-sakimura-oauth-meta-07#section-5)
- CnP:
-- use of the nonce parameter (as a distinct mitigation beside state for
counter XSRF)

Anyone having an opinion?

best regards,
Torsten.

_______________________________________________
OAuth mailing list
OAuth@ietf.or= g
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


--001a1140a3d041a2ca0531d277c8-- From nobody Sun May 1 23:11:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9F512D0F5 for ; Sun, 1 May 2016 23:11:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpBn9r_cQ4RS for ; Sun, 1 May 2016 23:11:48 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF4412B062 for ; Sun, 1 May 2016 23:11:47 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id a17so125796147wme.0 for ; Sun, 01 May 2016 23:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=Qy1QE6Mc/0bqaVBdYV5fmEVJ4jlctEuRRMW/CaB22hU=; b=fFmkT04dn649o/YbyDb+tDkdHJ0/pa0ShcZHZXrzwm/hc9iRzj2FImSNAV2H9+72mD MnQ0Rv/4aazHUyd8nctZAt8bsQjP23esV3q113d+Y2RtfJBVWSVAi6u+0uyC3fNqS+w7 PYoXqrUM21rXsDCvLN9KzNgwHcNDLN1v22JrVRQM6fGgLjO30X08xxy2enJCcVhyIhls WvNtJoX7yPOe9VE6YsBO4ZXPM6U/xL6bg5pGJlW9vBYvV+si71QsK3nrWOn5Dy/Pv6xB OSEGlQrily+8P9UFoMb1qglCICvlrrcNIAG6pIhJVP5cJKMHQeXXNcRBuPzJO32nYuyE UHMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=Qy1QE6Mc/0bqaVBdYV5fmEVJ4jlctEuRRMW/CaB22hU=; b=YQVbFuSNQTr0l5ErMNXthxgbYuBBN9La4Jr08h09jnncwhmvqylA8LQ1MnLzJ67X4s sNJfjcDhG882x7nzvjZs26E22heqUaIM0PyY8oAQkpBNPwBaphRtBR8JaC3Rb+9Z64km mZQxNtFp/nbW36CX7B1eNJS83XB9I/603Czfyukq5nMC9bw7uHUDfK/qfcSO319b7Um7 zwxUmc3HaMdMFebMaNDOIYm0cMqegrp/P1UlUxFoQd9Qxlg5p98/WK+5Lk6ci2YcsMaM HSn95+PKFCe0PH/WtikjzcvUwZ0x79KE0+q+1bS3jAX5+tM7D0cc04v2CA96Lanc1aOC grUw== X-Gm-Message-State: AOPr4FUX0NdFlTN2C45YFrr2TRr3uEABGoZS4LEFkDe3r8vvpTmKHuX1vPWGBfCclnB+pw== X-Received: by 10.194.63.226 with SMTP id j2mr34314696wjs.27.1462169506102; Sun, 01 May 2016 23:11:46 -0700 (PDT) Received: from dombp.fritz.box (HSI-KBW-078-042-013-158.hsi3.kabel-badenwuerttemberg.de. [78.42.13.158]) by smtp.gmail.com with ESMTPSA id us3sm28465057wjc.41.2016.05.01.23.11.44 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 May 2016 23:11:44 -0700 (PDT) Date: Mon, 2 May 2016 08:11:45 +0200 From: Dominick Baier To: William Denniss , Nat Sakimura Message-ID: In-Reply-To: References: <571B60BA.8090301@lodderstedt.net> <49355f12-ef58-0637-47e0-7acd54e882d9@lodderstedt.net> X-Mailer: Airmail (351) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5726efa1_6f5db174_2bb" Archived-At: Cc: "=?utf-8?Q??=" Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 06:11:50 -0000 --5726efa1_6f5db174_2bb Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The id=5Ftoken is a validatable protocol response - OAuth on its own cann= ot provide this and i doubt it is worth teaching teaching it new tricks.=C2= =A0 I personally have moved on to always add id=5Ftoken as a response type - = together with OIDC discovery, in my mind OIDC is a superset of OAuth and = I always use them together - or put differently - I recommend against usi= ng OAuth on its own without OIDC (besides client=5Fcreds/extension grants= scenarios of course). =E2=80=94=C2=A0 cheers Dominick Baier On 2 May 2016 at 04:08:25, William Denniss (wdenniss=40google.com) wrote:= I'm inclined to think that Nat's comment is right: =22As I look at it mor= e and more, it started to look like the problem of accepting tainted valu= es without message authentication. To fix the root cause, we would have t= o authenticate response. ID Token was designed to also serve as a solutio= n anticipating it.=22 Even if we workaround the current issue with more unbound plain text para= ms, will it solve the next issue=3F=C2=A0 Personally I'm not convinced. I also wonder at what level of risk is the right solution =22code id=5Fto= ken=22, which the researchers note will mitigate the attacks (when implem= ented correctly). If we=C2=A0absolutely=C2=A0must solve this without =22id=5Ftoken=22, I kn= ow=C2=A0John has a few ideas for lightweight binding of the request & res= ponse by hashing the request URL and some config. I wonder if a =22lightw= eight crypto=22 approach is superior to =22more unbound params=22 as the = best non-id=5Ftoken option. On Sat, Apr 30, 2016 at 10:36 PM, Nat Sakimura wro= te: It actually depends on what risk level the transaction is at. =46or low r= isk transactions, just having separate redirection endpoint may be adequa= te. On the other hand, I can easily think of an attack that replaces iss = on the authz response making the control invalid posing questions on whet= her it is worth introducing it. On Sun, May 1, 2016 at 14:21 Justin Richer wrote: I agree that we=E2=80=99re getting dangerously close to recommending sign= ed assertions at every step of the process, thereby bypassing HTTP. This = was the same mistake that WS-* and SOAP made, let=E2=80=99s not repeat it= if we can. =C2=A0=E2=80=94 Justin On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt wrote: Hi Nat, sure, one could also authenticate and cryptographically protect the redir= ect response. Leveraging OIDC concepts is an idea worth considering but t= hey should be adopted to the OAuth philosophy. The id token as used in th= e hybrid flows mixes an identity assertion with elements of transport sec= urity measures. A OAuth AS does not provide identity data to clients, so = we only need the transport security part. I personally would prefer a OAuth response object (similar to request obj= ect you have proposed) over the id token. Such a response object could co= ntain (and directly protect) state, code and other response values. I con= sider this the more elegant design and it is easier to implement then hav= ing detached signatures over hash values of codes or access tokens. Moreo= ver, it would allow to encrypt the response as well. Generally, our threat analysis so far does not have provided justificatio= n for cryptographically protected redirect responses. All proposals curre= ntly on the table stop mix up and code injection using simpler mechanisms= . I think OAuth 2.0 is a huge success due to its balance of versatility, se= curity and =5Fsimplicity=5F. We definitely need to keep it secure, but we= should also keep it as simple as possible. kind regards, Torsten. Am 29.04.2016 um 10:08 schrieb Nat Sakimura: As I look at it more and more, it started to look like the problem of acc= epting tainted values without message authentication. To fix the root cau= se, we would have to authenticate response. ID Token was designed to also= serve as a solution anticipating it. Any concrete ideas=3F On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt wrote: Hi all, discussion about Mix-Up and CnP seems to have stopped after the session in BA - at least in the OAuth WG. There is a discussion about mitigations in OpenId Connect going on at the OpenId Connect mailing list= . I'm very much interested to find a solution within the OAuth realm as I'm not interested to either implement two solutions (for OpenId Connect and OAuth) or adopt a OpenId-specific solution to OAuth (use id=21 tokens= in the front channel). I therefore would like to see progress and propose to continue the discussion regarding mitigations for both threats= . https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00 proposes reasonable mitigations for both attacks. There are alternatives as well: - mix up: -- AS specific redirect uris -- Meta data/turi (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07=23section-5) - CnP: -- use of the nonce parameter (as a distinct mitigation beside state for counter XSR=46) Anyone having an opinion=3F best regards, Torsten. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F OAuth mailing list OAuth=40ietf.org https://www.ietf.org/mailman/listinfo/oauth =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F OAuth mailing list OAuth=40ietf.org https://www.ietf.org/mailman/listinfo/oauth =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F OAuth mailing list OAuth=40ietf.org https://www.ietf.org/mailman/listinfo/oauth =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F =20 OAuth mailing list =20 OAuth=40ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 --5726efa1_6f5db174_2bb Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

I sat down with the two Microsoft teams that have im= plementations of the OAuth Device Flow and compared what they currently hav= e built to draft-ietf-oauth-device-flow.  Here’s some data that = we assembled…

 

One of the two implementations has an optional ̶= 0;message” parameter containing text that is to be shown to the user.=   This one also uses a “mkt” parameter to indicate the loc= ale of the message (as opposed to, for instance, ui_locales).  The developers want to know what the working group thinks of the possibili= ty of supporting some kind of a “message” parameter.=

 

The developers would like an example in the spec tha= t shows the use of simple polling.

 

We are using the “device_code” grant typ= e.  The token request is missing from the spec, including the grant ty= pe being missing from the spec.

 

One implementation adds two new errors: auth_pending= and expired_device_code.  (The spec uses authorization_pending.) = ; This implementation also uses the access_denied error defined by RFC 6749= .

 

The other uses authorization_pending, code_expired, = and authorization_declined.  The developers agreed that authorization_= declined should become access_denied.  That implementation hasn’= t implemented slow_down.

 

The developers wanted to ask what the right code exp= iration error code is.  They felt that invalid_grant may be a bit too = broad.

 

Our requests in both implementations do match the sp= ecification.

 

Our implementations currently use verification_url i= nstead of verification_uri.  This should be changed to verification_ur= i to match IETF naming practices.

 

Our default expires_in is 900 (15 minutes).  Ou= r default interval is 5 seconds.

 

Both implementations do intend to migrate to the syn= tax in the eventual final specification.

 

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

 

 

 

--_000_SN1PR0301MB16455DFD74EA565D1FB99A4EF57F0SN1PR0301MB1645_-- From nobody Sun May 8 20:43:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B090212D1BC for ; Sun, 8 May 2016 20:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5w3lMQ6K6ah for ; Sun, 8 May 2016 20:43:45 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A454C12B061 for ; Sun, 8 May 2016 20:43:44 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id f74so82777846qge.2 for ; Sun, 08 May 2016 20:43:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=baOUO903ot63e1vcyf7QP9HR60FAiacA37KDUUbIxTc=; b=NtWqhBSt+5xipvvNTn2VLGXonEOUe8G6ZNVzGorR2yxqJal0u490Z8A+E58CutiP31 7LrX+U6bo/6r+sogYQ/AcjaFSOQUGMIUjoAv2R+CR8xoZ1Ez61u92Hp9dPJTRym8M2Ns 6mXJZPBr7kVFdn2mAT/V3ZUz+y/y+ki9dq+6PVHUCA/HvwNQDBZkryJlDYaFe099SBVZ a5htkTBWoxFWMcjSfbVxp5J28AMivkwD4Oo7/LWUIE9OYW0oTTAxJ51e155hK7V3CUUN 3hCe/CsoAkmIjyGkTITv6OLctsnNkCFXdvxNtFla/B6qzDTykP3IFlvoh2BI8J55Tqlw /0pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=baOUO903ot63e1vcyf7QP9HR60FAiacA37KDUUbIxTc=; b=QjUxA2eDcofjyn+pPFIW8gJqdT115bEqcprzV5JYHaukE8Bv+LFkHkL4mYYwaJNlxW reh/Y+xZTF9P7YXb6eGbfzKsSm+mUNWfk21u3wuhXFcoVKnBldC6E7a5PYMDENWn4F+l n8Gq3/Lcdv/4OimtiocUdk2p8MfByj+iTwGud6+rUFSnzurDcRNFpNAqSLlLvLKzX/mx /invliRncNbEqVTqe61upsT5edEd0hkQe7A6I6u3J2zxHrjgjGhdDag6pidt/b0fq2vc /g/b5655HWHH6OEfQaMHF+np3yA7WCDYz2IODkDnPQSTtxd8vTgr40nmhJCm5eMQ2Uvm kmig== X-Gm-Message-State: AOPr4FW3PQlDPtg4SZ//fvLJFNyhaKTQ7lt4TDDzzQ0GrAgHrOPfJZif9VpNPcQ9Tfwn4k4xnceb0JeqeoFeqg== X-Received: by 10.140.21.164 with SMTP id 33mr32981099qgl.34.1462765423416; Sun, 08 May 2016 20:43:43 -0700 (PDT) MIME-Version: 1.0 References: <571B60BA.8090301@lodderstedt.net> <49355f12-ef58-0637-47e0-7acd54e882d9@lodderstedt.net> In-Reply-To: From: Nat Sakimura Date: Mon, 09 May 2016 03:43:34 +0000 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001a11c13aca73fb690532609de2 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 03:43:49 -0000 --001a11c13aca73fb690532609de2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, and unfortunately, that is a rather common attack these days. Infesting a user device with a malware is probably easier than having the client developer register its client to unknown server. 2016=E5=B9=B45=E6=9C=881=E6=97=A5(=E6=97=A5) 16:54 Torsten Lodderstedt : > Hi Nat, > > please explain the attack. I assume the attacker would need to control > network transmission or client device. > > kind regards, > Torsten. > > Am 01.05.2016 um 07:36 schrieb Nat Sakimura : > > It actually depends on what risk level the transaction is at. For low ris= k > transactions, just having separate redirection endpoint may be adequate. = On > the other hand, I can easily think of an attack that replaces iss on the > authz response making the control invalid posing questions on whether it = is > worth introducing it. > On Sun, May 1, 2016 at 14:21 Justin Richer wrote: > >> I agree that we=E2=80=99re getting dangerously close to recommending sig= ned >> assertions at every step of the process, thereby bypassing HTTP. This wa= s >> the same mistake that WS-* and SOAP made, let=E2=80=99s not repeat it if= we can. >> >> =E2=80=94 Justin >> >> On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >> Hi Nat, >> >> sure, one could also authenticate and cryptographically protect the >> redirect response. Leveraging OIDC concepts is an idea worth considering >> but they should be adopted to the OAuth philosophy. The id token as used= in >> the hybrid flows mixes an identity assertion with elements of transport >> security measures. A OAuth AS does not provide identity data to clients,= so >> we only need the transport security part. >> >> I personally would prefer a OAuth response object (similar to request >> object you have proposed) over the id token. Such a response object coul= d >> contain (and directly protect) state, code and other response values. I >> consider this the more elegant design and it is easier to implement then >> having detached signatures over hash values of codes or access tokens. >> Moreover, it would allow to encrypt the response as well. >> >> Generally, our threat analysis so far does not have provided >> justification for cryptographically protected redirect responses. All >> proposals currently on the table stop mix up and code injection using >> simpler mechanisms. >> >> I think OAuth 2.0 is a huge success due to its balance of versatility, >> security and _simplicity_. We definitely need to keep it secure, but we >> should also keep it as simple as possible. >> >> kind regards, >> Torsten. >> Am 29.04.2016 um 10:08 schrieb Nat Sakimura: >> >> As I look at it more and more, it started to look like the problem of >> accepting tainted values without message authentication. To fix the root >> cause, we would have to authenticate response. ID Token was designed to >> also serve as a solution anticipating it. >> >> Any concrete ideas? >> >> On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> Hi all, >>> >>> discussion about Mix-Up and CnP seems to have stopped after the session >>> in BA - at least in the OAuth WG. There is a discussion about >>> mitigations in OpenId Connect going on at the OpenId Connect mailing >>> list. >>> >>> I'm very much interested to find a solution within the OAuth realm as >>> I'm not interested to either implement two solutions (for OpenId Connec= t >>> and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens >>> in the front channel). I therefore would like to see progress and >>> propose to continue the discussion regarding mitigations for both >>> threats. >>> >>> https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00 >>> proposes reasonable mitigations for both attacks. There are alternative= s >>> as well: >>> - mix up: >>> -- AS specific redirect uris >>> -- Meta data/turi >>> (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5) >>> - CnP: >>> -- use of the nonce parameter (as a distinct mitigation beside state fo= r >>> counter XSRF) >>> >>> Anyone having an opinion? >>> >>> best regards, >>> Torsten. >>> >>> _______________________________________________ >>> OAuth mailing 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 Chairman of the Board, OpenID Foundation Trustee, Kantara Initiative --001a11c13aca73fb690532609de2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, and unfortunately, that is a rather common attack the= se days.=C2=A0
Infesting a user device with a malware is probably easie= r than having the client developer register its client to unknown server.= =C2=A0

2016=E5=B9= =B45=E6=9C=881=E6=97=A5(=E6=97=A5) 16:54 Torsten Lodderstedt <torsten@lodderstedt.net>:
=
Hi Nat,

please explain the attack. I assume the attacker wou= ld need to control network transmission or client device.

kind regards,
Torsten.
=
Am 01.05.2016 um 07:36 schrieb Nat Sakimura <sakimura@gmail.com>:

<= blockquote type=3D"cite">
It actually depends on what risk level the tr= ansaction is at. For low risk transactions, just having separate redirectio= n endpoint may be adequate. On the other hand, I can easily think of an att= ack that replaces iss on the authz response making the control invalid posi= ng questions on whether it is worth introducing it.
On Sun, May 1, 2016 at 14:21 Justin Richer <jricher@mit.edu> w= rote:
I agree that we=E2=80=99re getting dangerously close to recommending= signed assertions at every step of the process, thereby bypassing HTTP. Th= is was the same mistake that WS-* and SOAP made, let=E2=80=99s not repeat i= t if we can.

= =C2=A0=E2=80=94 Justin
=
On Apr 30, 2016, at 10:57 AM, Torst= en Lodderstedt <torsten@lodderstedt.net> wrote:

=20

Hi Nat,

sure, one coul= d also authenticate and cryptographically protect the redirect response. Leveraging OIDC concepts is an idea worth considering but they should be adopted to the OAuth philosophy. The id token as used in the hybrid flows mixes an identity assertion with elements of transport security measures. A OAuth AS does not provide identity data to clients, so we only need the transport security part.

I personally would prefer a OAuth response object (similar to request object you have proposed) over the id token. Such a response object could contain (and directly protect) state, code and other response values. I consider this the more elegant design and it is easier to implement then having detached signatures over hash values of codes or access tokens. Moreover, it would allow to encrypt the response as well.

Generally, our threat analysis so far does not have provided justification for cryptographically protected redirect responses. All proposals currently on the table stop mix up and code injection using simpler mechanisms.

I think OAuth 2.0 is a huge success due to its balance of versatility, security and _simplicity_. We definitely need to keep it secure, but we should also keep it as simple as possible.

kind regards,
Torsten.

Am 29.04.2016 um 10:08 schrieb Nat Sakimura:
As I look at it more and more, it started to = look like the problem of accepting tainted values without message authentication. To fix the root cause, we would have to authenticate response. ID Token was designed to also serve as a solution anticipating it.

Any concrete ideas?

On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt <= torsten@lodderstedt.net> wrote:
Hi all,

discussion about Mix-Up and CnP seems to have stopped after the session
in BA - at least in the OAuth WG. There is a discussion about
mitigations in OpenId Connect going on at the OpenId Connect mailing list.

I'm very much interested to find a solution within the OAuth realm as
I'm not interested to either implement two solutions (for OpenId Connect
and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens
in the front channel). I therefore would like to see progress and
propose to continue the discussion regarding mitigations for both threats.

https://tools.ietf.org/ht= ml/draft-ietf-oauth-mix-up-mitigation-00
proposes reasonable mitigations for both attacks. There are alternatives
as well:
- mix up:
-- AS specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/= html/draft-sakimura-oauth-meta-07#section-5)
- CnP:
-- use of the nonce parameter (as a distinct mitigation beside state for
counter XSRF)

Anyone having an opinion?

best regards,
Torsten.

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundatio= n
T= rustee, Kantara Initiative
--001a11c13aca73fb690532609de2-- From nobody Sun May 8 20:45:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4994112D1CA for ; Sun, 8 May 2016 20:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fa8Qhmh74izl for ; Sun, 8 May 2016 20:45:11 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409FC12D1BC for ; Sun, 8 May 2016 20:45:11 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id f74so82786541qge.2 for ; Sun, 08 May 2016 20:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Y0tbfp/+fDpxb5EogotSgM5p/A50fpL9HwFpRny6Fgc=; b=fFRqIKfjN2L1xFGcEMwDCy8p1GSje5MD6WDhiz/dlseBPTWF/0W4PFlalL3ixsZBgM WMltzgYCtZHQjV0qW5+3WQrc8KwE9Tvw1s6TkwLC8JNviDIlcFkyRuGEzK4MGDAMhMrl J/sQ16iWHiYYcAtnOdWNkuhL7d+nJ7vbpmlB+l5C3J8o4B246p3W3nQypF4IAf8TPLg0 JLmfwx13tiAw9R/ebGu2K6B/11o3Xj7B31ZJJ5BC1Cnfv737ZEJaPbvjJoAGG0lqfNqM R5h7gq0eiT1cd1wSQx+veyBLM4IH9uSaZzzwPLMfv/tsii4EQDg+KH+e2bzZImnHymZF jHsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Y0tbfp/+fDpxb5EogotSgM5p/A50fpL9HwFpRny6Fgc=; b=QQVagUEf6R883jPtITwDm6OYW8fZy4tg11zeLBGIVDPVDL2dPWPZClqhKwxXUafY2J +ziETUN7r7pnGU8WxDX7xBoijFHcWqU1WYmCdgtxmYkQVegXutaI1lZDwHmmKD1uLTf4 LZiP03BB6g/giLGsBGLtm0noCTf9hFwhbZneiIf+12WoudQTGr9H0RrFSlrU9hzoBRqu H+cAiFF60+OhOqsAh/EezMC/jDhVCjQCRR2AmDIpmjCNc278eGBlujL5Su7yMTiiX1wI zJD2h3hYJbXSzU9Q/ocE/jY1jX3ASohUXlkrjtDlP4K8T0492HglzpA7DoGcqV1EO1kJ dj1g== X-Gm-Message-State: AOPr4FV/bZvpzb6c/MkfYtul1lfd0/w2rdr1gvqBK0+KxPV06u1yy6XiOI/ZzeNrDysT2uoM6OeA4sEGHwzxRg== X-Received: by 10.140.221.210 with SMTP id r201mr33706894qhb.16.1462765510355; Sun, 08 May 2016 20:45:10 -0700 (PDT) MIME-Version: 1.0 References: <571B60BA.8090301@lodderstedt.net> <572B56BB.9080903@uni-trier.de> In-Reply-To: <572B56BB.9080903@uni-trier.de> From: Nat Sakimura Date: Mon, 09 May 2016 03:45:00 +0000 Message-ID: To: Daniel Fett , oauth@ietf.org Content-Type: multipart/alternative; boundary=001a1136ffd8a2785e053260a202 Archived-At: Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 03:45:14 -0000 --001a1136ffd8a2785e053260a202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Daniel, May I ask again why separate redirect uri would not work for mix-up? (I know, it does not work for cut-n-paste.) Thanks, Nat 2016=E5=B9=B45=E6=9C=885=E6=97=A5(=E6=9C=A8) 23:28 Daniel Fett : > Am 23.04.2016 um 13:47 schrieb Torsten Lodderstedt: > > I'm very much interested to find a solution within the OAuth realm as > > I'm not interested to either implement two solutions (for OpenId Connec= t > > and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens > > in the front channel). I therefore would like to see progress and > > propose to continue the discussion regarding mitigations for both > threats. > > > > https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00 > > proposes reasonable mitigations for both attacks. There are alternative= s > > as well: > > - mix up: > > -- AS specific redirect uris > > -- Meta data/turi > > (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5) > > - CnP: > > -- use of the nonce parameter (as a distinct mitigation beside state fo= r > > counter XSRF) > > >From our formal analysis of OAuth we are pretty confident that the > mitigation proposed in draft-ietf-oauth-mix-up-mitigation-00 should be > sufficient against the Mix-Up attack. > > Cheers, > Daniel > > > -- > Informationssicherheit und Kryptografie > Universit=C3=A4t Trier - Tel. 0651 201 2847 - H436 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura Chairman of the Board, OpenID Foundation Trustee, Kantara Initiative --001a1136ffd8a2785e053260a202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Daniel,=C2=A0

May I ask again why se= parate redirect uri would not work for mix-up?=C2=A0
(I know, it = does not work for cut-n-paste.)=C2=A0

Thanks,=C2= =A0

Nat

2016=E5=B9=B45=E6=9C=885=E6=97=A5(=E6=9C=A8) 23:28 Daniel Fett <= ;fett@uni-trier.de>:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Am 23.04.2016 um 13:47 schrieb Torsten Lodder= stedt:
> I'm very much interested to find a solution within the OAuth realm= as
> I'm not interested to either implement two solutions (for OpenId C= onnect
> and OAuth) or adopt a OpenId-specific solution to OAuth (use id! token= s
> in the front channel). I therefore would like to see progress and
> propose to continue the discussion regarding mitigations for both thre= ats.
>
> https://tools.ietf.org/html/dr= aft-ietf-oauth-mix-up-mitigation-00
> proposes reasonable mitigations for both attacks. There are alternativ= es
> as well:
> - mix up:
> -- AS specific redirect uris
> -- Meta data/turi
> (https://tools.ietf.org/html/= draft-sakimura-oauth-meta-07#section-5)
> - CnP:
> -- use of the nonce parameter (as a distinct mitigation beside state f= or
> counter XSRF)

>From our formal analysis of OAuth we are pretty confident that the
mitigation proposed in draft-ietf-oauth-mix-up-mitigation-00 should be
sufficient against the Mix-Up attack.

Cheers,
Daniel


--
Informationssicherheit und Kryptografie
Universit=C3=A4t Trier - Tel. 0651 201 2847 - H436

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat S= akimura
Chairman of the Board, OpenID Foundation
Trustee, Kantara Initiative
--001a1136ffd8a2785e053260a202-- From nobody Sun May 8 22:46:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A2F12D10D for ; Sun, 8 May 2016 22:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 blWdDTuCIpkE for ; Sun, 8 May 2016 22:46:05 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) (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 A1F8812D109 for ; Sun, 8 May 2016 22:46:04 -0700 (PDT) Received: from [80.187.103.36] (helo=[10.152.142.184]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1aze14-00069i-6Z; Mon, 09 May 2016 07:46:02 +0200 Date: Mon, 09 May 2016 07:45:51 +0200 Message-ID: In-Reply-To: References: <571B60BA.8090301@lodderstedt.net> <49355f12-ef58-0637-47e0-7acd54e882d9@lodderstedt.net> From: torsten@lodderstedt.net To: Nat Sakimura MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.syntomo.email_3075443775802722" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 05:46:07 -0000 ----_com.syntomo.email_3075443775802722 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QXJlIHlvdSBzdWdnZXN0aW5nIE9BdXRoIHNob3VsZCBkZWZlYXQgbWFsZXdhcmU/IFNvIGZhciwg dGhpcyB3YXMgY29uc2lkZXJlZCB0byBiZSBoYW5kbGVkIGJ5IE9TL0FudGktVmlydXMvb3RoZXIg bWVhc3VyZXMuIAoKCi0tLS0tLS0tIE9yaWdpbmFsbmFjaHJpY2h0IC0tLS0tLS0tCkJldHJlZmY6 IFJlOiBbT0FVVEgtV0ddIE1peC1VcCBhbmQgQ25QLyBDb2RlIGluamVjdGlvbgpWb246IE5hdCBT YWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPgpBbjogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQ+CkNjOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+ LCI8b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc+Cgo+WWVzLCBhbmQgdW5mb3J0dW5h dGVseSwgdGhhdCBpcyBhIHJhdGhlciBjb21tb24gYXR0YWNrIHRoZXNlIGRheXMuCj5JbmZlc3Rp bmcgYSB1c2VyIGRldmljZSB3aXRoIGEgbWFsd2FyZSBpcyBwcm9iYWJseSBlYXNpZXIgdGhhbiBo YXZpbmcgdGhlCj5jbGllbnQgZGV2ZWxvcGVyIHJlZ2lzdGVyIGl0cyBjbGllbnQgdG8gdW5rbm93 biBzZXJ2ZXIuCj4KPjIwMTblubQ15pyIMeaXpSjml6UpIDE2OjU0IFRvcnN0ZW4gTG9kZGVyc3Rl ZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PjoKPgo+PiBIaSBOYXQsCj4+Cj4+IHBsZWFzZSBl eHBsYWluIHRoZSBhdHRhY2suIEkgYXNzdW1lIHRoZSBhdHRhY2tlciB3b3VsZCBuZWVkIHRvIGNv bnRyb2wKPj4gbmV0d29yayB0cmFuc21pc3Npb24gb3IgY2xpZW50IGRldmljZS4KPj4KPj4ga2lu ZCByZWdhcmRzLAo+PiBUb3JzdGVuLgo+Pgo+PiBBbSAwMS4wNS4yMDE2IHVtIDA3OjM2IHNjaHJp ZWIgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+Ogo+Pgo+PiBJdCBhY3R1YWxseSBk ZXBlbmRzIG9uIHdoYXQgcmlzayBsZXZlbCB0aGUgdHJhbnNhY3Rpb24gaXMgYXQuIEZvciBsb3cg cmlzawo+PiB0cmFuc2FjdGlvbnMsIGp1c3QgaGF2aW5nIHNlcGFyYXRlIHJlZGlyZWN0aW9uIGVu ZHBvaW50IG1heSBiZSBhZGVxdWF0ZS4gT24KPj4gdGhlIG90aGVyIGhhbmQsIEkgY2FuIGVhc2ls eSB0aGluayBvZiBhbiBhdHRhY2sgdGhhdCByZXBsYWNlcyBpc3Mgb24gdGhlCj4+IGF1dGh6IHJl c3BvbnNlIG1ha2luZyB0aGUgY29udHJvbCBpbnZhbGlkIHBvc2luZyBxdWVzdGlvbnMgb24gd2hl dGhlciBpdCBpcwo+PiB3b3J0aCBpbnRyb2R1Y2luZyBpdC4KPj4gT24gU3VuLCBNYXkgMSwgMjAx NiBhdCAxNDoyMSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+IHdyb3RlOgo+Pgo+Pj4g SSBhZ3JlZSB0aGF0IHdl4oCZcmUgZ2V0dGluZyBkYW5nZXJvdXNseSBjbG9zZSB0byByZWNvbW1l bmRpbmcgc2lnbmVkCj4+PiBhc3NlcnRpb25zIGF0IGV2ZXJ5IHN0ZXAgb2YgdGhlIHByb2Nlc3Ms IHRoZXJlYnkgYnlwYXNzaW5nIEhUVFAuIFRoaXMgd2FzCj4+PiB0aGUgc2FtZSBtaXN0YWtlIHRo YXQgV1MtKiBhbmQgU09BUCBtYWRlLCBsZXTigJlzIG5vdCByZXBlYXQgaXQgaWYgd2UgY2FuLgo+ Pj4KPj4+ICDigJQgSnVzdGluCj4+Pgo+Pj4gT24gQXByIDMwLCAyMDE2LCBhdCAxMDo1NyBBTSwg VG9yc3RlbiBMb2RkZXJzdGVkdCA8Cj4+PiB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6 Cj4+Pgo+Pj4gSGkgTmF0LAo+Pj4KPj4+IHN1cmUsIG9uZSBjb3VsZCBhbHNvIGF1dGhlbnRpY2F0 ZSBhbmQgY3J5cHRvZ3JhcGhpY2FsbHkgcHJvdGVjdCB0aGUKPj4+IHJlZGlyZWN0IHJlc3BvbnNl LiBMZXZlcmFnaW5nIE9JREMgY29uY2VwdHMgaXMgYW4gaWRlYSB3b3J0aCBjb25zaWRlcmluZwo+ Pj4gYnV0IHRoZXkgc2hvdWxkIGJlIGFkb3B0ZWQgdG8gdGhlIE9BdXRoIHBoaWxvc29waHkuIFRo ZSBpZCB0b2tlbiBhcyB1c2VkIGluCj4+PiB0aGUgaHlicmlkIGZsb3dzIG1peGVzIGFuIGlkZW50 aXR5IGFzc2VydGlvbiB3aXRoIGVsZW1lbnRzIG9mIHRyYW5zcG9ydAo+Pj4gc2VjdXJpdHkgbWVh c3VyZXMuIEEgT0F1dGggQVMgZG9lcyBub3QgcHJvdmlkZSBpZGVudGl0eSBkYXRhIHRvIGNsaWVu dHMsIHNvCj4+PiB3ZSBvbmx5IG5lZWQgdGhlIHRyYW5zcG9ydCBzZWN1cml0eSBwYXJ0Lgo+Pj4K Pj4+IEkgcGVyc29uYWxseSB3b3VsZCBwcmVmZXIgYSBPQXV0aCByZXNwb25zZSBvYmplY3QgKHNp bWlsYXIgdG8gcmVxdWVzdAo+Pj4gb2JqZWN0IHlvdSBoYXZlIHByb3Bvc2VkKSBvdmVyIHRoZSBp ZCB0b2tlbi4gU3VjaCBhIHJlc3BvbnNlIG9iamVjdCBjb3VsZAo+Pj4gY29udGFpbiAoYW5kIGRp cmVjdGx5IHByb3RlY3QpIHN0YXRlLCBjb2RlIGFuZCBvdGhlciByZXNwb25zZSB2YWx1ZXMuIEkK Pj4+IGNvbnNpZGVyIHRoaXMgdGhlIG1vcmUgZWxlZ2FudCBkZXNpZ24gYW5kIGl0IGlzIGVhc2ll ciB0byBpbXBsZW1lbnQgdGhlbgo+Pj4gaGF2aW5nIGRldGFjaGVkIHNpZ25hdHVyZXMgb3ZlciBo YXNoIHZhbHVlcyBvZiBjb2RlcyBvciBhY2Nlc3MgdG9rZW5zLgo+Pj4gTW9yZW92ZXIsIGl0IHdv dWxkIGFsbG93IHRvIGVuY3J5cHQgdGhlIHJlc3BvbnNlIGFzIHdlbGwuCj4+Pgo+Pj4gR2VuZXJh bGx5LCBvdXIgdGhyZWF0IGFuYWx5c2lzIHNvIGZhciBkb2VzIG5vdCBoYXZlIHByb3ZpZGVkCj4+ PiBqdXN0aWZpY2F0aW9uIGZvciBjcnlwdG9ncmFwaGljYWxseSBwcm90ZWN0ZWQgcmVkaXJlY3Qg cmVzcG9uc2VzLiBBbGwKPj4+IHByb3Bvc2FscyBjdXJyZW50bHkgb24gdGhlIHRhYmxlIHN0b3Ag bWl4IHVwIGFuZCBjb2RlIGluamVjdGlvbiB1c2luZwo+Pj4gc2ltcGxlciBtZWNoYW5pc21zLgo+ Pj4KPj4+IEkgdGhpbmsgT0F1dGggMi4wIGlzIGEgaHVnZSBzdWNjZXNzIGR1ZSB0byBpdHMgYmFs YW5jZSBvZiB2ZXJzYXRpbGl0eSwKPj4+IHNlY3VyaXR5IGFuZCBfc2ltcGxpY2l0eV8uIFdlIGRl ZmluaXRlbHkgbmVlZCB0byBrZWVwIGl0IHNlY3VyZSwgYnV0IHdlCj4+PiBzaG91bGQgYWxzbyBr ZWVwIGl0IGFzIHNpbXBsZSBhcyBwb3NzaWJsZS4KPj4+Cj4+PiBraW5kIHJlZ2FyZHMsCj4+PiBU b3JzdGVuLgo+Pj4gQW0gMjkuMDQuMjAxNiB1bSAxMDowOCBzY2hyaWViIE5hdCBTYWtpbXVyYToK Pj4+Cj4+PiBBcyBJIGxvb2sgYXQgaXQgbW9yZSBhbmQgbW9yZSwgaXQgc3RhcnRlZCB0byBsb29r IGxpa2UgdGhlIHByb2JsZW0gb2YKPj4+IGFjY2VwdGluZyB0YWludGVkIHZhbHVlcyB3aXRob3V0 IG1lc3NhZ2UgYXV0aGVudGljYXRpb24uIFRvIGZpeCB0aGUgcm9vdAo+Pj4gY2F1c2UsIHdlIHdv dWxkIGhhdmUgdG8gYXV0aGVudGljYXRlIHJlc3BvbnNlLiBJRCBUb2tlbiB3YXMgZGVzaWduZWQg dG8KPj4+IGFsc28gc2VydmUgYXMgYSBzb2x1dGlvbiBhbnRpY2lwYXRpbmcgaXQuCj4+Pgo+Pj4g QW55IGNvbmNyZXRlIGlkZWFzPwo+Pj4KPj4+IE9uIFNhdCwgQXByIDIzLCAyMDE2IGF0IDA0OjQ3 IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPAo+Pj4gdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3Rl Ogo+Pj4KPj4+PiBIaSBhbGwsCj4+Pj4KPj4+PiBkaXNjdXNzaW9uIGFib3V0IE1peC1VcCBhbmQg Q25QIHNlZW1zIHRvIGhhdmUgc3RvcHBlZCBhZnRlciB0aGUgc2Vzc2lvbgo+Pj4+IGluIEJBIC0g YXQgbGVhc3QgaW4gdGhlIE9BdXRoIFdHLiBUaGVyZSBpcyBhIGRpc2N1c3Npb24gYWJvdXQKPj4+ PiBtaXRpZ2F0aW9ucyBpbiBPcGVuSWQgQ29ubmVjdCBnb2luZyBvbiBhdCB0aGUgT3BlbklkIENv bm5lY3QgbWFpbGluZwo+Pj4+IGxpc3QuCj4+Pj4KPj4+PiBJJ20gdmVyeSBtdWNoIGludGVyZXN0 ZWQgdG8gZmluZCBhIHNvbHV0aW9uIHdpdGhpbiB0aGUgT0F1dGggcmVhbG0gYXMKPj4+PiBJJ20g bm90IGludGVyZXN0ZWQgdG8gZWl0aGVyIGltcGxlbWVudCB0d28gc29sdXRpb25zIChmb3IgT3Bl bklkIENvbm5lY3QKPj4+PiBhbmQgT0F1dGgpIG9yIGFkb3B0IGEgT3BlbklkLXNwZWNpZmljIHNv bHV0aW9uIHRvIE9BdXRoICh1c2UgaWQhIHRva2Vucwo+Pj4+IGluIHRoZSBmcm9udCBjaGFubmVs KS4gSSB0aGVyZWZvcmUgd291bGQgbGlrZSB0byBzZWUgcHJvZ3Jlc3MgYW5kCj4+Pj4gcHJvcG9z ZSB0byBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiByZWdhcmRpbmcgbWl0aWdhdGlvbnMgZm9yIGJv dGgKPj4+PiB0aHJlYXRzLgo+Pj4+Cj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtb2F1dGgtbWl4LXVwLW1pdGlnYXRpb24tMDAKPj4+PiBwcm9wb3NlcyByZWFzb25h YmxlIG1pdGlnYXRpb25zIGZvciBib3RoIGF0dGFja3MuIFRoZXJlIGFyZSBhbHRlcm5hdGl2ZXMK Pj4+PiBhcyB3ZWxsOgo+Pj4+IC0gbWl4IHVwOgo+Pj4+IC0tIEFTIHNwZWNpZmljIHJlZGlyZWN0 IHVyaXMKPj4+PiAtLSBNZXRhIGRhdGEvdHVyaQo+Pj4+IChodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wNyNzZWN0aW9uLTUpCj4+Pj4gLSBDblA6 Cj4+Pj4gLS0gdXNlIG9mIHRoZSBub25jZSBwYXJhbWV0ZXIgKGFzIGEgZGlzdGluY3QgbWl0aWdh dGlvbiBiZXNpZGUgc3RhdGUgZm9yCj4+Pj4gY291bnRlciBYU1JGKQo+Pj4+Cj4+Pj4gQW55b25l IGhhdmluZyBhbiBvcGluaW9uPwo+Pj4+Cj4+Pj4gYmVzdCByZWdhcmRzLAo+Pj4+IFRvcnN0ZW4u Cj4+Pj4KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+Pj4+IE9BdXRoQGlldGYub3JnCj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+Cj4+Pgo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+IE9BdXRoIG1haWxp bmcgbGlzdAo+Pj4gT0F1dGhAaWV0Zi5vcmcKPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgKPj4+Cj4+Pgo+Pj4gLS0KPk5hdCBTYWtpbXVyYQo+Q2hhaXJtYW4g b2YgdGhlIEJvYXJkLCBPcGVuSUQgRm91bmRhdGlvbgo+VHJ1c3RlZSwgS2FudGFyYSBJbml0aWF0 aXZlCj4= ----_com.syntomo.email_3075443775802722 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPkFyZSB5b3Ugc3VnZ2VzdGluZyBPQXV0aCBzaG91bGQgZGVmZWF0IG1hbGV3 YXJlPyBTbyBmYXIsIHRoaXMgd2FzIGNvbnNpZGVyZWQgdG8gYmUgaGFuZGxlZCBieSBPUy9BbnRp LVZpcnVzL290aGVyIG1lYXN1cmVzLiA8YnI+CjwvcD4KPGJyPjxicj4tLS0tLS0tLSBPcmlnaW5h bG5hY2hyaWNodCAtLS0tLS0tLTxicj5CZXRyZWZmOiBSZTogW09BVVRILVdHXSBNaXgtVXAgYW5k IENuUC8gQ29kZSBpbmplY3Rpb248YnI+Vm9uOiBOYXQgU2FraW11cmEgJmx0O3Nha2ltdXJhQGdt YWlsLmNvbSZndDs8YnI+QW46IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9kZGVy c3RlZHQubmV0Jmd0Ozxicj5DYzogSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0 OywmcXVvdDsmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7JnF1b3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZn dDs8YnI+PGJyPjxkaXYgZGlyPSJsdHIiPlllcywgYW5kIHVuZm9ydHVuYXRlbHksIHRoYXQgaXMg YSByYXRoZXIgY29tbW9uIGF0dGFjayB0aGVzZSBkYXlzLsKgPGRpdj5JbmZlc3RpbmcgYSB1c2Vy IGRldmljZSB3aXRoIGEgbWFsd2FyZSBpcyBwcm9iYWJseSBlYXNpZXIgdGhhbiBoYXZpbmcgdGhl IGNsaWVudCBkZXZlbG9wZXIgcmVnaXN0ZXIgaXRzIGNsaWVudCB0byB1bmtub3duIHNlcnZlci7C oDxicj48ZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9Imx0ciI+MjAx NuW5tDXmnIgx5pelKOaXpSkgMTY6NTQgVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Ij50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwv YT4mZ3Q7Ojxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt YXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6 MWV4Ij48ZGl2IGRpcj0iYXV0byI+PGRpdj48L2Rpdj48ZGl2PkhpIE5hdCw8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PnBsZWFzZSBleHBsYWluIHRoZSBhdHRhY2suIEkgYXNzdW1lIHRoZSBhdHRh Y2tlciB3b3VsZCBuZWVkIHRvIGNvbnRyb2wgbmV0d29yayB0cmFuc21pc3Npb24gb3IgY2xpZW50 IGRldmljZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmtpbmQgcmVnYXJkcyw8L2Rpdj48ZGl2 PlRvcnN0ZW4uPC9kaXY+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxkaXY+PGJyPkFtIDAxLjA1LjIw MTYgdW0gMDc6MzYgc2NocmllYiBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtp bXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0 Ozo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+SXQgYWN0dWFsbHkg ZGVwZW5kcyBvbiB3aGF0IHJpc2sgbGV2ZWwgdGhlIHRyYW5zYWN0aW9uIGlzIGF0LiBGb3IgbG93 IHJpc2sgdHJhbnNhY3Rpb25zLCBqdXN0IGhhdmluZyBzZXBhcmF0ZSByZWRpcmVjdGlvbiBlbmRw b2ludCBtYXkgYmUgYWRlcXVhdGUuIE9uIHRoZSBvdGhlciBoYW5kLCBJIGNhbiBlYXNpbHkgdGhp bmsgb2YgYW4gYXR0YWNrIHRoYXQgcmVwbGFjZXMgaXNzIG9uIHRoZSBhdXRoeiByZXNwb25zZSBt YWtpbmcgdGhlIGNvbnRyb2wgaW52YWxpZCBwb3NpbmcgcXVlc3Rpb25zIG9uIHdoZXRoZXIgaXQg aXMgd29ydGggaW50cm9kdWNpbmcgaXQuIDxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRp diBkaXI9Imx0ciI+T24gU3VuLCBNYXkgMSwgMjAxNiBhdCAxNDoyMSBKdXN0aW4gUmljaGVyICZs dDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hl ckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNv bGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj5J IGFncmVlIHRoYXQgd2XigJlyZSBnZXR0aW5nIGRhbmdlcm91c2x5IGNsb3NlIHRvIHJlY29tbWVu ZGluZyBzaWduZWQgYXNzZXJ0aW9ucyBhdCBldmVyeSBzdGVwIG9mIHRoZSBwcm9jZXNzLCB0aGVy ZWJ5IGJ5cGFzc2luZyBIVFRQLiBUaGlzIHdhcyB0aGUgc2FtZSBtaXN0YWtlIHRoYXQgV1MtKiBh bmQgU09BUCBtYWRlLCBsZXTigJlzIG5vdCByZXBlYXQgaXQgaWYgd2UgY2FuLjwvZGl2PjxkaXYg c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj48ZGl2Pjxicj48L2Rpdj48ZGl2PsKg4oCUIEp1 c3RpbjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj48ZGl2Pjxi cj48ZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+T24gQXByIDMwLCAyMDE2LCBhdCAx MDo1NyBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5A bG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8 L2E+Jmd0OyB3cm90ZTo8L2Rpdj48YnI+PGRpdj4NCg0KICANCiAgPGRpdiBiZ2NvbG9yPSIjRkZG RkZGIiB0ZXh0PSIjMDAwMDAwIj48cD5IaSBOYXQsPC9wPjxwPnN1cmUsIG9uZSBjb3VsZCBhbHNv IGF1dGhlbnRpY2F0ZSBhbmQgY3J5cHRvZ3JhcGhpY2FsbHkgcHJvdGVjdA0KICAgICAgdGhlIHJl ZGlyZWN0IHJlc3BvbnNlLiBMZXZlcmFnaW5nIE9JREMgY29uY2VwdHMgaXMgYW4gaWRlYSB3b3J0 aA0KICAgICAgY29uc2lkZXJpbmcgYnV0IHRoZXkgc2hvdWxkIGJlIGFkb3B0ZWQgdG8gdGhlIE9B dXRoIHBoaWxvc29waHkuDQogICAgICBUaGUgaWQgdG9rZW4gYXMgdXNlZCBpbiB0aGUgaHlicmlk IGZsb3dzIG1peGVzIGFuIGlkZW50aXR5DQogICAgICBhc3NlcnRpb24gd2l0aCBlbGVtZW50cyBv ZiB0cmFuc3BvcnQgc2VjdXJpdHkgbWVhc3VyZXMuIEEgT0F1dGggQVMNCiAgICAgIGRvZXMgbm90 IHByb3ZpZGUgaWRlbnRpdHkgZGF0YSB0byBjbGllbnRzLCBzbyB3ZSBvbmx5IG5lZWQgdGhlDQog ICAgICB0cmFuc3BvcnQgc2VjdXJpdHkgcGFydC4gPGJyPg0KICAgIDwvcD48cD5JIHBlcnNvbmFs bHkgd291bGQgcHJlZmVyIGEgT0F1dGggcmVzcG9uc2Ugb2JqZWN0IChzaW1pbGFyIHRvDQogICAg ICByZXF1ZXN0IG9iamVjdCB5b3UgaGF2ZSBwcm9wb3NlZCkgb3ZlciB0aGUgaWQgdG9rZW4uIFN1 Y2ggYQ0KICAgICAgcmVzcG9uc2Ugb2JqZWN0IGNvdWxkIGNvbnRhaW4gKGFuZCBkaXJlY3RseSBw cm90ZWN0KSBzdGF0ZSwgY29kZQ0KICAgICAgYW5kIG90aGVyIHJlc3BvbnNlIHZhbHVlcy4gSSBj b25zaWRlciB0aGlzIHRoZSBtb3JlIGVsZWdhbnQgZGVzaWduDQogICAgICBhbmQgaXQgaXMgZWFz aWVyIHRvIGltcGxlbWVudCB0aGVuIGhhdmluZyBkZXRhY2hlZCBzaWduYXR1cmVzIG92ZXINCiAg ICAgIGhhc2ggdmFsdWVzIG9mIGNvZGVzIG9yIGFjY2VzcyB0b2tlbnMuIE1vcmVvdmVyLCBpdCB3 b3VsZCBhbGxvdyB0bw0KICAgICAgZW5jcnlwdCB0aGUgcmVzcG9uc2UgYXMgd2VsbC4gPGJyPg0K ICAgIDwvcD48cD5HZW5lcmFsbHksIG91ciB0aHJlYXQgYW5hbHlzaXMgc28gZmFyIGRvZXMgbm90 IGhhdmUgcHJvdmlkZWQNCiAgICAgIGp1c3RpZmljYXRpb24gZm9yIGNyeXB0b2dyYXBoaWNhbGx5 IHByb3RlY3RlZCByZWRpcmVjdCByZXNwb25zZXMuDQogICAgICBBbGwgcHJvcG9zYWxzIGN1cnJl bnRseSBvbiB0aGUgdGFibGUgc3RvcCBtaXggdXAgYW5kIGNvZGUNCiAgICAgIGluamVjdGlvbiB1 c2luZyBzaW1wbGVyIG1lY2hhbmlzbXMuIDxicj4NCiAgICA8L3A+PHA+SSB0aGluayBPQXV0aCAy LjAgaXMgYSBodWdlIHN1Y2Nlc3MgZHVlIHRvIGl0cyBiYWxhbmNlIG9mDQogICAgICB2ZXJzYXRp bGl0eSwgc2VjdXJpdHkgYW5kIF9zaW1wbGljaXR5Xy4gV2UgZGVmaW5pdGVseSBuZWVkIHRvIGtl ZXANCiAgICAgIGl0IHNlY3VyZSwgYnV0IHdlIHNob3VsZCBhbHNvIGtlZXAgaXQgYXMgc2ltcGxl IGFzIHBvc3NpYmxlLjxicj4NCiAgICA8L3A+PHA+a2luZCByZWdhcmRzLDxicj4NCiAgICAgIFRv cnN0ZW4uPGJyPg0KICAgIDwvcD4NCiAgICA8ZGl2PkFtIDI5LjA0LjIwMTYgdW0gMTA6MDggc2No cmllYiBOYXQNCiAgICAgIFNha2ltdXJhOjxicj4NCiAgICA8L2Rpdj4NCiAgICA8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj5BcyBJIGxvb2sgYXQgaXQgbW9yZSBhbmQgbW9yZSwgaXQgc3RhcnRlZCB0 byBsb29rIGxpa2UNCiAgICAgIHRoZSBwcm9ibGVtIG9mIGFjY2VwdGluZyB0YWludGVkIHZhbHVl cyB3aXRob3V0IG1lc3NhZ2UNCiAgICAgIGF1dGhlbnRpY2F0aW9uLiBUbyBmaXggdGhlIHJvb3Qg Y2F1c2UsIHdlIHdvdWxkIGhhdmUgdG8NCiAgICAgIGF1dGhlbnRpY2F0ZSByZXNwb25zZS4gSUQg VG9rZW4gd2FzIGRlc2lnbmVkIHRvIGFsc28gc2VydmUgYXMgYQ0KICAgICAgc29sdXRpb24gYW50 aWNpcGF0aW5nIGl0LiA8YnI+DQogICAgICA8YnI+DQogICAgICBBbnkgY29uY3JldGUgaWRlYXM/ IDxicj4NCiAgICAgIDxicj4NCiAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCiAgICAg ICAgPGRpdiBkaXI9Imx0ciI+T24gU2F0LCBBcHIgMjMsIDIwMTYgYXQgMDQ6NDcgVG9yc3RlbiBM b2RkZXJzdGVkdA0KICAgICAgICAgICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7 DQogICAgICAgICAgd3JvdGU6PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+SGkgYWxsLDxicj4NCiAgICAgICAg ICA8YnI+DQogICAgICAgICAgZGlzY3Vzc2lvbiBhYm91dCBNaXgtVXAgYW5kIENuUCBzZWVtcyB0 byBoYXZlIHN0b3BwZWQgYWZ0ZXINCiAgICAgICAgICB0aGUgc2Vzc2lvbjxicj4NCiAgICAgICAg ICBpbiBCQSAtIGF0IGxlYXN0IGluIHRoZSBPQXV0aCBXRy4gVGhlcmUgaXMgYSBkaXNjdXNzaW9u IGFib3V0PGJyPg0KICAgICAgICAgIG1pdGlnYXRpb25zIGluIE9wZW5JZCBDb25uZWN0IGdvaW5n IG9uIGF0IHRoZSBPcGVuSWQgQ29ubmVjdA0KICAgICAgICAgIG1haWxpbmcgbGlzdC48YnI+DQog ICAgICAgICAgPGJyPg0KICAgICAgICAgIEkmIzM5O20gdmVyeSBtdWNoIGludGVyZXN0ZWQgdG8g ZmluZCBhIHNvbHV0aW9uIHdpdGhpbiB0aGUgT0F1dGgNCiAgICAgICAgICByZWFsbSBhczxicj4N CiAgICAgICAgICBJJiMzOTttIG5vdCBpbnRlcmVzdGVkIHRvIGVpdGhlciBpbXBsZW1lbnQgdHdv IHNvbHV0aW9ucyAoZm9yDQogICAgICAgICAgT3BlbklkIENvbm5lY3Q8YnI+DQogICAgICAgICAg YW5kIE9BdXRoKSBvciBhZG9wdCBhIE9wZW5JZC1zcGVjaWZpYyBzb2x1dGlvbiB0byBPQXV0aCAo dXNlDQogICAgICAgICAgaWQhIHRva2Vuczxicj4NCiAgICAgICAgICBpbiB0aGUgZnJvbnQgY2hh bm5lbCkuIEkgdGhlcmVmb3JlIHdvdWxkIGxpa2UgdG8gc2VlIHByb2dyZXNzDQogICAgICAgICAg YW5kPGJyPg0KICAgICAgICAgIHByb3Bvc2UgdG8gY29udGludWUgdGhlIGRpc2N1c3Npb24gcmVn YXJkaW5nIG1pdGlnYXRpb25zIGZvcg0KICAgICAgICAgIGJvdGggdGhyZWF0cy48YnI+DQogICAg ICAgICAgPGJyPg0KICAgICAgICAgIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW9hdXRoLW1peC11cC1taXRpZ2F0aW9uLTAwIiByZWw9Im5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v YXV0aC1taXgtdXAtbWl0aWdhdGlvbi0wMDwvYT48YnI+DQogICAgICAgICAgcHJvcG9zZXMgcmVh c29uYWJsZSBtaXRpZ2F0aW9ucyBmb3IgYm90aCBhdHRhY2tzLiBUaGVyZSBhcmUNCiAgICAgICAg ICBhbHRlcm5hdGl2ZXM8YnI+DQogICAgICAgICAgYXMgd2VsbDo8YnI+DQogICAgICAgICAgLSBt aXggdXA6PGJyPg0KICAgICAgICAgIC0tIEFTIHNwZWNpZmljIHJlZGlyZWN0IHVyaXM8YnI+DQog ICAgICAgICAgLS0gTWV0YSBkYXRhL3R1cmk8YnI+DQogICAgICAgICAgKDxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA3I3NlY3Rp b24tNSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDcjc2VjdGlvbi01PC9hPik8YnI+ DQogICAgICAgICAgLSBDblA6PGJyPg0KICAgICAgICAgIC0tIHVzZSBvZiB0aGUgbm9uY2UgcGFy YW1ldGVyIChhcyBhIGRpc3RpbmN0IG1pdGlnYXRpb24gYmVzaWRlDQogICAgICAgICAgc3RhdGUg Zm9yPGJyPg0KICAgICAgICAgIGNvdW50ZXIgWFNSRik8YnI+DQogICAgICAgICAgPGJyPg0KICAg ICAgICAgIEFueW9uZSBoYXZpbmcgYW4gb3Bpbmlvbj88YnI+DQogICAgICAgICAgPGJyPg0KICAg ICAgICAgIGJlc3QgcmVnYXJkcyw8YnI+DQogICAgICAgICAgVG9yc3Rlbi48YnI+DQogICAgICAg ICAgPGJyPg0KICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KICAgICAgICAgIE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiAgICAgICAg ICA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQogICAgICAgICAgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQogICAg ICAgIDwvYmxvY2txdW90ZT4NCiAgICAgIDwvZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8 YnI+DQogIDwvZGl2Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj48L2Rp dj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj4N CjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PGRpdiBkaXI9Imx0ciI+LS0gPGJyPjwvZGl2PjxkaXYgZGlyPSJsdHIiPjxkaXYgc3R5 bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOnNtYWxsO2xpbmUtaGVpZ2h0OjE5LjVweCI+ TmF0IFNha2ltdXJhPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6 c21hbGw7bGluZS1oZWlnaHQ6MTkuNXB4Ij5DaGFpcm1hbiBvZiB0aGUgQm9hcmQsIE9wZW5JRCBG b3VuZGF0aW9uPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6c21h bGw7bGluZS1oZWlnaHQ6MTkuNXB4Ij5UcnVzdGVlLCBLYW50YXJhIEluaXRpYXRpdmU8L2Rpdj48 L2Rpdj4NCg== ----_com.syntomo.email_3075443775802722-- From nobody Sun May 8 22:46:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8E712D109 for ; Sun, 8 May 2016 22:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 BWXCPXP8CaT5 for ; Sun, 8 May 2016 22:46:04 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (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 06FFA12B026 for ; Sun, 8 May 2016 22:46:03 -0700 (PDT) Received: from [80.187.103.36] (helo=[10.152.142.184]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1aze12-0005hV-9m; Mon, 09 May 2016 07:46:01 +0200 Date: Mon, 09 May 2016 07:45:51 +0200 Message-ID: In-Reply-To: References: <571B60BA.8090301@lodderstedt.net> <49355f12-ef58-0637-47e0-7acd54e882d9@lodderstedt.net> From: torsten@lodderstedt.net To: Nat Sakimura MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.syntomo.email_3075425110965631" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 05:46:08 -0000 ----_com.syntomo.email_3075425110965631 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QXJlIHlvdSBzdWdnZXN0aW5nIE9BdXRoIHNob3VsZCBkZWZlYXQgbWFsZXdhcmU/IFNvIGZhciwg dGhpcyB3YXMgY29uc2lkZXJlZCB0byBiZSBoYW5kbGVkIGJ5IE9TL0FudGktVmlydXMvb3RoZXIg bWVhc3VyZXMuIAoKCi0tLS0tLS0tIE9yaWdpbmFsbmFjaHJpY2h0IC0tLS0tLS0tCkJldHJlZmY6 IFJlOiBbT0FVVEgtV0ddIE1peC1VcCBhbmQgQ25QLyBDb2RlIGluamVjdGlvbgpWb246IE5hdCBT YWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPgpBbjogVG9yc3RlbiBMb2RkZXJzdGVkdCA8dG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQ+CkNjOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+ LCI8b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc+Cgo+WWVzLCBhbmQgdW5mb3J0dW5h dGVseSwgdGhhdCBpcyBhIHJhdGhlciBjb21tb24gYXR0YWNrIHRoZXNlIGRheXMuCj5JbmZlc3Rp bmcgYSB1c2VyIGRldmljZSB3aXRoIGEgbWFsd2FyZSBpcyBwcm9iYWJseSBlYXNpZXIgdGhhbiBo YXZpbmcgdGhlCj5jbGllbnQgZGV2ZWxvcGVyIHJlZ2lzdGVyIGl0cyBjbGllbnQgdG8gdW5rbm93 biBzZXJ2ZXIuCj4KPjIwMTblubQ15pyIMeaXpSjml6UpIDE2OjU0IFRvcnN0ZW4gTG9kZGVyc3Rl ZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PjoKPgo+PiBIaSBOYXQsCj4+Cj4+IHBsZWFzZSBl eHBsYWluIHRoZSBhdHRhY2suIEkgYXNzdW1lIHRoZSBhdHRhY2tlciB3b3VsZCBuZWVkIHRvIGNv bnRyb2wKPj4gbmV0d29yayB0cmFuc21pc3Npb24gb3IgY2xpZW50IGRldmljZS4KPj4KPj4ga2lu ZCByZWdhcmRzLAo+PiBUb3JzdGVuLgo+Pgo+PiBBbSAwMS4wNS4yMDE2IHVtIDA3OjM2IHNjaHJp ZWIgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+Ogo+Pgo+PiBJdCBhY3R1YWxseSBk ZXBlbmRzIG9uIHdoYXQgcmlzayBsZXZlbCB0aGUgdHJhbnNhY3Rpb24gaXMgYXQuIEZvciBsb3cg cmlzawo+PiB0cmFuc2FjdGlvbnMsIGp1c3QgaGF2aW5nIHNlcGFyYXRlIHJlZGlyZWN0aW9uIGVu ZHBvaW50IG1heSBiZSBhZGVxdWF0ZS4gT24KPj4gdGhlIG90aGVyIGhhbmQsIEkgY2FuIGVhc2ls eSB0aGluayBvZiBhbiBhdHRhY2sgdGhhdCByZXBsYWNlcyBpc3Mgb24gdGhlCj4+IGF1dGh6IHJl c3BvbnNlIG1ha2luZyB0aGUgY29udHJvbCBpbnZhbGlkIHBvc2luZyBxdWVzdGlvbnMgb24gd2hl dGhlciBpdCBpcwo+PiB3b3J0aCBpbnRyb2R1Y2luZyBpdC4KPj4gT24gU3VuLCBNYXkgMSwgMjAx NiBhdCAxNDoyMSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+IHdyb3RlOgo+Pgo+Pj4g SSBhZ3JlZSB0aGF0IHdl4oCZcmUgZ2V0dGluZyBkYW5nZXJvdXNseSBjbG9zZSB0byByZWNvbW1l bmRpbmcgc2lnbmVkCj4+PiBhc3NlcnRpb25zIGF0IGV2ZXJ5IHN0ZXAgb2YgdGhlIHByb2Nlc3Ms IHRoZXJlYnkgYnlwYXNzaW5nIEhUVFAuIFRoaXMgd2FzCj4+PiB0aGUgc2FtZSBtaXN0YWtlIHRo YXQgV1MtKiBhbmQgU09BUCBtYWRlLCBsZXTigJlzIG5vdCByZXBlYXQgaXQgaWYgd2UgY2FuLgo+ Pj4KPj4+ICDigJQgSnVzdGluCj4+Pgo+Pj4gT24gQXByIDMwLCAyMDE2LCBhdCAxMDo1NyBBTSwg VG9yc3RlbiBMb2RkZXJzdGVkdCA8Cj4+PiB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6 Cj4+Pgo+Pj4gSGkgTmF0LAo+Pj4KPj4+IHN1cmUsIG9uZSBjb3VsZCBhbHNvIGF1dGhlbnRpY2F0 ZSBhbmQgY3J5cHRvZ3JhcGhpY2FsbHkgcHJvdGVjdCB0aGUKPj4+IHJlZGlyZWN0IHJlc3BvbnNl LiBMZXZlcmFnaW5nIE9JREMgY29uY2VwdHMgaXMgYW4gaWRlYSB3b3J0aCBjb25zaWRlcmluZwo+ Pj4gYnV0IHRoZXkgc2hvdWxkIGJlIGFkb3B0ZWQgdG8gdGhlIE9BdXRoIHBoaWxvc29waHkuIFRo ZSBpZCB0b2tlbiBhcyB1c2VkIGluCj4+PiB0aGUgaHlicmlkIGZsb3dzIG1peGVzIGFuIGlkZW50 aXR5IGFzc2VydGlvbiB3aXRoIGVsZW1lbnRzIG9mIHRyYW5zcG9ydAo+Pj4gc2VjdXJpdHkgbWVh c3VyZXMuIEEgT0F1dGggQVMgZG9lcyBub3QgcHJvdmlkZSBpZGVudGl0eSBkYXRhIHRvIGNsaWVu dHMsIHNvCj4+PiB3ZSBvbmx5IG5lZWQgdGhlIHRyYW5zcG9ydCBzZWN1cml0eSBwYXJ0Lgo+Pj4K Pj4+IEkgcGVyc29uYWxseSB3b3VsZCBwcmVmZXIgYSBPQXV0aCByZXNwb25zZSBvYmplY3QgKHNp bWlsYXIgdG8gcmVxdWVzdAo+Pj4gb2JqZWN0IHlvdSBoYXZlIHByb3Bvc2VkKSBvdmVyIHRoZSBp ZCB0b2tlbi4gU3VjaCBhIHJlc3BvbnNlIG9iamVjdCBjb3VsZAo+Pj4gY29udGFpbiAoYW5kIGRp cmVjdGx5IHByb3RlY3QpIHN0YXRlLCBjb2RlIGFuZCBvdGhlciByZXNwb25zZSB2YWx1ZXMuIEkK Pj4+IGNvbnNpZGVyIHRoaXMgdGhlIG1vcmUgZWxlZ2FudCBkZXNpZ24gYW5kIGl0IGlzIGVhc2ll ciB0byBpbXBsZW1lbnQgdGhlbgo+Pj4gaGF2aW5nIGRldGFjaGVkIHNpZ25hdHVyZXMgb3ZlciBo YXNoIHZhbHVlcyBvZiBjb2RlcyBvciBhY2Nlc3MgdG9rZW5zLgo+Pj4gTW9yZW92ZXIsIGl0IHdv dWxkIGFsbG93IHRvIGVuY3J5cHQgdGhlIHJlc3BvbnNlIGFzIHdlbGwuCj4+Pgo+Pj4gR2VuZXJh bGx5LCBvdXIgdGhyZWF0IGFuYWx5c2lzIHNvIGZhciBkb2VzIG5vdCBoYXZlIHByb3ZpZGVkCj4+ PiBqdXN0aWZpY2F0aW9uIGZvciBjcnlwdG9ncmFwaGljYWxseSBwcm90ZWN0ZWQgcmVkaXJlY3Qg cmVzcG9uc2VzLiBBbGwKPj4+IHByb3Bvc2FscyBjdXJyZW50bHkgb24gdGhlIHRhYmxlIHN0b3Ag bWl4IHVwIGFuZCBjb2RlIGluamVjdGlvbiB1c2luZwo+Pj4gc2ltcGxlciBtZWNoYW5pc21zLgo+ Pj4KPj4+IEkgdGhpbmsgT0F1dGggMi4wIGlzIGEgaHVnZSBzdWNjZXNzIGR1ZSB0byBpdHMgYmFs YW5jZSBvZiB2ZXJzYXRpbGl0eSwKPj4+IHNlY3VyaXR5IGFuZCBfc2ltcGxpY2l0eV8uIFdlIGRl ZmluaXRlbHkgbmVlZCB0byBrZWVwIGl0IHNlY3VyZSwgYnV0IHdlCj4+PiBzaG91bGQgYWxzbyBr ZWVwIGl0IGFzIHNpbXBsZSBhcyBwb3NzaWJsZS4KPj4+Cj4+PiBraW5kIHJlZ2FyZHMsCj4+PiBU b3JzdGVuLgo+Pj4gQW0gMjkuMDQuMjAxNiB1bSAxMDowOCBzY2hyaWViIE5hdCBTYWtpbXVyYToK Pj4+Cj4+PiBBcyBJIGxvb2sgYXQgaXQgbW9yZSBhbmQgbW9yZSwgaXQgc3RhcnRlZCB0byBsb29r IGxpa2UgdGhlIHByb2JsZW0gb2YKPj4+IGFjY2VwdGluZyB0YWludGVkIHZhbHVlcyB3aXRob3V0 IG1lc3NhZ2UgYXV0aGVudGljYXRpb24uIFRvIGZpeCB0aGUgcm9vdAo+Pj4gY2F1c2UsIHdlIHdv dWxkIGhhdmUgdG8gYXV0aGVudGljYXRlIHJlc3BvbnNlLiBJRCBUb2tlbiB3YXMgZGVzaWduZWQg dG8KPj4+IGFsc28gc2VydmUgYXMgYSBzb2x1dGlvbiBhbnRpY2lwYXRpbmcgaXQuCj4+Pgo+Pj4g QW55IGNvbmNyZXRlIGlkZWFzPwo+Pj4KPj4+IE9uIFNhdCwgQXByIDIzLCAyMDE2IGF0IDA0OjQ3 IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPAo+Pj4gdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3Rl Ogo+Pj4KPj4+PiBIaSBhbGwsCj4+Pj4KPj4+PiBkaXNjdXNzaW9uIGFib3V0IE1peC1VcCBhbmQg Q25QIHNlZW1zIHRvIGhhdmUgc3RvcHBlZCBhZnRlciB0aGUgc2Vzc2lvbgo+Pj4+IGluIEJBIC0g YXQgbGVhc3QgaW4gdGhlIE9BdXRoIFdHLiBUaGVyZSBpcyBhIGRpc2N1c3Npb24gYWJvdXQKPj4+ PiBtaXRpZ2F0aW9ucyBpbiBPcGVuSWQgQ29ubmVjdCBnb2luZyBvbiBhdCB0aGUgT3BlbklkIENv bm5lY3QgbWFpbGluZwo+Pj4+IGxpc3QuCj4+Pj4KPj4+PiBJJ20gdmVyeSBtdWNoIGludGVyZXN0 ZWQgdG8gZmluZCBhIHNvbHV0aW9uIHdpdGhpbiB0aGUgT0F1dGggcmVhbG0gYXMKPj4+PiBJJ20g bm90IGludGVyZXN0ZWQgdG8gZWl0aGVyIGltcGxlbWVudCB0d28gc29sdXRpb25zIChmb3IgT3Bl bklkIENvbm5lY3QKPj4+PiBhbmQgT0F1dGgpIG9yIGFkb3B0IGEgT3BlbklkLXNwZWNpZmljIHNv bHV0aW9uIHRvIE9BdXRoICh1c2UgaWQhIHRva2Vucwo+Pj4+IGluIHRoZSBmcm9udCBjaGFubmVs KS4gSSB0aGVyZWZvcmUgd291bGQgbGlrZSB0byBzZWUgcHJvZ3Jlc3MgYW5kCj4+Pj4gcHJvcG9z ZSB0byBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiByZWdhcmRpbmcgbWl0aWdhdGlvbnMgZm9yIGJv dGgKPj4+PiB0aHJlYXRzLgo+Pj4+Cj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtb2F1dGgtbWl4LXVwLW1pdGlnYXRpb24tMDAKPj4+PiBwcm9wb3NlcyByZWFzb25h YmxlIG1pdGlnYXRpb25zIGZvciBib3RoIGF0dGFja3MuIFRoZXJlIGFyZSBhbHRlcm5hdGl2ZXMK Pj4+PiBhcyB3ZWxsOgo+Pj4+IC0gbWl4IHVwOgo+Pj4+IC0tIEFTIHNwZWNpZmljIHJlZGlyZWN0 IHVyaXMKPj4+PiAtLSBNZXRhIGRhdGEvdHVyaQo+Pj4+IChodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wNyNzZWN0aW9uLTUpCj4+Pj4gLSBDblA6 Cj4+Pj4gLS0gdXNlIG9mIHRoZSBub25jZSBwYXJhbWV0ZXIgKGFzIGEgZGlzdGluY3QgbWl0aWdh dGlvbiBiZXNpZGUgc3RhdGUgZm9yCj4+Pj4gY291bnRlciBYU1JGKQo+Pj4+Cj4+Pj4gQW55b25l IGhhdmluZyBhbiBvcGluaW9uPwo+Pj4+Cj4+Pj4gYmVzdCByZWdhcmRzLAo+Pj4+IFRvcnN0ZW4u Cj4+Pj4KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xwo+Pj4+IE9BdXRoIG1haWxpbmcgbGlzdAo+Pj4+IE9BdXRoQGlldGYub3JnCj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aAo+Pj4+Cj4+Pgo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+IE9BdXRoIG1haWxp bmcgbGlzdAo+Pj4gT0F1dGhAaWV0Zi5vcmcKPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgKPj4+Cj4+Pgo+Pj4gLS0KPk5hdCBTYWtpbXVyYQo+Q2hhaXJtYW4g b2YgdGhlIEJvYXJkLCBPcGVuSUQgRm91bmRhdGlvbgo+VHJ1c3RlZSwgS2FudGFyYSBJbml0aWF0 aXZlCg== ----_com.syntomo.email_3075425110965631 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPkFyZSB5b3Ugc3VnZ2VzdGluZyBPQXV0aCBzaG91bGQgZGVmZWF0IG1hbGV3 YXJlPyBTbyBmYXIsIHRoaXMgd2FzIGNvbnNpZGVyZWQgdG8gYmUgaGFuZGxlZCBieSBPUy9BbnRp LVZpcnVzL290aGVyIG1lYXN1cmVzLiA8YnI+CjwvcD4KPGJyPjxicj4tLS0tLS0tLSBPcmlnaW5h bG5hY2hyaWNodCAtLS0tLS0tLTxicj5CZXRyZWZmOiBSZTogW09BVVRILVdHXSBNaXgtVXAgYW5k IENuUC8gQ29kZSBpbmplY3Rpb248YnI+Vm9uOiBOYXQgU2FraW11cmEgJmx0O3Nha2ltdXJhQGdt YWlsLmNvbSZndDs8YnI+QW46IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9kZGVy c3RlZHQubmV0Jmd0Ozxicj5DYzogSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0 OywmcXVvdDsmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7JnF1b3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZn dDs8YnI+PGJyPjxkaXYgZGlyPSJsdHIiPlllcywgYW5kIHVuZm9ydHVuYXRlbHksIHRoYXQgaXMg YSByYXRoZXIgY29tbW9uIGF0dGFjayB0aGVzZSBkYXlzLsKgPGRpdj5JbmZlc3RpbmcgYSB1c2Vy IGRldmljZSB3aXRoIGEgbWFsd2FyZSBpcyBwcm9iYWJseSBlYXNpZXIgdGhhbiBoYXZpbmcgdGhl IGNsaWVudCBkZXZlbG9wZXIgcmVnaXN0ZXIgaXRzIGNsaWVudCB0byB1bmtub3duIHNlcnZlci7C oDxicj48ZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9Imx0ciI+MjAx NuW5tDXmnIgx5pelKOaXpSkgMTY6NTQgVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Ij50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwv YT4mZ3Q7Ojxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt YXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6 MWV4Ij48ZGl2IGRpcj0iYXV0byI+PGRpdj48L2Rpdj48ZGl2PkhpIE5hdCw8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PnBsZWFzZSBleHBsYWluIHRoZSBhdHRhY2suIEkgYXNzdW1lIHRoZSBhdHRh Y2tlciB3b3VsZCBuZWVkIHRvIGNvbnRyb2wgbmV0d29yayB0cmFuc21pc3Npb24gb3IgY2xpZW50 IGRldmljZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmtpbmQgcmVnYXJkcyw8L2Rpdj48ZGl2 PlRvcnN0ZW4uPC9kaXY+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxkaXY+PGJyPkFtIDAxLjA1LjIw MTYgdW0gMDc6MzYgc2NocmllYiBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtp bXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0 Ozo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+SXQgYWN0dWFsbHkg ZGVwZW5kcyBvbiB3aGF0IHJpc2sgbGV2ZWwgdGhlIHRyYW5zYWN0aW9uIGlzIGF0LiBGb3IgbG93 IHJpc2sgdHJhbnNhY3Rpb25zLCBqdXN0IGhhdmluZyBzZXBhcmF0ZSByZWRpcmVjdGlvbiBlbmRw b2ludCBtYXkgYmUgYWRlcXVhdGUuIE9uIHRoZSBvdGhlciBoYW5kLCBJIGNhbiBlYXNpbHkgdGhp bmsgb2YgYW4gYXR0YWNrIHRoYXQgcmVwbGFjZXMgaXNzIG9uIHRoZSBhdXRoeiByZXNwb25zZSBt YWtpbmcgdGhlIGNvbnRyb2wgaW52YWxpZCBwb3NpbmcgcXVlc3Rpb25zIG9uIHdoZXRoZXIgaXQg aXMgd29ydGggaW50cm9kdWNpbmcgaXQuIDxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRp diBkaXI9Imx0ciI+T24gU3VuLCBNYXkgMSwgMjAxNiBhdCAxNDoyMSBKdXN0aW4gUmljaGVyICZs dDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hl ckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNv bGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj5J IGFncmVlIHRoYXQgd2XigJlyZSBnZXR0aW5nIGRhbmdlcm91c2x5IGNsb3NlIHRvIHJlY29tbWVu ZGluZyBzaWduZWQgYXNzZXJ0aW9ucyBhdCBldmVyeSBzdGVwIG9mIHRoZSBwcm9jZXNzLCB0aGVy ZWJ5IGJ5cGFzc2luZyBIVFRQLiBUaGlzIHdhcyB0aGUgc2FtZSBtaXN0YWtlIHRoYXQgV1MtKiBh bmQgU09BUCBtYWRlLCBsZXTigJlzIG5vdCByZXBlYXQgaXQgaWYgd2UgY2FuLjwvZGl2PjxkaXYg c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj48ZGl2Pjxicj48L2Rpdj48ZGl2PsKg4oCUIEp1 c3RpbjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj48ZGl2Pjxi cj48ZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+T24gQXByIDMwLCAyMDE2LCBhdCAx MDo1NyBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvcnN0ZW5A bG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8 L2E+Jmd0OyB3cm90ZTo8L2Rpdj48YnI+PGRpdj4NCg0KICANCiAgPGRpdiBiZ2NvbG9yPSIjRkZG RkZGIiB0ZXh0PSIjMDAwMDAwIj48cD5IaSBOYXQsPC9wPjxwPnN1cmUsIG9uZSBjb3VsZCBhbHNv IGF1dGhlbnRpY2F0ZSBhbmQgY3J5cHRvZ3JhcGhpY2FsbHkgcHJvdGVjdA0KICAgICAgdGhlIHJl ZGlyZWN0IHJlc3BvbnNlLiBMZXZlcmFnaW5nIE9JREMgY29uY2VwdHMgaXMgYW4gaWRlYSB3b3J0 aA0KICAgICAgY29uc2lkZXJpbmcgYnV0IHRoZXkgc2hvdWxkIGJlIGFkb3B0ZWQgdG8gdGhlIE9B dXRoIHBoaWxvc29waHkuDQogICAgICBUaGUgaWQgdG9rZW4gYXMgdXNlZCBpbiB0aGUgaHlicmlk IGZsb3dzIG1peGVzIGFuIGlkZW50aXR5DQogICAgICBhc3NlcnRpb24gd2l0aCBlbGVtZW50cyBv ZiB0cmFuc3BvcnQgc2VjdXJpdHkgbWVhc3VyZXMuIEEgT0F1dGggQVMNCiAgICAgIGRvZXMgbm90 IHByb3ZpZGUgaWRlbnRpdHkgZGF0YSB0byBjbGllbnRzLCBzbyB3ZSBvbmx5IG5lZWQgdGhlDQog ICAgICB0cmFuc3BvcnQgc2VjdXJpdHkgcGFydC4gPGJyPg0KICAgIDwvcD48cD5JIHBlcnNvbmFs bHkgd291bGQgcHJlZmVyIGEgT0F1dGggcmVzcG9uc2Ugb2JqZWN0IChzaW1pbGFyIHRvDQogICAg ICByZXF1ZXN0IG9iamVjdCB5b3UgaGF2ZSBwcm9wb3NlZCkgb3ZlciB0aGUgaWQgdG9rZW4uIFN1 Y2ggYQ0KICAgICAgcmVzcG9uc2Ugb2JqZWN0IGNvdWxkIGNvbnRhaW4gKGFuZCBkaXJlY3RseSBw cm90ZWN0KSBzdGF0ZSwgY29kZQ0KICAgICAgYW5kIG90aGVyIHJlc3BvbnNlIHZhbHVlcy4gSSBj b25zaWRlciB0aGlzIHRoZSBtb3JlIGVsZWdhbnQgZGVzaWduDQogICAgICBhbmQgaXQgaXMgZWFz aWVyIHRvIGltcGxlbWVudCB0aGVuIGhhdmluZyBkZXRhY2hlZCBzaWduYXR1cmVzIG92ZXINCiAg ICAgIGhhc2ggdmFsdWVzIG9mIGNvZGVzIG9yIGFjY2VzcyB0b2tlbnMuIE1vcmVvdmVyLCBpdCB3 b3VsZCBhbGxvdyB0bw0KICAgICAgZW5jcnlwdCB0aGUgcmVzcG9uc2UgYXMgd2VsbC4gPGJyPg0K ICAgIDwvcD48cD5HZW5lcmFsbHksIG91ciB0aHJlYXQgYW5hbHlzaXMgc28gZmFyIGRvZXMgbm90 IGhhdmUgcHJvdmlkZWQNCiAgICAgIGp1c3RpZmljYXRpb24gZm9yIGNyeXB0b2dyYXBoaWNhbGx5 IHByb3RlY3RlZCByZWRpcmVjdCByZXNwb25zZXMuDQogICAgICBBbGwgcHJvcG9zYWxzIGN1cnJl bnRseSBvbiB0aGUgdGFibGUgc3RvcCBtaXggdXAgYW5kIGNvZGUNCiAgICAgIGluamVjdGlvbiB1 c2luZyBzaW1wbGVyIG1lY2hhbmlzbXMuIDxicj4NCiAgICA8L3A+PHA+SSB0aGluayBPQXV0aCAy LjAgaXMgYSBodWdlIHN1Y2Nlc3MgZHVlIHRvIGl0cyBiYWxhbmNlIG9mDQogICAgICB2ZXJzYXRp bGl0eSwgc2VjdXJpdHkgYW5kIF9zaW1wbGljaXR5Xy4gV2UgZGVmaW5pdGVseSBuZWVkIHRvIGtl ZXANCiAgICAgIGl0IHNlY3VyZSwgYnV0IHdlIHNob3VsZCBhbHNvIGtlZXAgaXQgYXMgc2ltcGxl IGFzIHBvc3NpYmxlLjxicj4NCiAgICA8L3A+PHA+a2luZCByZWdhcmRzLDxicj4NCiAgICAgIFRv cnN0ZW4uPGJyPg0KICAgIDwvcD4NCiAgICA8ZGl2PkFtIDI5LjA0LjIwMTYgdW0gMTA6MDggc2No cmllYiBOYXQNCiAgICAgIFNha2ltdXJhOjxicj4NCiAgICA8L2Rpdj4NCiAgICA8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj5BcyBJIGxvb2sgYXQgaXQgbW9yZSBhbmQgbW9yZSwgaXQgc3RhcnRlZCB0 byBsb29rIGxpa2UNCiAgICAgIHRoZSBwcm9ibGVtIG9mIGFjY2VwdGluZyB0YWludGVkIHZhbHVl cyB3aXRob3V0IG1lc3NhZ2UNCiAgICAgIGF1dGhlbnRpY2F0aW9uLiBUbyBmaXggdGhlIHJvb3Qg Y2F1c2UsIHdlIHdvdWxkIGhhdmUgdG8NCiAgICAgIGF1dGhlbnRpY2F0ZSByZXNwb25zZS4gSUQg VG9rZW4gd2FzIGRlc2lnbmVkIHRvIGFsc28gc2VydmUgYXMgYQ0KICAgICAgc29sdXRpb24gYW50 aWNpcGF0aW5nIGl0LiA8YnI+DQogICAgICA8YnI+DQogICAgICBBbnkgY29uY3JldGUgaWRlYXM/ IDxicj4NCiAgICAgIDxicj4NCiAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCiAgICAg ICAgPGRpdiBkaXI9Imx0ciI+T24gU2F0LCBBcHIgMjMsIDIwMTYgYXQgMDQ6NDcgVG9yc3RlbiBM b2RkZXJzdGVkdA0KICAgICAgICAgICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7 DQogICAgICAgICAgd3JvdGU6PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAgPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+SGkgYWxsLDxicj4NCiAgICAgICAg ICA8YnI+DQogICAgICAgICAgZGlzY3Vzc2lvbiBhYm91dCBNaXgtVXAgYW5kIENuUCBzZWVtcyB0 byBoYXZlIHN0b3BwZWQgYWZ0ZXINCiAgICAgICAgICB0aGUgc2Vzc2lvbjxicj4NCiAgICAgICAg ICBpbiBCQSAtIGF0IGxlYXN0IGluIHRoZSBPQXV0aCBXRy4gVGhlcmUgaXMgYSBkaXNjdXNzaW9u IGFib3V0PGJyPg0KICAgICAgICAgIG1pdGlnYXRpb25zIGluIE9wZW5JZCBDb25uZWN0IGdvaW5n IG9uIGF0IHRoZSBPcGVuSWQgQ29ubmVjdA0KICAgICAgICAgIG1haWxpbmcgbGlzdC48YnI+DQog ICAgICAgICAgPGJyPg0KICAgICAgICAgIEkmIzM5O20gdmVyeSBtdWNoIGludGVyZXN0ZWQgdG8g ZmluZCBhIHNvbHV0aW9uIHdpdGhpbiB0aGUgT0F1dGgNCiAgICAgICAgICByZWFsbSBhczxicj4N CiAgICAgICAgICBJJiMzOTttIG5vdCBpbnRlcmVzdGVkIHRvIGVpdGhlciBpbXBsZW1lbnQgdHdv IHNvbHV0aW9ucyAoZm9yDQogICAgICAgICAgT3BlbklkIENvbm5lY3Q8YnI+DQogICAgICAgICAg YW5kIE9BdXRoKSBvciBhZG9wdCBhIE9wZW5JZC1zcGVjaWZpYyBzb2x1dGlvbiB0byBPQXV0aCAo dXNlDQogICAgICAgICAgaWQhIHRva2Vuczxicj4NCiAgICAgICAgICBpbiB0aGUgZnJvbnQgY2hh bm5lbCkuIEkgdGhlcmVmb3JlIHdvdWxkIGxpa2UgdG8gc2VlIHByb2dyZXNzDQogICAgICAgICAg YW5kPGJyPg0KICAgICAgICAgIHByb3Bvc2UgdG8gY29udGludWUgdGhlIGRpc2N1c3Npb24gcmVn YXJkaW5nIG1pdGlnYXRpb25zIGZvcg0KICAgICAgICAgIGJvdGggdGhyZWF0cy48YnI+DQogICAg ICAgICAgPGJyPg0KICAgICAgICAgIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW9hdXRoLW1peC11cC1taXRpZ2F0aW9uLTAwIiByZWw9Im5vcmVmZXJyZXIi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v YXV0aC1taXgtdXAtbWl0aWdhdGlvbi0wMDwvYT48YnI+DQogICAgICAgICAgcHJvcG9zZXMgcmVh c29uYWJsZSBtaXRpZ2F0aW9ucyBmb3IgYm90aCBhdHRhY2tzLiBUaGVyZSBhcmUNCiAgICAgICAg ICBhbHRlcm5hdGl2ZXM8YnI+DQogICAgICAgICAgYXMgd2VsbDo8YnI+DQogICAgICAgICAgLSBt aXggdXA6PGJyPg0KICAgICAgICAgIC0tIEFTIHNwZWNpZmljIHJlZGlyZWN0IHVyaXM8YnI+DQog ICAgICAgICAgLS0gTWV0YSBkYXRhL3R1cmk8YnI+DQogICAgICAgICAgKDxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA3I3NlY3Rp b24tNSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDcjc2VjdGlvbi01PC9hPik8YnI+ DQogICAgICAgICAgLSBDblA6PGJyPg0KICAgICAgICAgIC0tIHVzZSBvZiB0aGUgbm9uY2UgcGFy YW1ldGVyIChhcyBhIGRpc3RpbmN0IG1pdGlnYXRpb24gYmVzaWRlDQogICAgICAgICAgc3RhdGUg Zm9yPGJyPg0KICAgICAgICAgIGNvdW50ZXIgWFNSRik8YnI+DQogICAgICAgICAgPGJyPg0KICAg ICAgICAgIEFueW9uZSBoYXZpbmcgYW4gb3Bpbmlvbj88YnI+DQogICAgICAgICAgPGJyPg0KICAg ICAgICAgIGJlc3QgcmVnYXJkcyw8YnI+DQogICAgICAgICAgVG9yc3Rlbi48YnI+DQogICAgICAg ICAgPGJyPg0KICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KICAgICAgICAgIE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiAgICAgICAg ICA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBp ZXRmLm9yZzwvYT48YnI+DQogICAgICAgICAgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQogICAg ICAgIDwvYmxvY2txdW90ZT4NCiAgICAgIDwvZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8 YnI+DQogIDwvZGl2Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj48L2Rp dj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj4N CjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PGRpdiBkaXI9Imx0ciI+LS0gPGJyPjwvZGl2PjxkaXYgZGlyPSJsdHIiPjxkaXYgc3R5 bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOnNtYWxsO2xpbmUtaGVpZ2h0OjE5LjVweCI+ TmF0IFNha2ltdXJhPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6 c21hbGw7bGluZS1oZWlnaHQ6MTkuNXB4Ij5DaGFpcm1hbiBvZiB0aGUgQm9hcmQsIE9wZW5JRCBG b3VuZGF0aW9uPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LXNpemU6c21h bGw7bGluZS1oZWlnaHQ6MTkuNXB4Ij5UcnVzdGVlLCBLYW50YXJhIEluaXRpYXRpdmU8L2Rpdj48 L2Rpdj4NCg== ----_com.syntomo.email_3075425110965631-- From nobody Mon May 9 05:38:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BB312B077; Mon, 9 May 2016 05:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-39p_oURuOR; Mon, 9 May 2016 05:38:27 -0700 (PDT) Received: from out4133-18.mail.aliyun.com (out4133-18.mail.aliyun.com [42.120.133.18]) by ietfa.amsl.com (Postfix) with ESMTP id BA3EC12D181; Mon, 9 May 2016 05:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1462797505; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=dCMpT5UTfYmGIkvVFy+J5RS0W1mnTTCjS0d59row+KQ=; b=NjaDaCVy2xDuyYi8gQ+fDOGwxCPuRsKGwMdYknTz+7CUEDQXUYhSjxsmaFgcBbzD3uWMQyPHx6rWI8ejdxbIKsN9WrDszRxWNxVpw9LtdpEVb3rlATm3tY/fTWbLW8eWmfEXs8GdfKRGQz6ABNaGCi09mbb3VFUESreDio31wAQ= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R101e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03292; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=7; SR=0; TI=SMTPD_----4nE16x5_1462797491; Received: from 30.30.150.30(mailfrom:kepeng.lkp@alibaba-inc.com ip:182.92.253.7) by smtp.aliyun-inc.com(127.0.0.1); Mon, 09 May 2016 20:38:20 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Mon, 09 May 2016 20:38:11 +0800 From: "Kepeng Li" To: "Kepeng Li" , "ace@ietf.org" Message-ID: Thread-Topic: [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3545671101_2500699" Archived-At: Cc: cose@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 12:38:32 -0000 > ´ËÓʼþʹÓà MIME ¸ñʽ¡£ÓÉÓÚÓʼþÔĶÁ³ÌÐò²»ÄÜʶ±ð ´Ë¸ñʽ£¬Òò´Ë£¬¿ÉÄÜÎÞ·¨Ê¶±ð¸ÃÓʼþµÄ·Ö²¿»ò²¿·ÖÄÚÈÝ¡£ --B_3545671101_2500699 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable We got several supports and no objections, so it is concluded that the draf= t is adopted as an ACE WG item, with the change that we remove the "web=A1=B0 fro= m the name. Authors: please resubmit the current draft as draft-ietf-ace-cbor-token-00.txt; we will start processing further changes in the WG process.(If you already know about technical issues, please use the WG tracker for now; editorial issues might be tracked easier on github.= ) We will also add this item in our ACE charter. Kind Regards Kepeng (ACE co-chair) =B7=A2=BC=FE=C8=CB: Li Kepeng =C8=D5=C6=DA: Thursday, 7 April, 2016 9:34 am =D6=C1: "ace@ietf.org" =B3=AD=CB=CD: Kathleen Moriarty , Hannes Tschofenig , , , Stephen Farrell =D6=F7=CC=E2: [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 To: ACE WG Cc: OAuth and COSE WG Hello all, This note begins a Call For Adoption for draft-wahlstroem-ace-cbor-web-token-00 [1] to be adopted as an ACE working group item, and added in the charter. The call ends on April 22, 2016. Keep in mind that adoption of a document does not mean the document as-is is ready for publication. It is merely acceptance of the document as a starting point for what will be the final product of the ACE working group. The working group is free to make changes to the document according to the normal consensus process. Please reply on this thread with expressions of support or opposition, preferably with comments, regarding accepting this as a work item. Note that this email was also copied to OAuth and COSE WG, in order to get input from wider audience. Thanks, Kind Regards Kepeng (ACE co-chair) [1] https://datatracker.ietf.org/doc/draft-wahlstroem-ace-cbor-web-token/ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace --B_3545671101_2500699 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
We got several supports = and no objections, so it is concluded that the draft is adopted as an ACE WG= item, with the change that we remove the "web“ from the name.<= /div>

Authors: please resubmit the= current draft as draft-ietf-ace-cbor-token-00.txt; we will start processing= further changes in the WG process.(If you already know about technical issues, please use t= he WG tracker for now; editorial issues might be tracked easier on github.)<= /span>
<= br>
We will a= lso add this item in our ACE charter.

Kind Regards
Kepeng (ACE co-chair)

=B7=A2=BC=FE=C8=CB: Li Kep= eng <kepeng.lkp@alibaba-inc.c= om>
=C8=D5=C6=DA: Thursday, 7 April= , 2016 9:34 am
=D6=C1: "ace@ietf.org" <ace@ietf= .org>
=B3=AD=CB=CD: Kathleen Moriar= ty <kathleen.moriarty.i= etf@gmail.com>, Hannes Tschofenig <hannes.tschofenig@gmx.net>, <cose@ietf.org>, <oauth@ietf.= org>, Stephen Farrell <= stephen.farrell@cs.tcd.ie>
=D6=F7=CC=E2: [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00
=

To: ACE WG
Cc: OAuth and COSE WG
<= font face=3D"Courier">

Hello= all,

This note begins a Call For Adoption for draft-wa=
hlstroem-ace-cbor-web-token-00 [1]
to be adopted as an ACE working grou= p item, and added in the charter.
The call = ends on April 22, 2016.

Keep in mind that adoption of a=
 document does not mean the document
as-is is ready for publication. It is merely acceptance of the
document as a starting point for what will be the final product
of the ACE working group. The working group is free to make changes to
the document according to the normal consensus process.

Please reply on this thread with expressions of support or opposition,
preferably with comments, regarding accepting this as a work item.

Note that this email was also copied to OAuth an= d COSE WG, in order to 
get input from wider audience.

Thanks,

Kind Regards
Kepeng (ACE co-chair)


_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/ma= ilman/listinfo/ace --B_3545671101_2500699-- From nobody Mon May 9 07:31:54 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF6312B05A; Mon, 9 May 2016 07:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 JbUVoDqJKGbt; Mon, 9 May 2016 07:31:47 -0700 (PDT) Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by ietfa.amsl.com (Postfix) with ESMTP id BACC912B00A; Mon, 9 May 2016 07:31:47 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id 8176A47E163; Mon, 9 May 2016 16:31:37 +0200 (CEST) X-Originating-IP: 134.102.17.95 Received: from eduroam-0351.wlan.uni-bremen.de (eduroam-0351.wlan.uni-bremen.de [134.102.17.95]) (Authenticated sender: cabo@cabo.im) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id B528DA80E6; Mon, 9 May 2016 16:31:35 +0200 (CEST) Message-ID: <57309F46.9040705@tzi.org> Date: Mon, 09 May 2016 16:31:34 +0200 From: Carsten Bormann User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Kepeng Li References: In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: cose@ietf.org, oauth@ietf.org, "ace@ietf.org" Subject: Re: [OAUTH-WG] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 14:31:49 -0000 > draft-ietf-ace-cbor-token-00.txt; For the record, I do not think that ACE has a claim on the term "CBOR Token". While the term token is not used in RFC 7049, there are many tokens that could be expressed in CBOR or be used in applying CBOR to a problem. ACE CBOR Token is fine, though. (Or, better, CBOR ACE Token, CAT.) Grüße, Carsten From nobody Mon May 9 11:14:18 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E7812D59F for ; Mon, 9 May 2016 11:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8-CyiYTA6EN for ; Mon, 9 May 2016 11:14:15 -0700 (PDT) Received: from aulis.gtrs.de (aulis.gtrs.de [5.39.78.151]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375FD12B05A for ; Mon, 9 May 2016 11:14:14 -0700 (PDT) Received: from [136.199.52.42] (infsec42.uni-trier.de [136.199.52.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by aulis.gtrs.de (Postfix) with ESMTPSA id 7B168201E9 for ; Mon, 9 May 2016 20:14:10 +0200 (CEST) To: oauth@ietf.org References: <571A33E0.6070401@uni-trier.de> From: Guido Schmitz Message-ID: <5730D36A.4050601@gtrs.de> Date: Mon, 9 May 2016 20:14:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <571A33E0.6070401@uni-trier.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.7 at aulis.gtrs.de X-Virus-Status: Clean Archived-At: Subject: Re: [OAUTH-WG] Multi-AS State Re-Use X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 18:14:17 -0000 Hi all, can anybody confirm that this is a new / undocumented attack? Cheers, Guido, Daniel, and Ralf On 22.04.2016 16:23, Daniel Fett wrote: > Hi all, > > Besides the state leakage attack we found that another important fact > regarding state is underspecified: Each state value should only be > used for one run of the protocol, in particular, each AS should see a > different state in multi-AS settings. Clients might be tempted to > generate state once and then re-use each time a user wants to > authorize. > > If state is re-used, given a setup where one Client allows users to > authorize using two AS, a potentially malicious AS learns the state > value that is valid for authorization at an honest AS. I.e., each AS > can mount a CSRF attack on the user using the other AS. > > Just as the attack in the other mail, this is not a big deal in > practice, but should be discussed somewhere. > > Cheers, > Daniel, Guido, and Ralf > From nobody Mon May 9 12:26:45 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1FA12B051 for ; Mon, 9 May 2016 12:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0pylCbSIW7F for ; Mon, 9 May 2016 12:26:37 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C8E12B010 for ; Mon, 9 May 2016 12:26:37 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id f74so94482793qge.2 for ; Mon, 09 May 2016 12:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RCoXKCwXNhHQaZ96ff6uTtU2qFradK6zYjm4Pfs+Hiw=; b=sGZtF6eqsLNAMRXficA0W8ME2VdGNKwmdf1cJ24Tqpk+5ZLSba3zNMAi4jScDuRWwU Gds83YAELFIcpvPgliM7TvZCnunwnk8dXtiwj6GEZj0CY6ddlyjCeHRiyjmXys9x8j6S x329cCxtgNMHRJtklFW9X1rb9JSSjz5QoPUI5/NecVStK/IcYJLLxk9U94DdOuoZ4fh5 166mIrrUKHtbOvcewhZMv/2h5HvXSENoGqe9JAWQriGfwHJOrUAZTBQ5shjeXC4J8tKR KkAwTE+BrpXa210wOxlETUmg5GmWasTPnqcwjE6RcZKUMn0xM82KamwXh1FPTgVlSIRj VXNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RCoXKCwXNhHQaZ96ff6uTtU2qFradK6zYjm4Pfs+Hiw=; b=mYLD8adgi7TwdsyRWo27S2y3vuLON/fSiPOGQTZuTFnnChWwppDDKoTkk4SCikRoXC Ry1vgzdNm6fj7ckSPzXNxvfhT2qp/ioMGPkCkRe6yyPx2iSrXkSEXWmragEP5uDYEAMj e/otR0oUgjBe+DrNnLvw/Wp4UCvTpvKnKE778k7WKOmPEgxsSQxT7TxjFlwmStmA8vau TA7lXIcU7ZK7QOaRchKqf/pF8EPpoe/qFZ2zuLVoPLLXAErXVtpaLCZeSGv1+dZWVbf9 4z2Yp/N0Q9eJW2vdQ/NXb1qALYnl00u6GAi9OJcgL050/htmamrMqLVMlj/vYFchCFOx VHoA== X-Gm-Message-State: AOPr4FV6naiR2Bxqp+eXgXDQnoGiUa56EgAedP5fcXbacAM0/NBnilcg+Xcbc0IUb9/mByop1jV/Zbyi2KloRg== X-Received: by 10.140.222.210 with SMTP id s201mr37459740qhb.67.1462821996223; Mon, 09 May 2016 12:26:36 -0700 (PDT) MIME-Version: 1.0 References: <571B60BA.8090301@lodderstedt.net> <49355f12-ef58-0637-47e0-7acd54e882d9@lodderstedt.net> In-Reply-To: From: Nat Sakimura Date: Mon, 09 May 2016 19:26:25 +0000 Message-ID: To: torsten@lodderstedt.net Content-Type: multipart/alternative; boundary=001a113732a474632505326dc940 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 19:26:40 -0000 --001a113732a474632505326dc940 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Torsten, No, not defeating, but being able to find out if the input is tainted or not. Nat On Mon, May 9, 2016 at 07:46 wrote: > Are you suggesting OAuth should defeat maleware? So far, this was > considered to be handled by OS/Anti-Virus/other measures. > > > -------- Originalnachricht -------- > Betreff: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection > Von: Nat Sakimura > An: Torsten Lodderstedt > Cc: Justin Richer ,"" > > Yes, and unfortunately, that is a rather common attack these days. > Infesting a user device with a malware is probably easier than having the > client developer register its client to unknown server. > > 2016=E5=B9=B45=E6=9C=881=E6=97=A5(=E6=97=A5) 16:54 Torsten Lodderstedt : > >> Hi Nat, >> >> please explain the attack. I assume the attacker would need to control >> network transmission or client device. >> >> kind regards, >> Torsten. >> >> Am 01.05.2016 um 07:36 schrieb Nat Sakimura : >> >> It actually depends on what risk level the transaction is at. For low >> risk transactions, just having separate redirection endpoint may be >> adequate. On the other hand, I can easily think of an attack that replac= es >> iss on the authz response making the control invalid posing questions on >> whether it is worth introducing it. >> On Sun, May 1, 2016 at 14:21 Justin Richer wrote: >> >>> I agree that we=E2=80=99re getting dangerously close to recommending si= gned >>> assertions at every step of the process, thereby bypassing HTTP. This w= as >>> the same mistake that WS-* and SOAP made, let=E2=80=99s not repeat it i= f we can. >>> >>> =E2=80=94 Justin >>> >>> On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>> Hi Nat, >>> >>> sure, one could also authenticate and cryptographically protect the >>> redirect response. Leveraging OIDC concepts is an idea worth considerin= g >>> but they should be adopted to the OAuth philosophy. The id token as use= d in >>> the hybrid flows mixes an identity assertion with elements of transport >>> security measures. A OAuth AS does not provide identity data to clients= , so >>> we only need the transport security part. >>> >>> I personally would prefer a OAuth response object (similar to request >>> object you have proposed) over the id token. Such a response object cou= ld >>> contain (and directly protect) state, code and other response values. I >>> consider this the more elegant design and it is easier to implement the= n >>> having detached signatures over hash values of codes or access tokens. >>> Moreover, it would allow to encrypt the response as well. >>> >>> Generally, our threat analysis so far does not have provided >>> justification for cryptographically protected redirect responses. All >>> proposals currently on the table stop mix up and code injection using >>> simpler mechanisms. >>> >>> I think OAuth 2.0 is a huge success due to its balance of versatility, >>> security and _simplicity_. We definitely need to keep it secure, but we >>> should also keep it as simple as possible. >>> >>> kind regards, >>> Torsten. >>> Am 29.04.2016 um 10:08 schrieb Nat Sakimura: >>> >>> As I look at it more and more, it started to look like the problem of >>> accepting tainted values without message authentication. To fix the roo= t >>> cause, we would have to authenticate response. ID Token was designed to >>> also serve as a solution anticipating it. >>> >>> Any concrete ideas? >>> >>> On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>>> Hi all, >>>> >>>> discussion about Mix-Up and CnP seems to have stopped after the sessio= n >>>> in BA - at least in the OAuth WG. There is a discussion about >>>> mitigations in OpenId Connect going on at the OpenId Connect mailing >>>> list. >>>> >>>> I'm very much interested to find a solution within the OAuth realm as >>>> I'm not interested to either implement two solutions (for OpenId Conne= ct >>>> and OAuth) or adopt a OpenId-specific solution to OAuth (use id! token= s >>>> in the front channel). I therefore would like to see progress and >>>> propose to continue the discussion regarding mitigations for both >>>> threats. >>>> >>>> https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00 >>>> proposes reasonable mitigations for both attacks. There are alternativ= es >>>> as well: >>>> - mix up: >>>> -- AS specific redirect uris >>>> -- Meta data/turi >>>> (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5) >>>> - CnP: >>>> -- use of the nonce parameter (as a distinct mitigation beside state f= or >>>> counter XSRF) >>>> >>>> Anyone having an opinion? >>>> >>>> best regards, >>>> Torsten. >>>> >>>> _______________________________________________ >>>> OAuth mailing 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 > Chairman of the Board, OpenID Foundation > Trustee, Kantara Initiative > --=20 Nat Sakimura Chairman of the Board, OpenID Foundation Trustee, Kantara Initiative --001a113732a474632505326dc940 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Torsten,

No, not defeating, but being able to find out if the in= put is tainted or not.

Nat
On Mon, May 9, 2016 at 07:46 <torsten@lodderstedt.net> wrote:

Are you suggesting OAuth should defeat malewar= e? So far, this was considered to be handled by OS/Anti-Virus/other measure= s.



-------- Originalnachricht --------
Betreff: Re: [OAUTH-WG] Mix-= Up and CnP/ Code injection
Von: Nat Sakimura <sakimura@gmail.com>
An: Torsten = Lodderstedt <torsten@lodderstedt.net>
Cc: Justin Richer <jricher@mit.edu>,"<oauth@ietf.org>"= ; <oauth@ietf.org>

Yes, and unfortunately, that is a rather comm= on attack these days.=C2=A0
Infesting a user device with a malware is p= robably easier than having the client developer register its client to unkn= own server.=C2=A0

Hi Nat,

please explain the attack= . I assume the attacker would need to control network transmission or clien= t device.

kind regards,
Torsten.

Am 01.05.2016 um 07:36 schrieb Nat Sakimura = <sakimura@gmail.= com>:

It actually depend= s on what risk level the transaction is at. For low risk transactions, just= having separate redirection endpoint may be adequate. On the other hand, I= can easily think of an attack that replaces iss on the authz response maki= ng the control invalid posing questions on whether it is worth introducing = it.
On Sun, May 1, 2016 at = 14:21 Justin Richer <jricher@mit.edu> wrote:
I agree that we=E2=80=99re getting danger= ously close to recommending signed assertions at every step of the process,= thereby bypassing HTTP. This was the same mistake that WS-* and SOAP made,= let=E2=80=99s not repeat it if we can.

=C2=A0=E2=80=94 Justin

On Apr 30= , 2016, at 10:57 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=
=20

Hi Nat,

sure, one coul= d also authenticate and cryptographically protect the redirect response. Leveraging OIDC concepts is an idea worth considering but they should be adopted to the OAuth philosophy. The id token as used in the hybrid flows mixes an identity assertion with elements of transport security measures. A OAuth AS does not provide identity data to clients, so we only need the transport security part.

I personally would prefer a OAuth response object (similar to request object you have proposed) over the id token. Such a response object could contain (and directly protect) state, code and other response values. I consider this the more elegant design and it is easier to implement then having detached signatures over hash values of codes or access tokens. Moreover, it would allow to encrypt the response as well.

Generally, our threat analysis so far does not have provided justification for cryptographically protected redirect responses. All proposals currently on the table stop mix up and code injection using simpler mechanisms.

I think OAuth 2.0 is a huge success due to its balance of versatility, security and _simplicity_. We definitely need to keep it secure, but we should also keep it as simple as possible.

kind regards,
Torsten.

Am 29.04.2016 um 10:08 schrieb Nat Sakimura:
As I look at it more and more, it started to = look like the problem of accepting tainted values without message authentication. To fix the root cause, we would have to authenticate response. ID Token was designed to also serve as a solution anticipating it.

Any concrete ideas?

On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt <= torsten@lodderstedt.net> wrote:
Hi all,

discussion about Mix-Up and CnP seems to have stopped after the session
in BA - at least in the OAuth WG. There is a discussion about
mitigations in OpenId Connect going on at the OpenId Connect mailing list.

I'm very much interested to find a solution within the OAuth realm as
I'm not interested to either implement two solutions (for OpenId Connect
and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens
in the front channel). I therefore would like to see progress and
propose to continue the discussion regarding mitigations for both threats.

https://tools.ietf.org/ht= ml/draft-ietf-oauth-mix-up-mitigation-00
proposes reasonable mitigations for both attacks. There are alternatives
as well:
- mix up:
-- AS specific redirect uris
-- Meta data/turi
(https://tools.ietf.org/= html/draft-sakimura-oauth-meta-07#section-5)
- CnP:
-- use of the nonce parameter (as a distinct mitigation beside state for
counter XSRF)

Anyone having an opinion?

best regards,
Torsten.

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairman of the Board, OpenID Foundatio= n
T= rustee, Kantara Initiative
--
Nat Sakimura
Chairma= n of the Board, OpenID Foundation
Trustee, Kantara Initiative
--001a113732a474632505326dc940-- From nobody Mon May 9 17:49:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FB912D547; Mon, 9 May 2016 17:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Bb7RmqT8QjNS; Mon, 9 May 2016 17:49:42 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 A30F912D0BD; Mon, 9 May 2016 17:49:39 -0700 (PDT) X-AuditID: 12074425-c7fff70000005f72-41-573130224aa3 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 23.49.24434.22031375; Mon, 9 May 2016 20:49: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 u4A0nbAF013683; Mon, 9 May 2016 20:49:37 -0400 Received: from [10.20.11.38] ([65.115.200.131]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u4A0nUEW015036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 May 2016 20:49:33 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: <57309F46.9040705@tzi.org> Date: Mon, 9 May 2016 19:49:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <89B6F196-D08F-4FBD-9F0D-5B250284048F@mit.edu> References: <57309F46.9040705@tzi.org> To: Carsten Bormann X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsUixG6noqtkYBhusHyDnMX3bz3MFkem3GW1 mLZ1KqvF0p33WC0aduZbXJ5fZHHy7Ss2B3aPiW8/snjsnHWX3WPxpv1sHkuW/GTymLYoM4A1 issmJTUnsyy1SN8ugSvj9K9LbAX9bBW31t5lb2D8xtLFyMkhIWAi8X3ZZCCbi0NIoI1J4lP/ HlYIZwOjxLp5jVCZ1UwSZ6ZcBGthFlCX+DPvEjOIzSugJ7Fp/VsmEFtYIEzix76vrCA2m4Cq xPQ1LWBxTqD6OXPOgPWyCKhI7Pw1mxlkKLPAX0aJ2xOfsEMM1ZZYtvA11FAriUNHVwI1cwBt DpJom2sGEhYRUJK4cHENG8TZshJPTi5imcAoMAvJSbOQnDQLydQFjMyrGGVTcqt0cxMzc4pT k3WLkxPz8lKLdC30cjNL9FJTSjcxgoPeRXUH45y/XocYBTgYlXh4d3AZhguxJpYVV+YeYpTk YFIS5XVl1AsX4kvKT6nMSCzOiC8qzUktPsQowcGsJMJ7Tw+onDclsbIqtSgfJiXNwaIkzsvI wMAgJJCeWJKanZpakFoEk5Xh4FCS4H0A0ihYlJqeWpGWmVOCkGbi4AQZzgM0vBdseHFBYm5x ZjpE/hSjLseCH7fXMgmx5OXnpUqJ8/KBFAmAFGWU5sHNASUrx+ITza8YxYHeEuZl0weq4gEm OrhJr4CWMAEtkWPTB1lSkoiQkmpg5Gk1VtLRu84sejRua9lC4RduyrFLT7PXFZs9lDKUOV/A nRO/7kHC3fMH1HK9nZPi/s/n/cZ/8sbtDONGiadbj7mtN37829fribwIy5rvS50+zdt+fcsh 0Yn7fjx6Oqf3Hkd5l4ybvWvv8aUCzGvaZ9+rNjMv1Jm0Z/GKNB0W9VwdyYuvG29fVGIpzkg0 1GIuKk4EADn0NyMxAwAA Archived-At: Cc: "ace@ietf.org" , "" , cose@ietf.org Subject: Re: [OAUTH-WG] [COSE] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 00:49:44 -0000 We can also call it the =E2=80=9CCOSE Token=E2=80=9D. As a chair of the = COSE working group, I=E2=80=99m fine with that amount of co-branding. =E2=80=94 Justin > On May 9, 2016, at 9:31 AM, Carsten Bormann wrote: >=20 >> draft-ietf-ace-cbor-token-00.txt;=20 >=20 > For the record, I do not think that ACE has a claim on the term "CBOR > Token". While the term token is not used in RFC 7049, there are many > tokens that could be expressed in CBOR or be used in applying CBOR to = a > problem. >=20 > ACE CBOR Token is fine, though. > (Or, better, CBOR ACE Token, CAT.) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose From nobody Mon May 9 19:33:45 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C024B12D589 for ; Mon, 9 May 2016 19:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPPf9n87lzzJ for ; Mon, 9 May 2016 19:33:40 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8FF612D0A1 for ; Mon, 9 May 2016 19:33:40 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id 90so99225669qgz.1 for ; Mon, 09 May 2016 19:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=SAtMcyC/Fan45wRJ0Rp/94Sf5zn3MQsrEMmS6cwxA5Q=; b=NhN/zhTqMqOwYXJ/l8YS6c/GbADupYOLwWacP9FQfe9/X00KIEiVArvGU/a+wNVYx9 AcgARJct7J3Gjy45HO6N+BH/n7J4rUB2z63DhE0G2EOYvNEka7K2jRswUjXTeoUy/rrJ ZwTfA9FY+Y1/2MF31BpFSNxtVJJVLxH/QMS2JnHUg3kWpEvewF4+Y4Egt8oFT5yYxx1u k2M2ioZiQ54J79BbbmHuLFLsGuXsQQXWTP8LT/hIoFQfmITTX0U+7p5EY7Cf3qxDKF60 UzWkIZqLuLROGrwOOXFo5XBm9Xu2kcpsyCmyfPWVpZbzydOUsSVGnIq/Nv5TjtCNyHcJ WtaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SAtMcyC/Fan45wRJ0Rp/94Sf5zn3MQsrEMmS6cwxA5Q=; b=aPGkvmV7w0VsRYh5zeiEWW0cpLIPRD7c+jkSq4K4tMB1C0Y1Gr2NWxJ7bGKB/2WWXS nMrrgmlYUzWcJAsH5Z/ArSGVhHnfY1ZFAslv5dbEzYpRdw1v2TA+AH6wXyyuCD1KJ3XV B99ErniQqk4TmQgbJzuW9DAEX6FZCOXcrVI2TdaKMrnEOSjJ8MF1R+/x4OX3SwVRtopR 0VZLFYHOCgZHTyZYZMC4W0ndvl8WlBnmQb3UpaJgN1G1JZ6Y9vxPvoAbvArA+94p0qX2 GWolXXGJB0x0vGAJlk0g5ERzo2XOVWszpKWIZ+Ctbwur0wIcODYczeHt7fQypu5CER5l D09g== X-Gm-Message-State: AOPr4FXmRMJSa9smO6AXTqWSjD0vSMtj7iROOrlLc2APncyYeXUjcHL9sQ5NrR/mBfmNjV3a5xn8+UMHjQwAew== X-Received: by 10.140.92.65 with SMTP id a59mr37473007qge.93.1462847619804; Mon, 09 May 2016 19:33:39 -0700 (PDT) MIME-Version: 1.0 References: <571A33E0.6070401@uni-trier.de> <5730D36A.4050601@gtrs.de> In-Reply-To: <5730D36A.4050601@gtrs.de> From: Nat Sakimura Date: Tue, 10 May 2016 02:33:30 +0000 Message-ID: To: Guido Schmitz , oauth@ietf.org Content-Type: multipart/alternative; boundary=001a113ab29ebd34ad053273c011 Archived-At: Subject: Re: [OAUTH-WG] Multi-AS State Re-Use X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 02:33:44 -0000 --001a113ab29ebd34ad053273c011 Content-Type: text/plain; charset=UTF-8 As far as I am aware of, state was meant to be nonce. Replay possibility etc. were known. It is probably a bad documentation that every reviewers missed because they were assuming it. Best, Nat On Mon, May 9, 2016 at 20:14 Guido Schmitz wrote: > Hi all, > > can anybody confirm that this is a new / undocumented attack? > > Cheers, > > Guido, Daniel, and Ralf > > On 22.04.2016 16:23, Daniel Fett wrote: > > Hi all, > > > > Besides the state leakage attack we found that another important fact > > regarding state is underspecified: Each state value should only be > > used for one run of the protocol, in particular, each AS should see a > > different state in multi-AS settings. Clients might be tempted to > > generate state once and then re-use each time a user wants to > > authorize. > > > > If state is re-used, given a setup where one Client allows users to > > authorize using two AS, a potentially malicious AS learns the state > > value that is valid for authorization at an honest AS. I.e., each AS > > can mount a CSRF attack on the user using the other AS. > > > > Just as the attack in the other mail, this is not a big deal in > > practice, but should be discussed somewhere. > > > > Cheers, > > Daniel, Guido, and Ralf > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura Chairman of the Board, OpenID Foundation Trustee, Kantara Initiative --001a113ab29ebd34ad053273c011 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As far as I am aware of, state was meant to be nonce. Replay possibility et= c. were known. It is probably a bad documentation that every reviewers miss= ed because they were assuming it.

Best,

Nat
On Mon, May 9, 2016 at 20:14 Guido Schmit= z <g.schmitz@gtrs.de> wrote:=
Hi all,

can anybody confirm that this is a new / undocumented attack?

Cheers,

Guido, Daniel, and Ralf

On 22.04.2016 16:23, Daniel Fett wrote:
> Hi all,
>
> Besides the state leakage attack we found that another important fact<= br> > regarding state is underspecified: Each state value should only be
> used for one run of the protocol, in particular, each AS should see a<= br> > different state in multi-AS settings. Clients might be tempted to
> generate state once and then re-use each time a user wants to
> authorize.
>
> If state is re-used, given a setup where one Client allows users to > authorize using two AS, a potentially malicious AS learns the state > value that is valid for authorization at an honest AS. I.e., each AS > can mount a CSRF attack on the user using the other AS.
>
> Just as the attack in the other mail, this is not a big deal in
> practice, but should be discussed somewhere.
>
> Cheers,
> Daniel, Guido, and Ralf
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura
Chairma= n of the Board, OpenID Foundation
Trustee, Kantara Initiative
--001a113ab29ebd34ad053273c011-- From nobody Mon May 9 22:53:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683E112B044 for ; Mon, 9 May 2016 22:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 QtrOlqW4vdwK for ; Mon, 9 May 2016 22:53:43 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.93]) (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 EA12B12B02C for ; Mon, 9 May 2016 22:53:42 -0700 (PDT) Received: from [80.187.100.168] (helo=[10.19.148.171]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1b00bz-0002Bv-Sw; Tue, 10 May 2016 07:53:40 +0200 Date: Tue, 10 May 2016 07:53:32 +0200 Message-ID: <9i7j68wb5mksvyl9v5pbmmfm.1462859612477@com.syntomo.email> In-Reply-To: References: <571B60BA.8090301@lodderstedt.net> <49355f12-ef58-0637-47e0-7acd54e882d9@lodderstedt.net> From: torsten@lodderstedt.net To: Nat Sakimura MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.syntomo.email_3376154964019450" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 05:53:47 -0000 ----_com.syntomo.email_3376154964019450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgTmF0LAoKd291bGRuJ3QgYSBtYWxld2FyZSBzdGVhbCB0aGUgcmVzcG9uc2UgYW5kIHRoZSBj b29raWVzIGZyb20gdGhlIGRldmljZSBhbmQgcmVwbGF5IGl0IHNvbWV3aGVyZSBlbHNlLiBPciBq dXN0IHN0ZWFsIHRoZSBwYXNzd29yZD8gU28gbm8gbmVlZCB0byB0d2VhayB0aGUgcmVzcG9uc2U/ CgpiZXN0IHJlZ2FyZHMsClRvcnN0ZW4uCgoKLS0tLS0tLS0gT3JpZ2luYWxuYWNocmljaHQgLS0t LS0tLS0KQmV0cmVmZjogUmU6IFtPQVVUSC1XR10gTWl4LVVwIGFuZCBDblAvIENvZGUgaW5qZWN0 aW9uClZvbjogTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+CkFuOiB0b3JzdGVuQGxv ZGRlcnN0ZWR0Lm5ldApDYzoganJpY2hlckBtaXQuZWR1LG9hdXRoQGlldGYub3JnCgo+SGkgVG9y c3RlbiwKPgo+Tm8sIG5vdCBkZWZlYXRpbmcsIGJ1dCBiZWluZyBhYmxlIHRvIGZpbmQgb3V0IGlm IHRoZSBpbnB1dCBpcyB0YWludGVkIG9yCj5ub3QuCj4KPk5hdAo+T24gTW9uLCBNYXkgOSwgMjAx NiBhdCAwNzo0NiA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOgo+Cj4+IEFyZSB5b3Ug c3VnZ2VzdGluZyBPQXV0aCBzaG91bGQgZGVmZWF0IG1hbGV3YXJlPyBTbyBmYXIsIHRoaXMgd2Fz Cj4+IGNvbnNpZGVyZWQgdG8gYmUgaGFuZGxlZCBieSBPUy9BbnRpLVZpcnVzL290aGVyIG1lYXN1 cmVzLgo+Pgo+Pgo+PiAtLS0tLS0tLSBPcmlnaW5hbG5hY2hyaWNodCAtLS0tLS0tLQo+PiBCZXRy ZWZmOiBSZTogW09BVVRILVdHXSBNaXgtVXAgYW5kIENuUC8gQ29kZSBpbmplY3Rpb24KPj4gVm9u OiBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT4KPj4gQW46IFRvcnN0ZW4gTG9kZGVy c3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pgo+PiBDYzogSnVzdGluIFJpY2hlciA8anJp Y2hlckBtaXQuZWR1PiwiPG9hdXRoQGlldGYub3JnPiIgPG9hdXRoQGlldGYub3JnPgo+Pgo+PiBZ ZXMsIGFuZCB1bmZvcnR1bmF0ZWx5LCB0aGF0IGlzIGEgcmF0aGVyIGNvbW1vbiBhdHRhY2sgdGhl c2UgZGF5cy4KPj4gSW5mZXN0aW5nIGEgdXNlciBkZXZpY2Ugd2l0aCBhIG1hbHdhcmUgaXMgcHJv YmFibHkgZWFzaWVyIHRoYW4gaGF2aW5nIHRoZQo+PiBjbGllbnQgZGV2ZWxvcGVyIHJlZ2lzdGVy IGl0cyBjbGllbnQgdG8gdW5rbm93biBzZXJ2ZXIuCj4+Cj4+IDIwMTblubQ15pyIMeaXpSjml6Up IDE2OjU0IFRvcnN0ZW4gTG9kZGVyc3RlZHQgPHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PjoKPj4K Pj4+IEhpIE5hdCwKPj4+Cj4+PiBwbGVhc2UgZXhwbGFpbiB0aGUgYXR0YWNrLiBJIGFzc3VtZSB0 aGUgYXR0YWNrZXIgd291bGQgbmVlZCB0byBjb250cm9sCj4+PiBuZXR3b3JrIHRyYW5zbWlzc2lv biBvciBjbGllbnQgZGV2aWNlLgo+Pj4KPj4+IGtpbmQgcmVnYXJkcywKPj4+IFRvcnN0ZW4uCj4+ Pgo+Pj4gQW0gMDEuMDUuMjAxNiB1bSAwNzozNiBzY2hyaWViIE5hdCBTYWtpbXVyYSA8c2FraW11 cmFAZ21haWwuY29tPjoKPj4+Cj4+PiBJdCBhY3R1YWxseSBkZXBlbmRzIG9uIHdoYXQgcmlzayBs ZXZlbCB0aGUgdHJhbnNhY3Rpb24gaXMgYXQuIEZvciBsb3cKPj4+IHJpc2sgdHJhbnNhY3Rpb25z LCBqdXN0IGhhdmluZyBzZXBhcmF0ZSByZWRpcmVjdGlvbiBlbmRwb2ludCBtYXkgYmUKPj4+IGFk ZXF1YXRlLiBPbiB0aGUgb3RoZXIgaGFuZCwgSSBjYW4gZWFzaWx5IHRoaW5rIG9mIGFuIGF0dGFj ayB0aGF0IHJlcGxhY2VzCj4+PiBpc3Mgb24gdGhlIGF1dGh6IHJlc3BvbnNlIG1ha2luZyB0aGUg Y29udHJvbCBpbnZhbGlkIHBvc2luZyBxdWVzdGlvbnMgb24KPj4+IHdoZXRoZXIgaXQgaXMgd29y dGggaW50cm9kdWNpbmcgaXQuCj4+PiBPbiBTdW4sIE1heSAxLCAyMDE2IGF0IDE0OjIxIEp1c3Rp biBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4gd3JvdGU6Cj4+Pgo+Pj4+IEkgYWdyZWUgdGhhdCB3 ZeKAmXJlIGdldHRpbmcgZGFuZ2Vyb3VzbHkgY2xvc2UgdG8gcmVjb21tZW5kaW5nIHNpZ25lZAo+ Pj4+IGFzc2VydGlvbnMgYXQgZXZlcnkgc3RlcCBvZiB0aGUgcHJvY2VzcywgdGhlcmVieSBieXBh c3NpbmcgSFRUUC4gVGhpcyB3YXMKPj4+PiB0aGUgc2FtZSBtaXN0YWtlIHRoYXQgV1MtKiBhbmQg U09BUCBtYWRlLCBsZXTigJlzIG5vdCByZXBlYXQgaXQgaWYgd2UgY2FuLgo+Pj4+Cj4+Pj4gIOKA lCBKdXN0aW4KPj4+Pgo+Pj4+IE9uIEFwciAzMCwgMjAxNiwgYXQgMTA6NTcgQU0sIFRvcnN0ZW4g TG9kZGVyc3RlZHQgPAo+Pj4+IHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PiB3cm90ZToKPj4+Pgo+ Pj4+IEhpIE5hdCwKPj4+Pgo+Pj4+IHN1cmUsIG9uZSBjb3VsZCBhbHNvIGF1dGhlbnRpY2F0ZSBh bmQgY3J5cHRvZ3JhcGhpY2FsbHkgcHJvdGVjdCB0aGUKPj4+PiByZWRpcmVjdCByZXNwb25zZS4g TGV2ZXJhZ2luZyBPSURDIGNvbmNlcHRzIGlzIGFuIGlkZWEgd29ydGggY29uc2lkZXJpbmcKPj4+ PiBidXQgdGhleSBzaG91bGQgYmUgYWRvcHRlZCB0byB0aGUgT0F1dGggcGhpbG9zb3BoeS4gVGhl IGlkIHRva2VuIGFzIHVzZWQgaW4KPj4+PiB0aGUgaHlicmlkIGZsb3dzIG1peGVzIGFuIGlkZW50 aXR5IGFzc2VydGlvbiB3aXRoIGVsZW1lbnRzIG9mIHRyYW5zcG9ydAo+Pj4+IHNlY3VyaXR5IG1l YXN1cmVzLiBBIE9BdXRoIEFTIGRvZXMgbm90IHByb3ZpZGUgaWRlbnRpdHkgZGF0YSB0byBjbGll bnRzLCBzbwo+Pj4+IHdlIG9ubHkgbmVlZCB0aGUgdHJhbnNwb3J0IHNlY3VyaXR5IHBhcnQuCj4+ Pj4KPj4+PiBJIHBlcnNvbmFsbHkgd291bGQgcHJlZmVyIGEgT0F1dGggcmVzcG9uc2Ugb2JqZWN0 IChzaW1pbGFyIHRvIHJlcXVlc3QKPj4+PiBvYmplY3QgeW91IGhhdmUgcHJvcG9zZWQpIG92ZXIg dGhlIGlkIHRva2VuLiBTdWNoIGEgcmVzcG9uc2Ugb2JqZWN0IGNvdWxkCj4+Pj4gY29udGFpbiAo YW5kIGRpcmVjdGx5IHByb3RlY3QpIHN0YXRlLCBjb2RlIGFuZCBvdGhlciByZXNwb25zZSB2YWx1 ZXMuIEkKPj4+PiBjb25zaWRlciB0aGlzIHRoZSBtb3JlIGVsZWdhbnQgZGVzaWduIGFuZCBpdCBp cyBlYXNpZXIgdG8gaW1wbGVtZW50IHRoZW4KPj4+PiBoYXZpbmcgZGV0YWNoZWQgc2lnbmF0dXJl cyBvdmVyIGhhc2ggdmFsdWVzIG9mIGNvZGVzIG9yIGFjY2VzcyB0b2tlbnMuCj4+Pj4gTW9yZW92 ZXIsIGl0IHdvdWxkIGFsbG93IHRvIGVuY3J5cHQgdGhlIHJlc3BvbnNlIGFzIHdlbGwuCj4+Pj4K Pj4+PiBHZW5lcmFsbHksIG91ciB0aHJlYXQgYW5hbHlzaXMgc28gZmFyIGRvZXMgbm90IGhhdmUg cHJvdmlkZWQKPj4+PiBqdXN0aWZpY2F0aW9uIGZvciBjcnlwdG9ncmFwaGljYWxseSBwcm90ZWN0 ZWQgcmVkaXJlY3QgcmVzcG9uc2VzLiBBbGwKPj4+PiBwcm9wb3NhbHMgY3VycmVudGx5IG9uIHRo ZSB0YWJsZSBzdG9wIG1peCB1cCBhbmQgY29kZSBpbmplY3Rpb24gdXNpbmcKPj4+PiBzaW1wbGVy IG1lY2hhbmlzbXMuCj4+Pj4KPj4+PiBJIHRoaW5rIE9BdXRoIDIuMCBpcyBhIGh1Z2Ugc3VjY2Vz cyBkdWUgdG8gaXRzIGJhbGFuY2Ugb2YgdmVyc2F0aWxpdHksCj4+Pj4gc2VjdXJpdHkgYW5kIF9z aW1wbGljaXR5Xy4gV2UgZGVmaW5pdGVseSBuZWVkIHRvIGtlZXAgaXQgc2VjdXJlLCBidXQgd2UK Pj4+PiBzaG91bGQgYWxzbyBrZWVwIGl0IGFzIHNpbXBsZSBhcyBwb3NzaWJsZS4KPj4+Pgo+Pj4+ IGtpbmQgcmVnYXJkcywKPj4+PiBUb3JzdGVuLgo+Pj4+IEFtIDI5LjA0LjIwMTYgdW0gMTA6MDgg c2NocmllYiBOYXQgU2FraW11cmE6Cj4+Pj4KPj4+PiBBcyBJIGxvb2sgYXQgaXQgbW9yZSBhbmQg bW9yZSwgaXQgc3RhcnRlZCB0byBsb29rIGxpa2UgdGhlIHByb2JsZW0gb2YKPj4+PiBhY2NlcHRp bmcgdGFpbnRlZCB2YWx1ZXMgd2l0aG91dCBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uLiBUbyBmaXgg dGhlIHJvb3QKPj4+PiBjYXVzZSwgd2Ugd291bGQgaGF2ZSB0byBhdXRoZW50aWNhdGUgcmVzcG9u c2UuIElEIFRva2VuIHdhcyBkZXNpZ25lZCB0bwo+Pj4+IGFsc28gc2VydmUgYXMgYSBzb2x1dGlv biBhbnRpY2lwYXRpbmcgaXQuCj4+Pj4KPj4+PiBBbnkgY29uY3JldGUgaWRlYXM/Cj4+Pj4KPj4+ PiBPbiBTYXQsIEFwciAyMywgMjAxNiBhdCAwNDo0NyBUb3JzdGVuIExvZGRlcnN0ZWR0IDwKPj4+ PiB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6Cj4+Pj4KPj4+Pj4gSGkgYWxsLAo+Pj4+ Pgo+Pj4+PiBkaXNjdXNzaW9uIGFib3V0IE1peC1VcCBhbmQgQ25QIHNlZW1zIHRvIGhhdmUgc3Rv cHBlZCBhZnRlciB0aGUgc2Vzc2lvbgo+Pj4+PiBpbiBCQSAtIGF0IGxlYXN0IGluIHRoZSBPQXV0 aCBXRy4gVGhlcmUgaXMgYSBkaXNjdXNzaW9uIGFib3V0Cj4+Pj4+IG1pdGlnYXRpb25zIGluIE9w ZW5JZCBDb25uZWN0IGdvaW5nIG9uIGF0IHRoZSBPcGVuSWQgQ29ubmVjdCBtYWlsaW5nCj4+Pj4+ IGxpc3QuCj4+Pj4+Cj4+Pj4+IEknbSB2ZXJ5IG11Y2ggaW50ZXJlc3RlZCB0byBmaW5kIGEgc29s dXRpb24gd2l0aGluIHRoZSBPQXV0aCByZWFsbSBhcwo+Pj4+PiBJJ20gbm90IGludGVyZXN0ZWQg dG8gZWl0aGVyIGltcGxlbWVudCB0d28gc29sdXRpb25zIChmb3IgT3BlbklkIENvbm5lY3QKPj4+ Pj4gYW5kIE9BdXRoKSBvciBhZG9wdCBhIE9wZW5JZC1zcGVjaWZpYyBzb2x1dGlvbiB0byBPQXV0 aCAodXNlIGlkISB0b2tlbnMKPj4+Pj4gaW4gdGhlIGZyb250IGNoYW5uZWwpLiBJIHRoZXJlZm9y ZSB3b3VsZCBsaWtlIHRvIHNlZSBwcm9ncmVzcyBhbmQKPj4+Pj4gcHJvcG9zZSB0byBjb250aW51 ZSB0aGUgZGlzY3Vzc2lvbiByZWdhcmRpbmcgbWl0aWdhdGlvbnMgZm9yIGJvdGgKPj4+Pj4gdGhy ZWF0cy4KPj4+Pj4KPj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b2F1dGgtbWl4LXVwLW1pdGlnYXRpb24tMDAKPj4+Pj4gcHJvcG9zZXMgcmVhc29uYWJsZSBtaXRp Z2F0aW9ucyBmb3IgYm90aCBhdHRhY2tzLiBUaGVyZSBhcmUgYWx0ZXJuYXRpdmVzCj4+Pj4+IGFz IHdlbGw6Cj4+Pj4+IC0gbWl4IHVwOgo+Pj4+PiAtLSBBUyBzcGVjaWZpYyByZWRpcmVjdCB1cmlz Cj4+Pj4+IC0tIE1ldGEgZGF0YS90dXJpCj4+Pj4+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wNyNzZWN0aW9uLTUpCj4+Pj4+IC0gQ25QOgo+ Pj4+PiAtLSB1c2Ugb2YgdGhlIG5vbmNlIHBhcmFtZXRlciAoYXMgYSBkaXN0aW5jdCBtaXRpZ2F0 aW9uIGJlc2lkZSBzdGF0ZSBmb3IKPj4+Pj4gY291bnRlciBYU1JGKQo+Pj4+Pgo+Pj4+PiBBbnlv bmUgaGF2aW5nIGFuIG9waW5pb24/Cj4+Pj4+Cj4+Pj4+IGJlc3QgcmVnYXJkcywKPj4+Pj4gVG9y c3Rlbi4KPj4+Pj4KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPj4+Pj4gT0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4+IE9BdXRoQGlldGYub3JnCj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgKPj4+Pj4KPj4+ Pgo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+ Pj4gT0F1dGggbWFpbGluZyBsaXN0Cj4+Pj4gT0F1dGhAaWV0Zi5vcmcKPj4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCj4+Pj4KPj4+Pgo+Pj4+IC0tCj4+IE5h dCBTYWtpbXVyYQo+PiBDaGFpcm1hbiBvZiB0aGUgQm9hcmQsIE9wZW5JRCBGb3VuZGF0aW9uCj4+ IFRydXN0ZWUsIEthbnRhcmEgSW5pdGlhdGl2ZQo+Pgo+LS0gCj5OYXQgU2FraW11cmEKPkNoYWly bWFuIG9mIHRoZSBCb2FyZCwgT3BlbklEIEZvdW5kYXRpb24KPlRydXN0ZWUsIEthbnRhcmEgSW5p dGlhdGl2ZQo= ----_com.syntomo.email_3376154964019450 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHAgZGlyPSJsdHIiPkhpIE5hdCw8L3A+CjxwIGRpcj0ibHRyIj53b3VsZG4ndCBhIG1hbGV3YXJl IHN0ZWFsIHRoZSByZXNwb25zZSBhbmQgdGhlIGNvb2tpZXMgZnJvbSB0aGUgZGV2aWNlIGFuZCBy ZXBsYXkgaXQgc29tZXdoZXJlIGVsc2UuIE9yIGp1c3Qgc3RlYWwgdGhlIHBhc3N3b3JkPyBTbyBu byBuZWVkIHRvIHR3ZWFrIHRoZSByZXNwb25zZT88L3A+CjxwIGRpcj0ibHRyIj5iZXN0IHJlZ2Fy ZHMsPGJyPgpUb3JzdGVuLjxicj4KPC9wPgo8YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsbmFjaHJp Y2h0IC0tLS0tLS0tPGJyPkJldHJlZmY6IFJlOiBbT0FVVEgtV0ddIE1peC1VcCBhbmQgQ25QLyBD b2RlIGluamVjdGlvbjxicj5Wb246IE5hdCBTYWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29t Jmd0Ozxicj5BbjogdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ8YnI+Q2M6IGpyaWNoZXJAbWl0LmVk dSxvYXV0aEBpZXRmLm9yZzxicj48YnI+SGkgVG9yc3RlbiwgPGJyPjxicj5Obywgbm90IGRlZmVh dGluZywgYnV0IGJlaW5nIGFibGUgdG8gZmluZCBvdXQgaWYgdGhlIGlucHV0IGlzIHRhaW50ZWQg b3Igbm90LiA8YnI+PGJyPk5hdDxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9 Imx0ciI+T24gTW9uLCBNYXkgOSwgMjAxNiBhdCAwNzo0NiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRv cnN0ZW5AbG9kZGVyc3RlZHQubmV0Ij50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDwvYT4mZ3Q7IHdy b3RlOjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 Ij48cCBkaXI9Imx0ciI+QXJlIHlvdSBzdWdnZXN0aW5nIE9BdXRoIHNob3VsZCBkZWZlYXQgbWFs ZXdhcmU/IFNvIGZhciwgdGhpcyB3YXMgY29uc2lkZXJlZCB0byBiZSBoYW5kbGVkIGJ5IE9TL0Fu dGktVmlydXMvb3RoZXIgbWVhc3VyZXMuIDxicj4NCjwvcD4NCjxicj48YnI+LS0tLS0tLS0gT3Jp Z2luYWxuYWNocmljaHQgLS0tLS0tLS08YnI+QmV0cmVmZjogUmU6IFtPQVVUSC1XR10gTWl4LVVw IGFuZCBDblAvIENvZGUgaW5qZWN0aW9uPGJyPlZvbjogTmF0IFNha2ltdXJhICZsdDs8YSBocmVm PSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21h aWwuY29tPC9hPiZndDs8YnI+QW46IFRvcnN0ZW4gTG9kZGVyc3RlZHQgJmx0OzxhIGhyZWY9Im1h aWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnRvcnN0ZW5AbG9k ZGVyc3RlZHQubmV0PC9hPiZndDs8YnI+Q2M6IEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+ Jmd0OywmcXVvdDsmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0OyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9h dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj48 YnI+PGRpdiBkaXI9Imx0ciI+WWVzLCBhbmQgdW5mb3J0dW5hdGVseSwgdGhhdCBpcyBhIHJhdGhl ciBjb21tb24gYXR0YWNrIHRoZXNlIGRheXMuwqA8ZGl2PkluZmVzdGluZyBhIHVzZXIgZGV2aWNl IHdpdGggYSBtYWx3YXJlIGlzIHByb2JhYmx5IGVhc2llciB0aGFuIGhhdmluZyB0aGUgY2xpZW50 IGRldmVsb3BlciByZWdpc3RlciBpdHMgY2xpZW50IHRvIHVua25vd24gc2VydmVyLsKgPGJyPjxk aXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IGRpcj0ibHRyIj4yMDE25bm0Neac iDHml6Uo5pelKSAxNjo1NCBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDs8YSBocmVmPSJtYWlsdG86 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0 ZWR0Lm5ldDwvYT4mZ3Q7Ojxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk aW5nLWxlZnQ6MWV4Ij48ZGl2IGRpcj0iYXV0byI+PGRpdj48L2Rpdj48ZGl2PkhpIE5hdCw8L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PnBsZWFzZSBleHBsYWluIHRoZSBhdHRhY2suIEkgYXNzdW1l IHRoZSBhdHRhY2tlciB3b3VsZCBuZWVkIHRvIGNvbnRyb2wgbmV0d29yayB0cmFuc21pc3Npb24g b3IgY2xpZW50IGRldmljZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmtpbmQgcmVnYXJkcyw8 L2Rpdj48ZGl2PlRvcnN0ZW4uPC9kaXY+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxkaXY+PGJyPkFt IDAxLjA1LjIwMTYgdW0gMDc6MzYgc2NocmllYiBOYXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1h aWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5j b208L2E+Jmd0Ozo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+SXQg YWN0dWFsbHkgZGVwZW5kcyBvbiB3aGF0IHJpc2sgbGV2ZWwgdGhlIHRyYW5zYWN0aW9uIGlzIGF0 LiBGb3IgbG93IHJpc2sgdHJhbnNhY3Rpb25zLCBqdXN0IGhhdmluZyBzZXBhcmF0ZSByZWRpcmVj dGlvbiBlbmRwb2ludCBtYXkgYmUgYWRlcXVhdGUuIE9uIHRoZSBvdGhlciBoYW5kLCBJIGNhbiBl YXNpbHkgdGhpbmsgb2YgYW4gYXR0YWNrIHRoYXQgcmVwbGFjZXMgaXNzIG9uIHRoZSBhdXRoeiBy ZXNwb25zZSBtYWtpbmcgdGhlIGNvbnRyb2wgaW52YWxpZCBwb3NpbmcgcXVlc3Rpb25zIG9uIHdo ZXRoZXIgaXQgaXMgd29ydGggaW50cm9kdWNpbmcgaXQuIDxicj48ZGl2IGNsYXNzPSJnbWFpbF9x dW90ZSI+PGRpdiBkaXI9Imx0ciI+T24gU3VuLCBNYXkgMSwgMjAxNiBhdCAxNDoyMSBKdXN0aW4g UmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFu ayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVh ay13b3JkIj5JIGFncmVlIHRoYXQgd2XigJlyZSBnZXR0aW5nIGRhbmdlcm91c2x5IGNsb3NlIHRv IHJlY29tbWVuZGluZyBzaWduZWQgYXNzZXJ0aW9ucyBhdCBldmVyeSBzdGVwIG9mIHRoZSBwcm9j ZXNzLCB0aGVyZWJ5IGJ5cGFzc2luZyBIVFRQLiBUaGlzIHdhcyB0aGUgc2FtZSBtaXN0YWtlIHRo YXQgV1MtKiBhbmQgU09BUCBtYWRlLCBsZXTigJlzIG5vdCByZXBlYXQgaXQgaWYgd2UgY2FuLjwv ZGl2PjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj48ZGl2Pjxicj48L2Rpdj48ZGl2 PsKg4oCUIEp1c3RpbjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk Ij48ZGl2Pjxicj48ZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+T24gQXByIDMwLCAy MDE2LCBhdCAxMDo1NyBBTSwgVG9yc3RlbiBMb2RkZXJzdGVkdCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+dG9yc3RlbkBsb2RkZXJz dGVkdC5uZXQ8L2E+Jmd0OyB3cm90ZTo8L2Rpdj48YnI+PGRpdj4NCg0KICANCiAgPGRpdiBiZ2Nv bG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj48cD5IaSBOYXQsPC9wPjxwPnN1cmUsIG9uZSBj b3VsZCBhbHNvIGF1dGhlbnRpY2F0ZSBhbmQgY3J5cHRvZ3JhcGhpY2FsbHkgcHJvdGVjdA0KICAg ICAgdGhlIHJlZGlyZWN0IHJlc3BvbnNlLiBMZXZlcmFnaW5nIE9JREMgY29uY2VwdHMgaXMgYW4g aWRlYSB3b3J0aA0KICAgICAgY29uc2lkZXJpbmcgYnV0IHRoZXkgc2hvdWxkIGJlIGFkb3B0ZWQg dG8gdGhlIE9BdXRoIHBoaWxvc29waHkuDQogICAgICBUaGUgaWQgdG9rZW4gYXMgdXNlZCBpbiB0 aGUgaHlicmlkIGZsb3dzIG1peGVzIGFuIGlkZW50aXR5DQogICAgICBhc3NlcnRpb24gd2l0aCBl bGVtZW50cyBvZiB0cmFuc3BvcnQgc2VjdXJpdHkgbWVhc3VyZXMuIEEgT0F1dGggQVMNCiAgICAg IGRvZXMgbm90IHByb3ZpZGUgaWRlbnRpdHkgZGF0YSB0byBjbGllbnRzLCBzbyB3ZSBvbmx5IG5l ZWQgdGhlDQogICAgICB0cmFuc3BvcnQgc2VjdXJpdHkgcGFydC4gPGJyPg0KICAgIDwvcD48cD5J IHBlcnNvbmFsbHkgd291bGQgcHJlZmVyIGEgT0F1dGggcmVzcG9uc2Ugb2JqZWN0IChzaW1pbGFy IHRvDQogICAgICByZXF1ZXN0IG9iamVjdCB5b3UgaGF2ZSBwcm9wb3NlZCkgb3ZlciB0aGUgaWQg dG9rZW4uIFN1Y2ggYQ0KICAgICAgcmVzcG9uc2Ugb2JqZWN0IGNvdWxkIGNvbnRhaW4gKGFuZCBk aXJlY3RseSBwcm90ZWN0KSBzdGF0ZSwgY29kZQ0KICAgICAgYW5kIG90aGVyIHJlc3BvbnNlIHZh bHVlcy4gSSBjb25zaWRlciB0aGlzIHRoZSBtb3JlIGVsZWdhbnQgZGVzaWduDQogICAgICBhbmQg aXQgaXMgZWFzaWVyIHRvIGltcGxlbWVudCB0aGVuIGhhdmluZyBkZXRhY2hlZCBzaWduYXR1cmVz IG92ZXINCiAgICAgIGhhc2ggdmFsdWVzIG9mIGNvZGVzIG9yIGFjY2VzcyB0b2tlbnMuIE1vcmVv dmVyLCBpdCB3b3VsZCBhbGxvdyB0bw0KICAgICAgZW5jcnlwdCB0aGUgcmVzcG9uc2UgYXMgd2Vs bC4gPGJyPg0KICAgIDwvcD48cD5HZW5lcmFsbHksIG91ciB0aHJlYXQgYW5hbHlzaXMgc28gZmFy IGRvZXMgbm90IGhhdmUgcHJvdmlkZWQNCiAgICAgIGp1c3RpZmljYXRpb24gZm9yIGNyeXB0b2dy YXBoaWNhbGx5IHByb3RlY3RlZCByZWRpcmVjdCByZXNwb25zZXMuDQogICAgICBBbGwgcHJvcG9z YWxzIGN1cnJlbnRseSBvbiB0aGUgdGFibGUgc3RvcCBtaXggdXAgYW5kIGNvZGUNCiAgICAgIGlu amVjdGlvbiB1c2luZyBzaW1wbGVyIG1lY2hhbmlzbXMuIDxicj4NCiAgICA8L3A+PHA+SSB0aGlu ayBPQXV0aCAyLjAgaXMgYSBodWdlIHN1Y2Nlc3MgZHVlIHRvIGl0cyBiYWxhbmNlIG9mDQogICAg ICB2ZXJzYXRpbGl0eSwgc2VjdXJpdHkgYW5kIF9zaW1wbGljaXR5Xy4gV2UgZGVmaW5pdGVseSBu ZWVkIHRvIGtlZXANCiAgICAgIGl0IHNlY3VyZSwgYnV0IHdlIHNob3VsZCBhbHNvIGtlZXAgaXQg YXMgc2ltcGxlIGFzIHBvc3NpYmxlLjxicj4NCiAgICA8L3A+PHA+a2luZCByZWdhcmRzLDxicj4N CiAgICAgIFRvcnN0ZW4uPGJyPg0KICAgIDwvcD4NCiAgICA8ZGl2PkFtIDI5LjA0LjIwMTYgdW0g MTA6MDggc2NocmllYiBOYXQNCiAgICAgIFNha2ltdXJhOjxicj4NCiAgICA8L2Rpdj4NCiAgICA8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5BcyBJIGxvb2sgYXQgaXQgbW9yZSBhbmQgbW9yZSwgaXQg c3RhcnRlZCB0byBsb29rIGxpa2UNCiAgICAgIHRoZSBwcm9ibGVtIG9mIGFjY2VwdGluZyB0YWlu dGVkIHZhbHVlcyB3aXRob3V0IG1lc3NhZ2UNCiAgICAgIGF1dGhlbnRpY2F0aW9uLiBUbyBmaXgg dGhlIHJvb3QgY2F1c2UsIHdlIHdvdWxkIGhhdmUgdG8NCiAgICAgIGF1dGhlbnRpY2F0ZSByZXNw b25zZS4gSUQgVG9rZW4gd2FzIGRlc2lnbmVkIHRvIGFsc28gc2VydmUgYXMgYQ0KICAgICAgc29s dXRpb24gYW50aWNpcGF0aW5nIGl0LiA8YnI+DQogICAgICA8YnI+DQogICAgICBBbnkgY29uY3Jl dGUgaWRlYXM/IDxicj4NCiAgICAgIDxicj4NCiAgICAgIDxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl Ij4NCiAgICAgICAgPGRpdiBkaXI9Imx0ciI+T24gU2F0LCBBcHIgMjMsIDIwMTYgYXQgMDQ6NDcg VG9yc3RlbiBMb2RkZXJzdGVkdA0KICAgICAgICAgICZsdDs8YSBocmVmPSJtYWlsdG86dG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXQiIHRhcmdldD0iX2JsYW5rIj50b3JzdGVuQGxvZGRlcnN0ZWR0Lm5l dDwvYT4mZ3Q7DQogICAgICAgICAgd3JvdGU6PGJyPg0KICAgICAgICA8L2Rpdj4NCiAgICAgICAg PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+SGkgYWxsLDxicj4N CiAgICAgICAgICA8YnI+DQogICAgICAgICAgZGlzY3Vzc2lvbiBhYm91dCBNaXgtVXAgYW5kIENu UCBzZWVtcyB0byBoYXZlIHN0b3BwZWQgYWZ0ZXINCiAgICAgICAgICB0aGUgc2Vzc2lvbjxicj4N CiAgICAgICAgICBpbiBCQSAtIGF0IGxlYXN0IGluIHRoZSBPQXV0aCBXRy4gVGhlcmUgaXMgYSBk aXNjdXNzaW9uIGFib3V0PGJyPg0KICAgICAgICAgIG1pdGlnYXRpb25zIGluIE9wZW5JZCBDb25u ZWN0IGdvaW5nIG9uIGF0IHRoZSBPcGVuSWQgQ29ubmVjdA0KICAgICAgICAgIG1haWxpbmcgbGlz dC48YnI+DQogICAgICAgICAgPGJyPg0KICAgICAgICAgIEkmIzM5O20gdmVyeSBtdWNoIGludGVy ZXN0ZWQgdG8gZmluZCBhIHNvbHV0aW9uIHdpdGhpbiB0aGUgT0F1dGgNCiAgICAgICAgICByZWFs bSBhczxicj4NCiAgICAgICAgICBJJiMzOTttIG5vdCBpbnRlcmVzdGVkIHRvIGVpdGhlciBpbXBs ZW1lbnQgdHdvIHNvbHV0aW9ucyAoZm9yDQogICAgICAgICAgT3BlbklkIENvbm5lY3Q8YnI+DQog ICAgICAgICAgYW5kIE9BdXRoKSBvciBhZG9wdCBhIE9wZW5JZC1zcGVjaWZpYyBzb2x1dGlvbiB0 byBPQXV0aCAodXNlDQogICAgICAgICAgaWQhIHRva2Vuczxicj4NCiAgICAgICAgICBpbiB0aGUg ZnJvbnQgY2hhbm5lbCkuIEkgdGhlcmVmb3JlIHdvdWxkIGxpa2UgdG8gc2VlIHByb2dyZXNzDQog ICAgICAgICAgYW5kPGJyPg0KICAgICAgICAgIHByb3Bvc2UgdG8gY29udGludWUgdGhlIGRpc2N1 c3Npb24gcmVnYXJkaW5nIG1pdGlnYXRpb25zIGZvcg0KICAgICAgICAgIGJvdGggdGhyZWF0cy48 YnI+DQogICAgICAgICAgPGJyPg0KICAgICAgICAgIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLW1peC11cC1taXRpZ2F0aW9uLTAwIiByZWw9Im5v cmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1vYXV0aC1taXgtdXAtbWl0aWdhdGlvbi0wMDwvYT48YnI+DQogICAgICAgICAgcHJv cG9zZXMgcmVhc29uYWJsZSBtaXRpZ2F0aW9ucyBmb3IgYm90aCBhdHRhY2tzLiBUaGVyZSBhcmUN CiAgICAgICAgICBhbHRlcm5hdGl2ZXM8YnI+DQogICAgICAgICAgYXMgd2VsbDo8YnI+DQogICAg ICAgICAgLSBtaXggdXA6PGJyPg0KICAgICAgICAgIC0tIEFTIHNwZWNpZmljIHJlZGlyZWN0IHVy aXM8YnI+DQogICAgICAgICAgLS0gTWV0YSBkYXRhL3R1cmk8YnI+DQogICAgICAgICAgKDxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRh LTA3I3NlY3Rpb24tNSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDcjc2VjdGlvbi01 PC9hPik8YnI+DQogICAgICAgICAgLSBDblA6PGJyPg0KICAgICAgICAgIC0tIHVzZSBvZiB0aGUg bm9uY2UgcGFyYW1ldGVyIChhcyBhIGRpc3RpbmN0IG1pdGlnYXRpb24gYmVzaWRlDQogICAgICAg ICAgc3RhdGUgZm9yPGJyPg0KICAgICAgICAgIGNvdW50ZXIgWFNSRik8YnI+DQogICAgICAgICAg PGJyPg0KICAgICAgICAgIEFueW9uZSBoYXZpbmcgYW4gb3Bpbmlvbj88YnI+DQogICAgICAgICAg PGJyPg0KICAgICAgICAgIGJlc3QgcmVnYXJkcyw8YnI+DQogICAgICAgICAgVG9yc3Rlbi48YnI+ DQogICAgICAgICAgPGJyPg0KICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KICAgICAgICAgIE9BdXRoIG1haWxpbmcgbGlzdDxicj4N CiAgICAgICAgICA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQogICAgICAgICAgPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48 YnI+DQogICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgIDwvZGl2Pg0KICAgIDwvYmxvY2txdW90 ZT4NCiAgICA8YnI+DQogIDwvZGl2Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRv Ok9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h Pjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90 ZT48L2Rpdj4NCjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+PGRpdiBkaXI9Imx0ciI+LS0gPGJyPjwvZGl2PjxkaXYgZGlyPSJsdHIi PjxkaXYgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOnNtYWxsO2xpbmUtaGVpZ2h0 OjE5LjVweCI+TmF0IFNha2ltdXJhPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtm b250LXNpemU6c21hbGw7bGluZS1oZWlnaHQ6MTkuNXB4Ij5DaGFpcm1hbiBvZiB0aGUgQm9hcmQs IE9wZW5JRCBGb3VuZGF0aW9uPC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250 LXNpemU6c21hbGw7bGluZS1oZWlnaHQ6MTkuNXB4Ij5UcnVzdGVlLCBLYW50YXJhIEluaXRpYXRp dmU8L2Rpdj48L2Rpdj4NCjwvYmxvY2txdW90ZT48L2Rpdj48ZGl2IGRpcj0ibHRyIj4tLSA8YnI+ PC9kaXY+PGRpdiBkaXI9Imx0ciI+PGRpdiBzdHlsZT0iY29sb3I6cmdiKDAsMCwwKTtmb250LXNp emU6c21hbGw7bGluZS1oZWlnaHQ6MTkuNXB4Ij5OYXQgU2FraW11cmE8L2Rpdj48ZGl2IHN0eWxl PSJjb2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZTpzbWFsbDtsaW5lLWhlaWdodDoxOS41cHgiPkNo YWlybWFuIG9mIHRoZSBCb2FyZCwgT3BlbklEIEZvdW5kYXRpb248L2Rpdj48ZGl2IHN0eWxlPSJj b2xvcjpyZ2IoMCwwLDApO2ZvbnQtc2l6ZTpzbWFsbDtsaW5lLWhlaWdodDoxOS41cHgiPlRydXN0 ZWUsIEthbnRhcmEgSW5pdGlhdGl2ZTwvZGl2PjwvZGl2Pg0K ----_com.syntomo.email_3376154964019450-- From nobody Tue May 10 00:25:55 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99E912D0C0 for ; Tue, 10 May 2016 00:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 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_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=alexbilbie-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvQSu9W5SEm8 for ; Tue, 10 May 2016 00:25:50 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0359A12D188 for ; Tue, 10 May 2016 00:25:49 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id u64so4718639lff.3 for ; Tue, 10 May 2016 00:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alexbilbie-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=UIY0xUP56EbyDPr3X0f8NczDDp1wEj+6ijqgnehvRC8=; b=UQmk/Hm0JdjUhWX+RYACsHW/92o6vh/GyRCMOKlxqm2ll+37AIBNCfvKiietmTISJU 3Y2x+7s9kE70iS22b+pVLYYmiHGVsHvxupTPzC+qhRYXAYhmEFIQ+xCpRWlFLdoOyV+7 bdxugDNtgDve7qm0pOb4oT/OWpkvSfzip0KiVI/36XIF2mmPXE15YoOUGfmgaxJ50Qf7 dtl/FVqOTTOS+DLrKhywrRaE+rkEiCXadUk8I07EZhNjFHzvgcvcsU+VIUgFYKsRegi9 RJE8Ap4d8QXv0XegLsUuoysddu4DyRgnrapwKeR0m0fUOUt4bXYOveEv+c1DK0XaDg4f BA/g== 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; bh=UIY0xUP56EbyDPr3X0f8NczDDp1wEj+6ijqgnehvRC8=; b=TehrycW78feSPf6OYVmZVeUwQMSUkfHFzFhMlP5h/QVv5NSFSI8iqJWpuVgT3f5flu TLI6qk+qY6MNEkL5jOvdlsrC5mdLLOQVd1jPGPQpQlhijL2eJBVF406zbEeZIu9/5i4q dPBnO19SUD6fzJ4FkdpgJFE137LGVYWAP7508MhljrCT6IWOOtw4zyiAPvX9DwKXRtn3 DWV+J2fzSzpU8YbKOYeRMr/sWUYM2QJiXBEWBdnLwwSFzIUWGtvdMFgbIevbfs3LaNRd g6rglFLiSKmr7heOcO9uZfEZ8KrX+F1nRpsKBydw6mMFg9kFQ/zd/nyp5f8sG7J4/Z57 1Xsg== X-Gm-Message-State: AOPr4FXSxnzPlUzC4K/4d/b5whiU6M8f1Xy3PZJUl45Sg049uL4KvZ9F+cFrAtr5xiEHvwRULnbq4K5sh/Mk+Q== X-Received: by 10.25.18.215 with SMTP id 84mr16259152lfs.154.1462865147943; Tue, 10 May 2016 00:25:47 -0700 (PDT) MIME-Version: 1.0 From: Alex Bilbie Date: Tue, 10 May 2016 07:25:38 +0000 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a114082127f710f053277d5f1 Archived-At: Subject: Re: [OAUTH-WG] OAuth Device Flow data from Microsoft implementations X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 07:25:53 -0000 --001a114082127f710f053277d5f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mike, Some interesting feedback. > One of the two implementations has an optional =E2=80=9Cmessage=E2=80=9D = parameter > containing text that is to be shown to the user. This one also uses a > =E2=80=9Cmkt=E2=80=9D parameter to indicate the locale of the message (as= opposed to, for > instance, ui_locales). The developers want to know what the working grou= p > thinks of the possibility of supporting some kind of a =E2=80=9Cmessage= =E2=80=9D parameter. In our test implementation we're serving a localised message parameter by interpreting the Accept-Language request header. I agree that an optional message parameter should be part of the specification. Alex On Sun, 8 May 2016 at 06:27 Mike Jones wrote: > I sat down with the two Microsoft teams that have implementations of the > OAuth Device Flow and compared what they currently have built to > draft-ietf-oauth-device-flow. Here=E2=80=99s some data that we assembled= =E2=80=A6 > > > > One of the two implementations has an optional =E2=80=9Cmessage=E2=80=9D = parameter > containing text that is to be shown to the user. This one also uses a > =E2=80=9Cmkt=E2=80=9D parameter to indicate the locale of the message (as= opposed to, for > instance, ui_locales). The developers want to know what the working grou= p > thinks of the possibility of supporting some kind of a =E2=80=9Cmessage= =E2=80=9D parameter. > > > > The developers would like an example in the spec that shows the use of > simple polling. > > > > We are using the =E2=80=9Cdevice_code=E2=80=9D grant type. The token req= uest is missing > from the spec, including the grant type being missing from the spec. > > > > One implementation adds two new errors: auth_pending and > expired_device_code. (The spec uses authorization_pending.) This > implementation also uses the access_denied error defined by RFC 6749. > > > > The other uses authorization_pending, code_expired, and > authorization_declined. The developers agreed that authorization_decline= d > should become access_denied. That implementation hasn=E2=80=99t implemen= ted > slow_down. > > > > The developers wanted to ask what the right code expiration error code > is. They felt that invalid_grant may be a bit too broad. > > > > Our requests in both implementations do match the specification. > > > > Our implementations currently use verification_url instead of > verification_uri. This should be changed to verification_uri to match IE= TF > naming practices. > > > > Our default expires_in is 900 (15 minutes). Our default interval is 5 > seconds. > > > > Both implementations do intend to migrate to the syntax in the eventual > final specification. > > > > -- Mike > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a114082127f710f053277d5f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mike,

Some interesting fe= edback.
=C2=A0
One of the = two implementations has an optional =E2=80=9Cmessage=E2=80=9D parameter con= taining text that is to be shown to the user.=C2=A0 This one also uses a = =E2=80=9Cmkt=E2=80=9D parameter to indicate the locale of the message (as o= pposed to, for instance, ui_locales).=C2=A0 The developers want to know wha= t the working group thinks of the possibility of supporting some kind of a = =E2=80=9Cmessage=E2=80=9D parameter.

In our test implementation we're serving a localised m= essage parameter by interpreting the=C2=A0Accept-Language request header.

I agree that an optional message parameter should b= e part of the specification.

Alex

On Sun, 8 May 2016 at 06:27 Mike Jones <Michael.Jones@microsoft.com&g= t; wrote:

I sat down with the two Microsoft teams that have im= plementations of the OAuth Device Flow and compared what they currently hav= e built to draft-ietf-oauth-device-flow.=C2=A0 Here=E2=80=99s some data tha= t we assembled=E2=80=A6

=C2=A0

One of the two implementations has an optional =E2= =80=9Cmessage=E2=80=9D parameter containing text that is to be shown to the= user.=C2=A0 This one also uses a =E2=80=9Cmkt=E2=80=9D parameter to indica= te the locale of the message (as opposed to, for instance, ui_locales).=C2= =A0 The developers want to know what the working group thinks of the possibili= ty of supporting some kind of a =E2=80=9Cmessage=E2=80=9D parameter.=

=C2=A0

The developers would like an example in the spec tha= t shows the use of simple polling.

=C2=A0

We are using the =E2=80=9Cdevice_code=E2=80=9D grant= type.=C2=A0 The token request is missing from the spec, including the gran= t type being missing from the spec.

=C2=A0

One implementation adds two new errors: auth_pending= and expired_device_code.=C2=A0 (The spec uses authorization_pending.)=C2= =A0 This implementation also uses the access_denied error defined by RFC 67= 49.

=C2=A0

The other uses authorization_pending, code_expired, = and authorization_declined.=C2=A0 The developers agreed that authorization_= declined should become access_denied.=C2=A0 That implementation hasn=E2=80= =99t implemented slow_down.

=C2=A0

The developers wanted to ask what the right code exp= iration error code is.=C2=A0 They felt that invalid_grant may be a bit too = broad.

=C2=A0

Our requests in both implementations do match the sp= ecification.

=C2=A0

Our implementations currently use verification_url i= nstead of verification_uri.=C2=A0 This should be changed to verification_ur= i to match IETF naming practices.

=C2=A0

Our default expires_in is 900 (15 minutes).=C2=A0 Ou= r default interval is 5 seconds.

=C2=A0

Both implementations do intend to migrate to the syn= tax in the eventual final specification.

=C2=A0

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

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a114082127f710f053277d5f1-- From nobody Tue May 10 00:31:57 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F7012D1BE for ; Tue, 10 May 2016 00:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJhBrRccJm4Q for ; Tue, 10 May 2016 00:31:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050FD12D1BC for ; Tue, 10 May 2016 00:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=G/WTn7QK6wo8vV31VVgvrqnas2rv14VwvQKKoVW4lPM=; b=DeNn08xjakHpT4o2vHJeUgZu7NiunNAclKavAkSCEvRb2WukHMSl4PbWRxUSfFs+Rl0VTYipCLOg2de3U9ys9clTwDnlf/e2tHvRqPbnMUW4l28a7Gm35ay+7IHzw/sNykyJ8Kg2ri7Ta6bW3CzLBPRQPYkVlk+7u9wcfYlLjyM= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1233.namprd03.prod.outlook.com (10.161.207.21) with Microsoft SMTP Server (TLS) id 15.1.492.11; Tue, 10 May 2016 07:31:37 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0492.016; Tue, 10 May 2016 07:31:36 +0000 From: Anthony Nadalin To: Nat Sakimura , Guido Schmitz , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Multi-AS State Re-Use Thread-Index: AQHRnKKPwSTx3OpGmU6RU+/LjreJi5+xA9sAgACLjQCAAFLzkA== Date: Tue, 10 May 2016 07:31:36 +0000 Message-ID: References: <571A33E0.6070401@uni-trier.de> <5730D36A.4050601@gtrs.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [213.221.117.233] x-ms-office365-filtering-correlation-id: faf9a476-105c-47a3-5282-08d378a51ea0 x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1233; 5:mtTaC8Hlqq0/w1GiK2vDFXKG5OgPdJ79s1x404q1u3WgdYIBXjn+HJoRLh9yE30Qk5u5uSJcbzVq6YMQHZLD+mND2tAe8bh2Jx9v45xl0iAQt4r1Jnbyka0yR9nEKY5IWMI/X1MPbZBdHrDpGWzXNg==; 24:BPZkYcRnTfyf1uMG2IMdbAcRvwStaY9cj/2oYqCvSx2cspaxpAjb4b9gtBluIYpjVYcNQHrKAKrZ14wLZ40w379F9tGUU3sa4h/9DDS3uiM=; 7:/fgctcYhmgm3s2/rsz8g40R1JyqRUOGdsh17M47BcuTtttDUtsG7dAaEdPDoZKQtsOmIFCSOrq8h372by0X57pxJJE3pG7qm7FIiUhPA2FE8klQFCtw2HXHQvTnpsHj5mDFV7FJhUGMr6nJ1lD1Tfjrqx681PD4qVgPfsNnarQPddvpJHuGMYxVDcQ8ANpl9Vl07CpRqyobrAgtXHsMsBw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1233; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; x-forefront-prvs: 0938781D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(53754006)(377454003)(122556002)(10090500001)(10290500002)(5005710100001)(10400500002)(77096005)(15975445007)(2950100001)(5001770100001)(5008740100001)(3280700002)(3660700001)(81166005)(2501003)(33656002)(16236675004)(19625215002)(92566002)(19617315012)(8936002)(86362001)(99286002)(66066001)(106116001)(5003600100002)(76576001)(74316001)(19580405001)(19580395003)(2906002)(107886002)(19300405004)(19609705001)(189998001)(102836003)(87936001)(6116002)(790700001)(1220700001)(76176999)(50986999)(54356999)(586003)(5002640100001)(9686002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234025C97EE6EE4832FC839A6710BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2016 07:31:36.6413 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1233 Archived-At: Subject: Re: [OAUTH-WG] Multi-AS State Re-Use X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 07:31:56 -0000 --_000_BN3PR0301MB1234025C97EE6EE4832FC839A6710BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U1RBVEUgY2FuIGJlIGFueXRoaW5nLCBpdCBkb2VzIG5vdCBoYXZlIHRvIGJlIGEgTk9OQ0Ugc28g Y2hhbmdpbmcgdGhpcyB3b3VsZCBjYXVzZSBpc3N1ZXMgYXQgdGhpcyB0aW1lIGZvciBleGlzdGlu ZyBkZXBsb3ltZW50cw0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBOYXQgU2FraW11cmENClNlbnQ6IE1vbmRheSwgTWF5IDksIDIwMTYg NzozNCBQTQ0KVG86IEd1aWRvIFNjaG1pdHogPGcuc2NobWl0ekBndHJzLmRlPjsgb2F1dGhAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE11bHRpLUFTIFN0YXRlIFJlLVVzZQ0KDQpB cyBmYXIgYXMgSSBhbSBhd2FyZSBvZiwgc3RhdGUgd2FzIG1lYW50IHRvIGJlIG5vbmNlLiBSZXBs YXkgcG9zc2liaWxpdHkgZXRjLiB3ZXJlIGtub3duLiBJdCBpcyBwcm9iYWJseSBhIGJhZCBkb2N1 bWVudGF0aW9uIHRoYXQgZXZlcnkgcmV2aWV3ZXJzIG1pc3NlZCBiZWNhdXNlIHRoZXkgd2VyZSBh c3N1bWluZyBpdC4NCg0KQmVzdCwNCg0KTmF0DQpPbiBNb24sIE1heSA5LCAyMDE2IGF0IDIwOjE0 IEd1aWRvIFNjaG1pdHogPGcuc2NobWl0ekBndHJzLmRlPG1haWx0bzpnLnNjaG1pdHpAZ3Rycy5k ZT4+IHdyb3RlOg0KSGkgYWxsLA0KDQpjYW4gYW55Ym9keSBjb25maXJtIHRoYXQgdGhpcyBpcyBh IG5ldyAvIHVuZG9jdW1lbnRlZCBhdHRhY2s/DQoNCkNoZWVycywNCg0KR3VpZG8sIERhbmllbCwg YW5kIFJhbGYNCg0KT24gMjIuMDQuMjAxNiAxNjoyMywgRGFuaWVsIEZldHQgd3JvdGU6DQo+IEhp IGFsbCwNCj4NCj4gQmVzaWRlcyB0aGUgc3RhdGUgbGVha2FnZSBhdHRhY2sgd2UgZm91bmQgdGhh dCBhbm90aGVyIGltcG9ydGFudCBmYWN0DQo+IHJlZ2FyZGluZyBzdGF0ZSBpcyB1bmRlcnNwZWNp ZmllZDogRWFjaCBzdGF0ZSB2YWx1ZSBzaG91bGQgb25seSBiZQ0KPiB1c2VkIGZvciBvbmUgcnVu IG9mIHRoZSBwcm90b2NvbCwgaW4gcGFydGljdWxhciwgZWFjaCBBUyBzaG91bGQgc2VlIGENCj4g ZGlmZmVyZW50IHN0YXRlIGluIG11bHRpLUFTIHNldHRpbmdzLiBDbGllbnRzIG1pZ2h0IGJlIHRl bXB0ZWQgdG8NCj4gZ2VuZXJhdGUgc3RhdGUgb25jZSBhbmQgdGhlbiByZS11c2UgZWFjaCB0aW1l IGEgdXNlciB3YW50cyB0bw0KPiBhdXRob3JpemUuDQo+DQo+IElmIHN0YXRlIGlzIHJlLXVzZWQs IGdpdmVuIGEgc2V0dXAgd2hlcmUgb25lIENsaWVudCBhbGxvd3MgdXNlcnMgdG8NCj4gYXV0aG9y aXplIHVzaW5nIHR3byBBUywgYSBwb3RlbnRpYWxseSBtYWxpY2lvdXMgQVMgbGVhcm5zIHRoZSBz dGF0ZQ0KPiB2YWx1ZSB0aGF0IGlzIHZhbGlkIGZvciBhdXRob3JpemF0aW9uIGF0IGFuIGhvbmVz dCBBUy4gSS5lLiwgZWFjaCBBUw0KPiBjYW4gbW91bnQgYSBDU1JGIGF0dGFjayBvbiB0aGUgdXNl ciB1c2luZyB0aGUgb3RoZXIgQVMuDQo+DQo+IEp1c3QgYXMgdGhlIGF0dGFjayBpbiB0aGUgb3Ro ZXIgbWFpbCwgdGhpcyBpcyBub3QgYSBiaWcgZGVhbCBpbg0KPiBwcmFjdGljZSwgYnV0IHNob3Vs ZCBiZSBkaXNjdXNzZWQgc29tZXdoZXJlLg0KPg0KPiBDaGVlcnMsDQo+IERhbmllbCwgR3VpZG8s IGFuZCBSYWxmDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2El MmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdj MDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzJlZTAyMTIwOWYyZTRmNzc0MTE5MDhkMzc4 N2I4NDZmJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPXdMWE0w Z0JCQnVmdHhUc2dXMG5LT2RZUGNlN1dxYk94SktXZjc3RmFKWXclM2Q+DQotLQ0KTmF0IFNha2lt dXJhDQpDaGFpcm1hbiBvZiB0aGUgQm9hcmQsIE9wZW5JRCBGb3VuZGF0aW9uDQpUcnVzdGVlLCBL YW50YXJhIEluaXRpYXRpdmUNCg== --_000_BN3PR0301MB1234025C97EE6EE4832FC839A6710BN3PR0301MB1234_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNUQVRFIGNhbiBiZSBhbnl0aGluZywgaXQgZG9lcyBub3Qg aGF2ZSB0byBiZSBhIE5PTkNFIHNvIGNoYW5naW5nIHRoaXMgd291bGQgY2F1c2UgaXNzdWVzIGF0 IHRoaXMgdGltZSBmb3IgZXhpc3RpbmcgZGVwbG95bWVudHMNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+TmF0IFNha2ltdXJhPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDksIDIwMTYgNzoz NCBQTTxicj4NCjxiPlRvOjwvYj4gR3VpZG8gU2NobWl0eiAmbHQ7Zy5zY2htaXR6QGd0cnMuZGUm Z3Q7OyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBN dWx0aS1BUyBTdGF0ZSBSZS1Vc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGZh ciBhcyBJIGFtIGF3YXJlIG9mLCBzdGF0ZSB3YXMgbWVhbnQgdG8gYmUgbm9uY2UuIFJlcGxheSBw b3NzaWJpbGl0eSBldGMuIHdlcmUga25vd24uIEl0IGlzIHByb2JhYmx5IGEgYmFkIGRvY3VtZW50 YXRpb24gdGhhdCBldmVyeSByZXZpZXdlcnMgbWlzc2VkIGJlY2F1c2UgdGhleSB3ZXJlIGFzc3Vt aW5nIGl0Lg0KPGJyPg0KPGJyPg0KQmVzdCwgPGJyPg0KPGJyPg0KTmF0PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTWF5IDksIDIwMTYg YXQgMjA6MTQgR3VpZG8gU2NobWl0eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmcuc2NobWl0ekBndHJz LmRlIj5nLnNjaG1pdHpAZ3Rycy5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgYWxsLDxicj4NCjxicj4N CmNhbiBhbnlib2R5IGNvbmZpcm0gdGhhdCB0aGlzIGlzIGEgbmV3IC8gdW5kb2N1bWVudGVkIGF0 dGFjaz88YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KPGJyPg0KR3VpZG8sIERhbmllbCwgYW5kIFJh bGY8YnI+DQo8YnI+DQpPbiAyMi4wNC4yMDE2IDE2OjIzLCBEYW5pZWwgRmV0dCB3cm90ZTo8YnI+ DQomZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBCZXNpZGVzIHRoZSBzdGF0ZSBsZWFr YWdlIGF0dGFjayB3ZSBmb3VuZCB0aGF0IGFub3RoZXIgaW1wb3J0YW50IGZhY3Q8YnI+DQomZ3Q7 IHJlZ2FyZGluZyBzdGF0ZSBpcyB1bmRlcnNwZWNpZmllZDogRWFjaCBzdGF0ZSB2YWx1ZSBzaG91 bGQgb25seSBiZTxicj4NCiZndDsgdXNlZCBmb3Igb25lIHJ1biBvZiB0aGUgcHJvdG9jb2wsIGlu IHBhcnRpY3VsYXIsIGVhY2ggQVMgc2hvdWxkIHNlZSBhPGJyPg0KJmd0OyBkaWZmZXJlbnQgc3Rh dGUgaW4gbXVsdGktQVMgc2V0dGluZ3MuIENsaWVudHMgbWlnaHQgYmUgdGVtcHRlZCB0bzxicj4N CiZndDsgZ2VuZXJhdGUgc3RhdGUgb25jZSBhbmQgdGhlbiByZS11c2UgZWFjaCB0aW1lIGEgdXNl ciB3YW50cyB0bzxicj4NCiZndDsgYXV0aG9yaXplLjxicj4NCiZndDs8YnI+DQomZ3Q7IElmIHN0 YXRlIGlzIHJlLXVzZWQsIGdpdmVuIGEgc2V0dXAgd2hlcmUgb25lIENsaWVudCBhbGxvd3MgdXNl cnMgdG88YnI+DQomZ3Q7IGF1dGhvcml6ZSB1c2luZyB0d28gQVMsIGEgcG90ZW50aWFsbHkgbWFs aWNpb3VzIEFTIGxlYXJucyB0aGUgc3RhdGU8YnI+DQomZ3Q7IHZhbHVlIHRoYXQgaXMgdmFsaWQg Zm9yIGF1dGhvcml6YXRpb24gYXQgYW4gaG9uZXN0IEFTLiBJLmUuLCBlYWNoIEFTPGJyPg0KJmd0 OyBjYW4gbW91bnQgYSBDU1JGIGF0dGFjayBvbiB0aGUgdXNlciB1c2luZyB0aGUgb3RoZXIgQVMu PGJyPg0KJmd0Ozxicj4NCiZndDsgSnVzdCBhcyB0aGUgYXR0YWNrIGluIHRoZSBvdGhlciBtYWls LCB0aGlzIGlzIG5vdCBhIGJpZyBkZWFsIGluPGJyPg0KJmd0OyBwcmFjdGljZSwgYnV0IHNob3Vs ZCBiZSBkaXNjdXNzZWQgc29tZXdoZXJlLjxicj4NCiZndDs8YnI+DQomZ3Q7IENoZWVycyw8YnI+ DQomZ3Q7IERhbmllbCwgR3VpZG8sIGFuZCBSYWxmPGJyPg0KJmd0Ozxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5v cmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5h ZCU0MG1pY3Jvc29mdC5jb20lN2MyZWUwMjEyMDlmMmU0Zjc3NDExOTA4ZDM3ODdiODQ2ZiU3Yzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9d0xYTTBnQkJCdWZ0 eFRzZ1cwbktPZFlQY2U3V3FiT3hKS1dmNzdGYUpZdyUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNjVwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5O YXQgU2FraW11cmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTQuNjVwdCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5DaGFpcm1hbiBvZiB0aGUgQm9hcmQsIE9wZW5JRCBGb3VuZGF0aW9uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjE0LjY1cHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VHJ1c3Rl ZSwgS2FudGFyYSBJbml0aWF0aXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR0301MB1234025C97EE6EE4832FC839A6710BN3PR0301MB1234_-- From nobody Tue May 10 01:23:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4506F12D1D4 for ; Tue, 10 May 2016 01:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 AKBynWi36bLn for ; Tue, 10 May 2016 01:23:42 -0700 (PDT) Received: from mx1.uni-trier.de (mx1.uni-trier.de [136.199.224.17]) (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 70CE712B074 for ; Tue, 10 May 2016 01:23:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,604,1454972400"; d="scan'208";a="20212894" Received: from rzmail.uni-trier.de ([136.199.8.220]) by mx1i.uni-trier.de with ESMTP; 10 May 2016 10:23:40 +0200 Received: from [136.199.52.39] (infsec39.uni-trier.de [136.199.52.39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by rzmail.uni-trier.de (Postfix) with ESMTPSA id 96AF7409C4; Tue, 10 May 2016 10:23:40 +0200 (CEST) To: oauth@ietf.org References: <571B60BA.8090301@lodderstedt.net> <572B56BB.9080903@uni-trier.de> From: Daniel Fett Message-ID: <57319A8C.3070408@uni-trier.de> Date: Tue, 10 May 2016 10:23:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 08:23:45 -0000 It does not work if the AS does not check the redirect URI completely. Facebook being the main example here, and I guess they won't change this soon (for backwards compatibility). Adding the iss parameter won't break things. -Daniel Am 09.05.2016 um 05:45 schrieb Nat Sakimura: > Hi Daniel, > > May I ask again why separate redirect uri would not work for mix-up? > (I know, it does not work for cut-n-paste.) > > Thanks, > > Nat > > 2016年5月5日(木) 23:28 Daniel Fett >: > > Am 23.04.2016 um 13:47 schrieb Torsten Lodderstedt: > > I'm very much interested to find a solution within the OAuth realm as > > I'm not interested to either implement two solutions (for OpenId > Connect > > and OAuth) or adopt a OpenId-specific solution to OAuth (use id! > tokens > > in the front channel). I therefore would like to see progress and > > propose to continue the discussion regarding mitigations for both > threats. > > > > https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00 > > proposes reasonable mitigations for both attacks. There are > alternatives > > as well: > > - mix up: > > -- AS specific redirect uris > > -- Meta data/turi > > (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5) > > - CnP: > > -- use of the nonce parameter (as a distinct mitigation beside > state for > > counter XSRF) > > >From our formal analysis of OAuth we are pretty confident that the > mitigation proposed in draft-ietf-oauth-mix-up-mitigation-00 should be > sufficient against the Mix-Up attack. > > Cheers, > Daniel > > > -- > Informationssicherheit und Kryptografie > Universität Trier - Tel. 0651 201 2847 - H436 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > Nat Sakimura > Chairman of the Board, OpenID Foundation > Trustee, Kantara Initiative -- Informationssicherheit und Kryptografie Universität Trier - Tel. 0651 201 2847 - H436 From nobody Tue May 10 01:44:03 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189E812D56E for ; Tue, 10 May 2016 01:43:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wahlstromstekniska-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i2FoU9khbta for ; Tue, 10 May 2016 01:43:56 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CA712D18E for ; Tue, 10 May 2016 01:43:52 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id m64so6766088lfd.1 for ; Tue, 10 May 2016 01:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wahlstromstekniska-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tSby/1R0Lu9eXQstX/YJ8XL0DFyOGbnRpVwShspzJqQ=; b=bPn/lEO5kS4Z++5m6QFNKEByjjHK3+PrBS3KwJF4F9RCPcxHGXrC7qiP4WyqvWN+xf Azla7jnU189E87xVsV8HZLfktl+MgPT7OlFha5k3HVGmlYbJpM3m08zgJqWtXxIfTDgj UZJxCGyCOstbRyQUM64xvs9o873H3c9e1vjacV185/20phKH8Psy7xljbdxGx0YBnO8X ePh/uSubc0Yxqmy75jQZY1XSEZMpElGQIRQovERTXvDWrrKU4SmK/LSx4JXabbjudqho 6BdE4vK2SCyQZKMcIRnL75XUXlvoF5R/EmeGbd1Wf0Y8LXqolvt5cCVUuTN1wh8W1HGL qmVw== 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:date :message-id:subject:from:to:cc; bh=tSby/1R0Lu9eXQstX/YJ8XL0DFyOGbnRpVwShspzJqQ=; b=fveQt3Ae/aagsXDa3QX4nP4+VG4MNQacDAu9xJi3KEC6gv9atf5wCXA4HaQ98FHF0q h75LWiR8C85ZUIf6empjEklzzxvXReeIAP0+y8DTLcas7UOXuDcEMGFez3fBNIpFu8JO P9dtTYv4PCDoQSyu6UMoYq9kPw7VmL6M1GSjSaRXZQpwOP38VC1i5k7id6YUuXvufD4t +MEHQF2649mL1NTWD9FeJzPCxuVksj2OPCEZM5k9mGBCGXuC9bFcGn2N9wj/LqAkpI0A 7OOfsTgjvQUFPwvfadn3eH7n4ax4FiHGFG4xHlULP1VeIt9P9UILNCVUV18r40UOlK3Z wKwg== X-Gm-Message-State: AOPr4FWpD8XiQWq23R0/oWn0byE/ODGwgxcPvnImWth/Spm7O22BtLiivsVGBlFJe4SnUYGV2MQIVVPHDurnqg== MIME-Version: 1.0 X-Received: by 10.25.22.19 with SMTP id m19mr17054764lfi.118.1462869830177; Tue, 10 May 2016 01:43:50 -0700 (PDT) Received: by 10.25.136.5 with HTTP; Tue, 10 May 2016 01:43:50 -0700 (PDT) X-Originating-IP: [37.247.26.197] In-Reply-To: <89B6F196-D08F-4FBD-9F0D-5B250284048F@mit.edu> References: <57309F46.9040705@tzi.org> <89B6F196-D08F-4FBD-9F0D-5B250284048F@mit.edu> Date: Tue, 10 May 2016 10:43:50 +0200 Message-ID: From: =?UTF-8?Q?Erik_Wahlstr=C3=B6m?= To: Justin Richer Content-Type: multipart/alternative; boundary=001a11406a9c94ae0a053278ec62 Archived-At: Cc: "ace@ietf.org" , "" , cose Subject: Re: [OAUTH-WG] [Ace] [COSE] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 08:43:58 -0000 --001a11406a9c94ae0a053278ec62 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Or keep the CBOR Web Token (CWT) for two major reasons: - To show the very close relationship to JWT. It relies heavily on JWT and it's iana registry. It is essentially a JWT but in CBOR/COSE instead of JSON/JOSE. - I would not say that JWT is the only format that works for the web, and it's even used in other, non-traditional, web protocols. That means I don't have a problem with the W in CWT at all. Why would JSON be the only web protocol? Then we also have one smaller (a lot smaller) reason, it's the fact that it can be called "cot" just like JWT is called a "jot" and I figured that our "cozy chairs" would very much like that fact because then it's essentially a "cozy cot" :) / Erik On Tue, May 10, 2016 at 2:49 AM, Justin Richer wrote: > We can also call it the =E2=80=9CCOSE Token=E2=80=9D. As a chair of the C= OSE working > group, I=E2=80=99m fine with that amount of co-branding. > > =E2=80=94 Justin > > > On May 9, 2016, at 9:31 AM, Carsten Bormann wrote: > > > >> draft-ietf-ace-cbor-token-00.txt; > > > > For the record, I do not think that ACE has a claim on the term "CBOR > > Token". While the term token is not used in RFC 7049, there are many > > tokens that could be expressed in CBOR or be used in applying CBOR to a > > problem. > > > > ACE CBOR Token is fine, though. > > (Or, better, CBOR ACE Token, CAT.) > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --001a11406a9c94ae0a053278ec62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Or keep the CBOR Web Token (CWT) for two major reasons:- To show the very close relationship to JWT. It relies heavily on JWT an= d it's iana registry. It is essentially a JWT but in CBOR/COSE instead = of JSON/JOSE.
- I would not say that JWT is the only format that = works for the web, and it's even used in other, non-traditional, web pr= otocols. That means I don't have a problem with the W in CWT at all. Wh= y would JSON be the only web protocol?

Then we als= o have one smaller (a lot smaller) reason, it's the fact that it can be= called "cot" just like JWT is called a "jot" and I fig= ured that our "cozy chairs" would very much like that fact becaus= e then it's essentially a "cozy cot" :)

<= div>/ Erik


On Tue, May 10, 2016 at 2:49 AM, Justin Richer <jricher@= mit.edu> wrote:
We can also= call it the =E2=80=9CCOSE Token=E2=80=9D. As a chair of the COSE working g= roup, I=E2=80=99m fine with that amount of co-branding.

=C2=A0=E2=80=94 Justin

> On May 9, 2016, at 9:31 AM, Carsten Bormann <cabo@tzi.org> wrote:
>
>> draft-ietf-ace-cbor-token-00.txt;
>
> For the record, I do not think that ACE has a claim on the term "= CBOR
> Token".=C2=A0 While the term token is not used in RFC 7049, there= are many
> tokens that could be expressed in CBOR or be used in applying CBOR to = a
> problem.
>
> ACE CBOR Token is fine, though.
> (Or, better, CBOR ACE Token, CAT.)
>
> Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

--001a11406a9c94ae0a053278ec62-- From nobody Tue May 10 01:50:45 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546B412D56E; Tue, 10 May 2016 01:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWD2aS42PBcY; Tue, 10 May 2016 01:50:40 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160EB12D0EC; Tue, 10 May 2016 01:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2Pb2uuHwa6Jnqn40nZjHM/K60YjU2Fe2jk5X6obVYwc=; b=ZIXCgRcSRcQcIyBxcqyCc8nvXjHA/ZnWQvQFA1W1EHWnRPyN4YInFOi1R8GMKyhY+SpGQqpJx1p8vcntvjOJ6ImCQ7YO0z5oR97LUeythsu7gplRJaWMySvd+eUUrA/sf4nXmMo4TXu2MXm7e7fzKTHkfEy/N3AZmOS5CaXvgNM= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1648.namprd03.prod.outlook.com (10.162.130.142) with Microsoft SMTP Server (TLS) id 15.1.485.9; Tue, 10 May 2016 08:50:38 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0492.016; Tue, 10 May 2016 08:50:38 +0000 From: Mike Jones To: =?utf-8?B?RXJpayBXYWhsc3Ryw7Zt?= , "Justin Richer" Thread-Topic: [Ace] [COSE] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 Thread-Index: AQHRqpgaOC6RkJUk/U2IOlAZ6LFfqJ+x20iA Date: Tue, 10 May 2016 08:50:38 +0000 Message-ID: References: <57309F46.9040705@tzi.org> <89B6F196-D08F-4FBD-9F0D-5B250284048F@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: wahlstromstekniska.se; dkim=none (message not signed) header.d=none; wahlstromstekniska.se; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [86.110.65.6] x-ms-office365-filtering-correlation-id: 739799e7-b7da-4bfd-ed62-08d378b028c5 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1648; 5:K7Id0ATTLRgZvJbTnnlc06Wik3fklcDLwhFjrTXVUhOs7ZLB9rZ9vKoF32KEKZ3GmyTNyWBT2j/Qq0UqMyAidTJkY8BBX9sex2PfjxUfPh/FchNhiqIQz0/IoKdB6zwjr0kv47w0r3JLWO+p59/Www==; 24:GkraLZES7gpCh9GvOcxpnAtodVePBbUYq4KQqVONY5cwnIP/opCoMnaTqZ47uH1VH+1gGCZPn8ao2XOr/WnyiZsS7rB54UxFip5kbMzjqo0=; 7:I7HvaxNOca1PiuxDXJTZrycBzcztCmtk7kwVbcEox6ebrphSf+KJJLW0ebLIuJlABwAq6hPGM0io1oHQaiBzxCLBUN3k1v+sRlkxarMkL0Awrz05v3p+QO1emjbCz+Jz5gVBJQNj1GcrZhrbZqMvj7wi7mW6d66S1WwswgNjyqbA7S5fT0L6QmlH9FWpXpO6YDeZdOM0Z+3j+686i35n7Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1648; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1648; x-forefront-prvs: 0938781D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(74316001)(76576001)(92566002)(11100500001)(5003600100002)(8936002)(3280700002)(19609705001)(81166005)(19580395003)(3660700001)(9686002)(19580405001)(19617315012)(10090500001)(5002640100001)(10290500002)(10400500002)(5005710100001)(2950100001)(50986999)(87936001)(2171001)(2906002)(5008740100001)(66066001)(1220700001)(33656002)(230783001)(5001770100001)(54356999)(76176999)(16236675004)(99286002)(86362001)(122556002)(4326007)(77096005)(106116001)(19300405004)(790700001)(586003)(102836003)(6116002)(15975445007)(189998001)(19625215002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1648; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1645A1F955468253B8EF4782F5710SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2016 08:50:38.1134 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1648 Archived-At: Cc: "ace@ietf.org" , "" , cose Subject: Re: [OAUTH-WG] [Ace] [COSE] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 08:50:43 -0000 --_000_SN1PR0301MB1645A1F955468253B8EF4782F5710SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIGZlZWwgc3Ryb25nbHkgdGhhdCB0aGUgbmFtZSBzaG91bGQgcmVtYWluIENCT1IgV2Vi IFRva2VuLiAgQ1dUIGlzIGEgYmVuZWZpY2lhcnkgb2YgdGhlIGludGVsbGVjdHVhbCBhbmQgZGVw bG95bWVudCBoZXJpdGFnZSBmcm9tIHRoZSBTaW1wbGUgV2ViIFRva2VuIChTV1QpIGFuZCBKU09O IFdlYiBUb2tlbiAoSldUKS4gIENXVCBpcyBpbnRlbnRpb25hbGx5IHBhcmFsbGVsIHRvIEpXVC4g IFRoZSBuYW1lIHNob3VsZCBzdGF5IHBhcmFsbGVsIGFzIHdlbGwuDQoNClRoZSDigJxXZWLigJ0g cGFydCBvZiB0aGUg4oCcQ0JPUiBXZWIgVG9rZW7igJ0gbmFtZSBjYW4gYmUgdGFrZW4gYXMgYSBy ZWZlcmVuY2UgdG8gdGhlIFdlYiBvZiBUaGluZ3MgKHNlZSBodHRwczovL2VuLndpa2lwZWRpYS5v cmcvd2lraS9XZWJfb2ZfVGhpbmdzKS4gIEFzIEVyaWsgY29ycmVjdGx5IHBvaW50cyBvdXQgSlNP TiBpcyBub3QgdGhlIG9ubHkgZGF0YSByZXByZXNlbnRhdGlvbiB0aGF0IG1ha2VzIHRoaW5ncyBp biB0aGUgV2ViIGFuZCB0aGUgV2ViIG9mIFRoaW5ncy4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogQWNl IFttYWlsdG86YWNlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmlrIFdhaGxzdHLD tm0NClNlbnQ6IFR1ZXNkYXksIE1heSAxMCwgMjAxNiAxOjQ0IEFNDQpUbzogSnVzdGluIFJpY2hl ciA8anJpY2hlckBtaXQuZWR1Pg0KQ2M6IEthdGhsZWVuIE1vcmlhcnR5IDxrYXRobGVlbi5tb3Jp YXJ0eS5pZXRmQGdtYWlsLmNvbT47IEtlcGVuZyBMaSA8a2VwZW5nLmxrcEBhbGliYWJhLWluYy5j b20+OyBhY2VAaWV0Zi5vcmc7IENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPjsgSGFubmVz IFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+OyA8b2F1dGhAaWV0Zi5vcmc+ IDxvYXV0aEBpZXRmLm9yZz47IGNvc2UgPGNvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0Fj ZV0gW0NPU0VdIENhbGwgZm9yIGFkb3B0aW9uIGZvciBkcmFmdC13YWhsc3Ryb2VtLWFjZS1jYm9y LXdlYi10b2tlbi0wMA0KDQpPciBrZWVwIHRoZSBDQk9SIFdlYiBUb2tlbiAoQ1dUKSBmb3IgdHdv IG1ham9yIHJlYXNvbnM6DQotIFRvIHNob3cgdGhlIHZlcnkgY2xvc2UgcmVsYXRpb25zaGlwIHRv IEpXVC4gSXQgcmVsaWVzIGhlYXZpbHkgb24gSldUIGFuZCBpdCdzIGlhbmEgcmVnaXN0cnkuIEl0 IGlzIGVzc2VudGlhbGx5IGEgSldUIGJ1dCBpbiBDQk9SL0NPU0UgaW5zdGVhZCBvZiBKU09OL0pP U0UuDQotIEkgd291bGQgbm90IHNheSB0aGF0IEpXVCBpcyB0aGUgb25seSBmb3JtYXQgdGhhdCB3 b3JrcyBmb3IgdGhlIHdlYiwgYW5kIGl0J3MgZXZlbiB1c2VkIGluIG90aGVyLCBub24tdHJhZGl0 aW9uYWwsIHdlYiBwcm90b2NvbHMuIFRoYXQgbWVhbnMgSSBkb24ndCBoYXZlIGEgcHJvYmxlbSB3 aXRoIHRoZSBXIGluIENXVCBhdCBhbGwuIFdoeSB3b3VsZCBKU09OIGJlIHRoZSBvbmx5IHdlYiBw cm90b2NvbD8NCg0KVGhlbiB3ZSBhbHNvIGhhdmUgb25lIHNtYWxsZXIgKGEgbG90IHNtYWxsZXIp IHJlYXNvbiwgaXQncyB0aGUgZmFjdCB0aGF0IGl0IGNhbiBiZSBjYWxsZWQgImNvdCIganVzdCBs aWtlIEpXVCBpcyBjYWxsZWQgYSAiam90IiBhbmQgSSBmaWd1cmVkIHRoYXQgb3VyICJjb3p5IGNo YWlycyIgd291bGQgdmVyeSBtdWNoIGxpa2UgdGhhdCBmYWN0IGJlY2F1c2UgdGhlbiBpdCdzIGVz c2VudGlhbGx5IGEgImNvenkgY290IiA6KQ0KDQovIEVyaWsNCg0KDQpPbiBUdWUsIE1heSAxMCwg MjAxNiBhdCAyOjQ5IEFNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpy aWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KV2UgY2FuIGFsc28gY2FsbCBpdCB0aGUg4oCcQ09TRSBU b2tlbuKAnS4gQXMgYSBjaGFpciBvZiB0aGUgQ09TRSB3b3JraW5nIGdyb3VwLCBJ4oCZbSBmaW5l IHdpdGggdGhhdCBhbW91bnQgb2YgY28tYnJhbmRpbmcuDQoNCiDigJQgSnVzdGluDQoNCj4gT24g TWF5IDksIDIwMTYsIGF0IDk6MzEgQU0sIENhcnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPG1h aWx0bzpjYWJvQHR6aS5vcmc+PiB3cm90ZToNCj4NCj4+IGRyYWZ0LWlldGYtYWNlLWNib3ItdG9r ZW4tMDAudHh0Ow0KPg0KPiBGb3IgdGhlIHJlY29yZCwgSSBkbyBub3QgdGhpbmsgdGhhdCBBQ0Ug aGFzIGEgY2xhaW0gb24gdGhlIHRlcm0gIkNCT1INCj4gVG9rZW4iLiAgV2hpbGUgdGhlIHRlcm0g dG9rZW4gaXMgbm90IHVzZWQgaW4gUkZDIDcwNDksIHRoZXJlIGFyZSBtYW55DQo+IHRva2VucyB0 aGF0IGNvdWxkIGJlIGV4cHJlc3NlZCBpbiBDQk9SIG9yIGJlIHVzZWQgaW4gYXBwbHlpbmcgQ0JP UiB0byBhDQo+IHByb2JsZW0uDQo+DQo+IEFDRSBDQk9SIFRva2VuIGlzIGZpbmUsIHRob3VnaC4N Cj4gKE9yLCBiZXR0ZXIsIENCT1IgQUNFIFRva2VuLCBDQVQuKQ0KPg0KPiBHcsO8w59lLCBDYXJz dGVuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IENPU0UgbWFpbGluZyBsaXN0DQo+IENPU0VAaWV0Zi5vcmc8bWFpbHRvOkNPU0VAaWV0Zi5v cmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY29zZQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQWNlIG1haWxpbmcg bGlzdA0KQWNlQGlldGYub3JnPG1haWx0bzpBY2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KDQo= --_000_SN1PR0301MB1645A1F955468253B8EF4782F5710SN1PR0301MB1645_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSBhbHNvIGZlZWwgc3Ryb25nbHkgdGhh dCB0aGUgbmFtZSBzaG91bGQgcmVtYWluIENCT1IgV2ViIFRva2VuLiZuYnNwOyBDV1QgaXMgYSBi ZW5lZmljaWFyeSBvZiB0aGUgaW50ZWxsZWN0dWFsIGFuZCBkZXBsb3ltZW50IGhlcml0YWdlIGZy b20gdGhlIFNpbXBsZSBXZWIgVG9rZW4gKFNXVCkNCiBhbmQgSlNPTiBXZWIgVG9rZW4gKEpXVCku Jm5ic3A7IENXVCBpcyBpbnRlbnRpb25hbGx5IHBhcmFsbGVsIHRvIEpXVC4mbmJzcDsgVGhlIG5h bWUgc2hvdWxkIHN0YXkgcGFyYWxsZWwgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPlRoZSDigJxXZWLigJ0gcGFydCBvZiB0aGUg4oCcQ0JPUiBXZWIg VG9rZW7igJ0gbmFtZSBjYW4gYmUgdGFrZW4gYXMgYSByZWZlcmVuY2UgdG8gdGhlIFdlYiBvZiBU aGluZ3MgKHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvV2ViX29m X1RoaW5ncyI+aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvV2ViX29mX1RoaW5nczwvYT4p LiZuYnNwOyBBcyBFcmlrIGNvcnJlY3RseSBwb2ludHMgb3V0IEpTT04gaXMgbm90IHRoZSBvbmx5 IGRhdGEgcmVwcmVzZW50YXRpb24gdGhhdCBtYWtlcyB0aGluZ3MgaW4gdGhlIFdlYiBhbmQgdGhl IFdlYiBvZiBUaGluZ3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQWNlIFttYWlsdG86 YWNlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWsgV2FobHN0csO2 bTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXkgMTAsIDIwMTYgMTo0NCBBTTxicj4NCjxi PlRvOjwvYj4gSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0Ozxicj4NCjxiPkNj OjwvYj4gS2F0aGxlZW4gTW9yaWFydHkgJmx0O2thdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwu Y29tJmd0OzsgS2VwZW5nIExpICZsdDtrZXBlbmcubGtwQGFsaWJhYmEtaW5jLmNvbSZndDs7IGFj ZUBpZXRmLm9yZzsgQ2Fyc3RlbiBCb3JtYW5uICZsdDtjYWJvQHR6aS5vcmcmZ3Q7OyBIYW5uZXMg VHNjaG9mZW5pZyAmbHQ7aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCZndDs7ICZsdDtvYXV0aEBp ZXRmLm9yZyZndDsgJmx0O29hdXRoQGlldGYub3JnJmd0OzsgY29zZSAmbHQ7Y29zZUBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtBY2VdIFtDT1NFXSBDYWxsIGZvciBhZG9w dGlvbiBmb3IgZHJhZnQtd2FobHN0cm9lbS1hY2UtY2Jvci13ZWItdG9rZW4tMDA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PciBrZWVwIHRoZSBDQk9SIFdlYiBUb2tlbiAo Q1dUKSBmb3IgdHdvIG1ham9yIHJlYXNvbnM6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LSBUbyBzaG93IHRoZSB2ZXJ5IGNsb3NlIHJlbGF0aW9uc2hpcCB0byBK V1QuIEl0IHJlbGllcyBoZWF2aWx5IG9uIEpXVCBhbmQgaXQncyBpYW5hIHJlZ2lzdHJ5LiBJdCBp cyBlc3NlbnRpYWxseSBhIEpXVCBidXQgaW4gQ0JPUi9DT1NFIGluc3RlYWQgb2YgSlNPTi9KT1NF LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBJ IHdvdWxkIG5vdCBzYXkgdGhhdCBKV1QgaXMgdGhlIG9ubHkgZm9ybWF0IHRoYXQgd29ya3MgZm9y IHRoZSB3ZWIsIGFuZCBpdCdzIGV2ZW4gdXNlZCBpbiBvdGhlciwgbm9uLXRyYWRpdGlvbmFsLCB3 ZWIgcHJvdG9jb2xzLiBUaGF0IG1lYW5zIEkgZG9uJ3QgaGF2ZSBhIHByb2JsZW0gd2l0aCB0aGUg VyBpbiBDV1QgYXQgYWxsLiBXaHkgd291bGQgSlNPTiBiZSB0aGUgb25seSB3ZWIgcHJvdG9jb2w/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZW4gd2UgYWxzbyBoYXZlIG9uZSBzbWFsbGVyIChhIGxvdCBzbWFsbGVyKSByZWFzb24sIGl0J3Mg dGhlIGZhY3QgdGhhdCBpdCBjYW4gYmUgY2FsbGVkICZxdW90O2NvdCZxdW90OyBqdXN0IGxpa2Ug SldUIGlzIGNhbGxlZCBhICZxdW90O2pvdCZxdW90OyBhbmQgSSBmaWd1cmVkIHRoYXQgb3VyICZx dW90O2NvenkgY2hhaXJzJnF1b3Q7IHdvdWxkIHZlcnkgbXVjaCBsaWtlIHRoYXQgZmFjdCBiZWNh dXNlIHRoZW4gaXQncyBlc3NlbnRpYWxseSBhICZxdW90O2NvenkgY290JnF1b3Q7DQogOik8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LyBFcmlr PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVHVlLCBNYXkgMTAsIDIwMTYgYXQgMjo0OSBBTSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVk dTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldlIGNhbiBhbHNvIGNhbGwgaXQgdGhlIOKAnENPU0UgVG9rZW7igJ0uIEFzIGEg Y2hhaXIgb2YgdGhlIENPU0Ugd29ya2luZyBncm91cCwgSeKAmW0gZmluZSB3aXRoIHRoYXQgYW1v dW50IG9mIGNvLWJyYW5kaW5nLjxicj4NCjxicj4NCiZuYnNwO+KAlCBKdXN0aW48YnI+DQo8YnI+ DQomZ3Q7IE9uIE1heSA5LCAyMDE2LCBhdCA5OjMxIEFNLCBDYXJzdGVuIEJvcm1hbm4gJmx0Ozxh IGhyZWY9Im1haWx0bzpjYWJvQHR6aS5vcmciPmNhYm9AdHppLm9yZzwvYT4mZ3Q7IHdyb3RlOjxi cj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBkcmFmdC1pZXRmLWFjZS1jYm9yLXRva2VuLTAwLnR4dDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBGb3IgdGhlIHJlY29yZCwgSSBkbyBub3QgdGhpbmsgdGhhdCBB Q0UgaGFzIGEgY2xhaW0gb24gdGhlIHRlcm0gJnF1b3Q7Q0JPUjxicj4NCiZndDsgVG9rZW4mcXVv dDsuJm5ic3A7IFdoaWxlIHRoZSB0ZXJtIHRva2VuIGlzIG5vdCB1c2VkIGluIFJGQyA3MDQ5LCB0 aGVyZSBhcmUgbWFueTxicj4NCiZndDsgdG9rZW5zIHRoYXQgY291bGQgYmUgZXhwcmVzc2VkIGlu IENCT1Igb3IgYmUgdXNlZCBpbiBhcHBseWluZyBDQk9SIHRvIGE8YnI+DQomZ3Q7IHByb2JsZW0u PGJyPg0KJmd0Ozxicj4NCiZndDsgQUNFIENCT1IgVG9rZW4gaXMgZmluZSwgdGhvdWdoLjxicj4N CiZndDsgKE9yLCBiZXR0ZXIsIENCT1IgQUNFIFRva2VuLCBDQVQuKTxicj4NCiZndDs8YnI+DQom Z3Q7IEdyw7zDn2UsIENhcnN0ZW48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgQ09TRSBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpDT1NFQGlldGYub3JnIj5DT1NFQGlldGYub3Jn PC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jb3NlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCkFjZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QWNlQGll dGYub3JnIj5BY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hY2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FjZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN1PR0301MB1645A1F955468253B8EF4782F5710SN1PR0301MB1645_-- From nobody Tue May 10 02:37:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DE912D656 for ; Tue, 10 May 2016 02:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 wEsLkMNBVFXi for ; Tue, 10 May 2016 02:37:25 -0700 (PDT) Received: from mx1.uni-trier.de (mx1.uni-trier.de [136.199.224.17]) (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 1094912D5BA for ; Tue, 10 May 2016 02:37:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,604,1454972400"; d="scan'208";a="20214309" Received: from rzmail.uni-trier.de ([136.199.8.220]) by mx1i.uni-trier.de with ESMTP; 10 May 2016 11:37:23 +0200 Received: from [136.199.52.39] (infsec39.uni-trier.de [136.199.52.39]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by rzmail.uni-trier.de (Postfix) with ESMTPSA id 84DBF409A0 for ; Tue, 10 May 2016 11:37:23 +0200 (CEST) To: oauth@ietf.org References: <571A33E0.6070401@uni-trier.de> <5730D36A.4050601@gtrs.de> From: Daniel Fett Message-ID: <5731ABD3.2070502@uni-trier.de> Date: Tue, 10 May 2016 11:37:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] Multi-AS State Re-Use X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 09:37:32 -0000 Regardless of what state actually is, the documentation (also the one for OIDC) should make clear that the same state should not be sent to two different AS, and that a state issued for AS #1 should be invalid for AS #2. Am 10.05.2016 um 09:31 schrieb Anthony Nadalin: > STATE can be anything, it does not have to be a NONCE so changing this > would cause issues at this time for existing deployments > > > > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Nat Sakimura > *Sent:* Monday, May 9, 2016 7:34 PM > *To:* Guido Schmitz ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Multi-AS State Re-Use > > > > As far as I am aware of, state was meant to be nonce. Replay possibility > etc. were known. It is probably a bad documentation that every reviewers > missed because they were assuming it. -- Informationssicherheit und Kryptografie Universität Trier - Tel. 0651 201 2847 - H436 From nobody Tue May 10 05:57:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EF012D5B9; Tue, 10 May 2016 05:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Zl7N8RBuMPgl; Tue, 10 May 2016 05:57:37 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 7FF8912B03D; Tue, 10 May 2016 05:57:36 -0700 (PDT) X-AuditID: 12074423-58fff7000000258f-cc-5731dabf32f1 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E5.63.09615.FBAD1375; Tue, 10 May 2016 08:57:35 -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 u4ACvYaS010547; Tue, 10 May 2016 08:57:34 -0400 Received: from [10.20.11.38] ([65.115.200.131]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u4ACvRlP031382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 May 2016 08:57:30 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_EF532274-2CD8-4C78-BC6B-DE6F810A1E2D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: Date: Tue, 10 May 2016 07:57:27 -0500 Message-Id: <5E85AFAC-07D3-4499-A5B2-5FEC69409913@mit.edu> References: <57309F46.9040705@tzi.org> <89B6F196-D08F-4FBD-9F0D-5B250284048F@mit.edu> To: Mike Jones X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAKsWRmVeSWpSXmKPExsUixG6nrrv/lmG4wbN5ahbfv/UwWxyZcpfV YtrWqawWXyc0sVos3XmP1aJhZ77F5flFFnunfWKxOPn2FZsDp8fEtx9ZPHbOusvusXjTfjaP JUt+Mnm07vjL7jFtUabHmmkzWALYo7hsUlJzMstSi/TtErgyuh9dYCo408pYce9+A1sD48Li LkZODgkBE4kDf48xdzFycQgJtDFJvLz5nhHC2cgocW/JZVYIZw2TxJHj51hAWpgFEiRuv1oI ZvMK6ElsWv+WCcQWFgiTaPx9E8xmE1CVmL6mBczmFEiUOHr8OzuIzQIUv/pzL9hQZoEvTBKz p/0EcjiABllJzNwlCLFsNpPEvgWTWUEaRAR0JB5f/MYGcausxJOTi1gmMPLPQnLHLCR3QMS1 JZYtfM0MYWtK7O9ezoIpriHR+W0i6wJGtlWMsim5Vbq5iZk5xanJusXJiXl5qUW6Znq5mSV6 qSmlmxjBEeWivIPxZZ/3IUYBDkYlHt4dXIbhQqyJZcWVuYcYJTmYlER5BacAhfiS8lMqMxKL M+KLSnNSiw8xSnAwK4nwRl4GyvGmJFZWpRblw6SkOViUxHkZGRgYhATSE0tSs1NTC1KLYLIy HBxKEryzbgI1ChalpqdWpGXmlCCkmTg4QYbzAA2fC1LDW1yQmFucmQ6RP8WoKCXOWwWSEABJ ZJTmwfWCEp5j8YnmV4ziQK8I874AqeIBJku47ldAg5mABsux6YMMLklESEk1MHbKrGzb2PNJ U1ksaobdPsN/eyumVbuazbrUrBL/+lRpdVS32ovXc5Jm55idehif/WTithVvopkNPGWOrDLM lGy89ezlhMzrGpXrcj+9bms5FbmgVPfeway3gs9f3dp7ntNYaof+tXBDx8jXdzMvHr8x92b3 73gRcc8s+8QGI72lxyRPWtx7+02JpTgj0VCLuag4EQCP/Uo5UwMAAA== Archived-At: Cc: "ace@ietf.org" , "" , cose Subject: Re: [OAUTH-WG] [Ace] [COSE] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 12:57:41 -0000 --Apple-Mail=_EF532274-2CD8-4C78-BC6B-DE6F810A1E2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You=E2=80=99re missing my original complaint: Until this token can be = directly encoded into web technologies, like HTTP headers and HTML = pages, then it has no business being called a =E2=80=9CWeb=E2=80=9D = anything. As it is, it=E2=80=99s a binary encoding that would need an = additional wrapper, like base64url perhaps, to be placed into web = spaces. It can be used in CoAP and native CBOR structures as-is, which = is what it=E2=80=99s designed to do.=20 The =E2=80=9Cweb=E2=80=9D part of JWT is very important. A JWT can be = used, as-is, in any part of an HTTP message: headers, query, form, etc. = It can also be encoded as a string in other data structures in just = about any language without any additional transformation, including = HTML, XML, and JSON. This makes the JWT very =E2=80=9Cwebby=E2=80=9D, = and this is a feature set that this new token doesn=E2=80=99t share. = Ergo, it has no business being called a =E2=80=9Cweb=E2=80=9D token = regardless of its heritage.=20 Both CBOR Token and COSE Token are fine with me.=20 =E2=80=94 Justin > On May 10, 2016, at 3:50 AM, Mike Jones = wrote: >=20 > I also feel strongly that the name should remain CBOR Web Token. CWT = is a beneficiary of the intellectual and deployment heritage from the = Simple Web Token (SWT) and JSON Web Token (JWT). CWT is intentionally = parallel to JWT. The name should stay parallel as well. > =20 > The =E2=80=9CWeb=E2=80=9D part of the =E2=80=9CCBOR Web Token=E2=80=9D = name can be taken as a reference to the Web of Things (see = https://en.wikipedia.org/wiki/Web_of_Things = ). As Erik correctly = points out JSON is not the only data representation that makes things in = the Web and the Web of Things. > =20 > -- Mike > =C2=A0 <> > From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlstr=C3=B6m= > Sent: Tuesday, May 10, 2016 1:44 AM > To: Justin Richer > Cc: Kathleen Moriarty ; Kepeng Li = ; ace@ietf.org; Carsten Bormann = ; Hannes Tschofenig ; = ; cose > Subject: Re: [Ace] [COSE] Call for adoption for = draft-wahlstroem-ace-cbor-web-token-00 > =20 > Or keep the CBOR Web Token (CWT) for two major reasons: > - To show the very close relationship to JWT. It relies heavily on JWT = and it's iana registry. It is essentially a JWT but in CBOR/COSE instead = of JSON/JOSE. > - I would not say that JWT is the only format that works for the web, = and it's even used in other, non-traditional, web protocols. That means = I don't have a problem with the W in CWT at all. Why would JSON be the = only web protocol? > =20 > Then we also have one smaller (a lot smaller) reason, it's the fact = that it can be called "cot" just like JWT is called a "jot" and I = figured that our "cozy chairs" would very much like that fact because = then it's essentially a "cozy cot" :) > =20 > / Erik > =20 > =20 > On Tue, May 10, 2016 at 2:49 AM, Justin Richer > wrote: > We can also call it the =E2=80=9CCOSE Token=E2=80=9D. As a chair of = the COSE working group, I=E2=80=99m fine with that amount of = co-branding. >=20 > =E2=80=94 Justin >=20 > > On May 9, 2016, at 9:31 AM, Carsten Bormann > wrote: > > > >> draft-ietf-ace-cbor-token-00.txt; > > > > For the record, I do not think that ACE has a claim on the term = "CBOR > > Token". While the term token is not used in RFC 7049, there are = many > > tokens that could be expressed in CBOR or be used in applying CBOR = to a > > problem. > > > > ACE CBOR Token is fine, though. > > (Or, better, CBOR ACE Token, CAT.) > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose = >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace = --Apple-Mail=_EF532274-2CD8-4C78-BC6B-DE6F810A1E2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You=E2=80=99re missing my original complaint: Until this = token can be directly encoded into web technologies, like HTTP headers = and HTML pages, then it has no business being called a =E2=80=9CWeb=E2=80=9D= anything. As it is, it=E2=80=99s a binary encoding that would need an = additional wrapper, like base64url perhaps, to be placed into web = spaces. It can be used in CoAP and native CBOR structures as-is, which = is what it=E2=80=99s designed to do. 

The =E2=80=9Cweb=E2=80=9D part of JWT = is very important. A JWT can be used, as-is, in any part of an HTTP = message: headers, query, form, etc. It can also be encoded as a string = in other data structures in just about any language without any = additional transformation, including HTML, XML, and JSON. This makes the = JWT very =E2=80=9Cwebby=E2=80=9D, and this is a feature set that this = new token doesn=E2=80=99t share. Ergo, it has no business being called a = =E2=80=9Cweb=E2=80=9D token regardless of its heritage. 

Both CBOR Token and COSE = Token are fine with me. 

 =E2=80=94 Justin

On May 10, 2016, at 3:50 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I also feel strongly that the name should = remain CBOR Web Token.  CWT is a beneficiary of the intellectual = and deployment heritage from the Simple Web Token (SWT) and JSON Web = Token (JWT).  CWT is intentionally parallel to JWT.  The name = should stay parallel as well.
 
The =E2=80=9CWeb=E2=80=9D = part of the =E2=80=9CCBOR Web Token=E2=80=9D name can be taken as a = reference to the Web of Things (see https://en.wikipedia.org/wiki/Web_of_Things).  As = Erik correctly points out JSON is not the only data representation that = makes things in the Web and the Web of Things.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
From: Ace [mailto:ace-bounces@ietf.org] On Behalf = Of Erik = Wahlstr=C3=B6m
Sent: Tuesday, May 10, 2016 1:44 = AM
To: Justin Richer <jricher@mit.edu>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; Kepeng Li <kepeng.lkp@alibaba-inc.com>; ace@ietf.org; Carsten = Bormann <cabo@tzi.org>; Hannes Tschofenig <hannes.tschofenig@gmx.net>; <oauth@ietf.org> <oauth@ietf.org>; cose = <cose@ietf.org>
Subject: Re: [Ace] [COSE] Call for = adoption for draft-wahlstroem-ace-cbor-web-token-00
 
Or keep the CBOR Web Token (CWT) for two major reasons:
- To show the very close relationship to JWT. It relies = heavily on JWT and it's iana registry. It is essentially a JWT but in = CBOR/COSE instead of JSON/JOSE.
- I would not say = that JWT is the only format that works for the web, and it's even used = in other, non-traditional, web protocols. That means I don't have a = problem with the W in CWT at all. Why would JSON be the only web = protocol?
 
Then we also have one smaller (a lot smaller) reason, = it's the fact that it can be called "cot" just like JWT is called a = "jot" and I figured that our "cozy chairs" would very much like that = fact because then it's essentially a "cozy cot" :)
 
/ Erik
 
 
On Tue, May 10, 2016 at 2:49 AM, Justin Richer <jricher@mit.edu> = wrote:
We = can also call it the =E2=80=9CCOSE Token=E2=80=9D. As a chair of the = COSE working group, I=E2=80=99m fine with that amount of co-branding.

 =E2=80=94 Justin

> On May 9, 2016, at 9:31 AM, Carsten Bormann <cabo@tzi.org> wrote:
>
>> draft-ietf-ace-cbor-token-00.txt;
>
> For the record, I do not think that = ACE has a claim on the term "CBOR
> Token".  While = the term token is not used in RFC 7049, there are many
> = tokens that could be expressed in CBOR or be used in applying CBOR to = a
> problem.
>
> ACE = CBOR Token is fine, though.
> (Or, better, CBOR ACE = Token, CAT.)
>
> Gr=C3=BC=C3=9Fe, = Carsten
>
> = _______________________________________________
> COSE = mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
=

= --Apple-Mail=_EF532274-2CD8-4C78-BC6B-DE6F810A1E2D-- From nobody Tue May 10 08:14:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEC212D704; Tue, 10 May 2016 08:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.215 X-Spam-Level: X-Spam-Status: No, score=-5.215 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Afx2e5YWakx4; Tue, 10 May 2016 08:14:37 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF31012D6FC; Tue, 10 May 2016 08:14:36 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u4AFES5h017962 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 May 2016 15:14:28 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u4AFER06014933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 May 2016 15:14:28 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u4AFEQIq027188; Tue, 10 May 2016 15:14:26 GMT Received: from [10.0.1.3] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 10 May 2016 08:14:25 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-12FBE324-A738-4D06-97CC-03AF56B063ED Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13E238) In-Reply-To: <5E85AFAC-07D3-4499-A5B2-5FEC69409913@mit.edu> Date: Tue, 10 May 2016 08:14:22 -0700 Content-Transfer-Encoding: 7bit Message-Id: <7C5768D4-8293-49E4-B8A6-49910E9C4372@oracle.com> References: <57309F46.9040705@tzi.org> <89B6F196-D08F-4FBD-9F0D-5B250284048F@mit.edu> <5E85AFAC-07D3-4499-A5B2-5FEC69409913@mit.edu> To: Justin Richer X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "ace@ietf.org" , "" , cose Subject: Re: [OAUTH-WG] [COSE] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 15:14:50 -0000 --Apple-Mail-12FBE324-A738-4D06-97CC-03AF56B063ED Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I don't have this issue. I see your point, but I think the constrained brand= ing makes it clear.=20 IOW. When the specs say "constrained web" the use means to me that the token= s for the constrained set of binary protocols which all tend to be in parall= el architecture with web apis anyway. =20 Phil > On May 10, 2016, at 05:57, Justin Richer wrote: >=20 > You=E2=80=99re missing my original complaint: Until this token can be dire= ctly encoded into web technologies, like HTTP headers and HTML pages, then i= t has no business being called a =E2=80=9CWeb=E2=80=9D anything. As it is, i= t=E2=80=99s a binary encoding that would need an additional wrapper, like ba= se64url perhaps, to be placed into web spaces. It can be used in CoAP and na= tive CBOR structures as-is, which is what it=E2=80=99s designed to do.=20 >=20 > The =E2=80=9Cweb=E2=80=9D part of JWT is very important. A JWT can be used= , as-is, in any part of an HTTP message: headers, query, form, etc. It can a= lso be encoded as a string in other data structures in just about any langua= ge without any additional transformation, including HTML, XML, and JSON. Thi= s makes the JWT very =E2=80=9Cwebby=E2=80=9D, and this is a feature set that= this new token doesn=E2=80=99t share. Ergo, it has no business being called= a =E2=80=9Cweb=E2=80=9D token regardless of its heritage.=20 >=20 > Both CBOR Token and COSE Token are fine with me.=20 >=20 > =E2=80=94 Justin >=20 >> On May 10, 2016, at 3:50 AM, Mike Jones wro= te: >>=20 >> I also feel strongly that the name should remain CBOR Web Token. CWT is a= beneficiary of the intellectual and deployment heritage from the Simple Web= Token (SWT) and JSON Web Token (JWT). CWT is intentionally parallel to JWT= . The name should stay parallel as well. >> =20 >> The =E2=80=9CWeb=E2=80=9D part of the =E2=80=9CCBOR Web Token=E2=80=9D na= me can be taken as a reference to the Web of Things (see https://en.wikipedi= a.org/wiki/Web_of_Things). As Erik correctly points out JSON is not the onl= y data representation that makes things in the Web and the Web of Things. >> =20 >> -- Mike >> =20 >> From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Erik Wahlstr=C3=B6m >> Sent: Tuesday, May 10, 2016 1:44 AM >> To: Justin Richer >> Cc: Kathleen Moriarty ; Kepeng Li ; ace@ietf.org; Carsten Bormann ; Hanne= s Tschofenig ; ;= cose >> Subject: Re: [Ace] [COSE] Call for adoption for draft-wahlstroem-ace-cbor= -web-token-00 >> =20 >> Or keep the CBOR Web Token (CWT) for two major reasons: >> - To show the very close relationship to JWT. It relies heavily on JWT an= d it's iana registry. It is essentially a JWT but in CBOR/COSE instead of JS= ON/JOSE. >> - I would not say that JWT is the only format that works for the web, and= it's even used in other, non-traditional, web protocols. That means I don't= have a problem with the W in CWT at all. Why would JSON be the only web pro= tocol? >> =20 >> Then we also have one smaller (a lot smaller) reason, it's the fact that i= t can be called "cot" just like JWT is called a "jot" and I figured that our= "cozy chairs" would very much like that fact because then it's essentially a= "cozy cot" :) >> =20 >> / Erik >> =20 >> =20 >> On Tue, May 10, 2016 at 2:49 AM, Justin Richer wrote: >> We can also call it the =E2=80=9CCOSE Token=E2=80=9D. As a chair of the C= OSE working group, I=E2=80=99m fine with that amount of co-branding. >>=20 >> =E2=80=94 Justin >>=20 >> > On May 9, 2016, at 9:31 AM, Carsten Bormann wrote: >> > >> >> draft-ietf-ace-cbor-token-00.txt; >> > >> > For the record, I do not think that ACE has a claim on the term "CBOR >> > Token". While the term token is not used in RFC 7049, there are many >> > tokens that could be expressed in CBOR or be used in applying CBOR to a= >> > problem. >> > >> > ACE CBOR Token is fine, though. >> > (Or, better, CBOR ACE Token, CAT.) >> > >> > Gr=C3=BC=C3=9Fe, Carsten >> > >> > _______________________________________________ >> > COSE mailing list >> > COSE@ietf.org >> > https://www.ietf.org/mailman/listinfo/cose >>=20 >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose --Apple-Mail-12FBE324-A738-4D06-97CC-03AF56B063ED Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I don't have this issue. I see your po= int, but I think the constrained branding makes it clear. 

IOW. When t= he specs say "constrained web" the use means to me that the tokens for the c= onstrained set of binary protocols which all tend to be in parallel architec= ture with web apis anyway.  

Phil

On May 10, 2016,= at 05:57, Justin Richer <jricher@mit.= edu> wrote:

You=E2=80=99re mi= ssing my original complaint: Until this token can be directly encoded into w= eb technologies, like HTTP headers and HTML pages, then it has no business b= eing called a =E2=80=9CWeb=E2=80=9D anything. As it is, it=E2=80=99s a binar= y encoding that would need an additional wrapper, like base64url perhaps, to= be placed into web spaces. It can be used in CoAP and native CBOR structure= s as-is, which is what it=E2=80=99s designed to do. 
The =E2=80=9Cweb=E2=80=9D part of JWT is v= ery important. A JWT can be used, as-is, in any part of an HTTP message: hea= ders, query, form, etc. It can also be encoded as a string in other data str= uctures in just about any language without any additional transformation, in= cluding HTML, XML, and JSON. This makes the JWT very =E2=80=9Cwebby=E2=80=9D= , and this is a feature set that this new token doesn=E2=80=99t share. Ergo,= it has no business being called a =E2=80=9Cweb=E2=80=9D token regardless of= its heritage. 

Both CBOR Token and COSE Token are fine with me. 

 =E2=80=94 Justin

On May 10, 2016, at 3:50 AM, Mike Jones <Michael.Jones@microsoft.com> w= rote:

I also feel strongly that the name should remain CBOR Web T= oken.  CWT is a beneficiary of the intellectual and deployment heritage= from the Simple Web Token (SWT) and JSON Web Token (JWT).  CWT is inte= ntionally parallel to JWT.  The name should stay parallel as well.
 
The =E2=80=9CWeb=E2=80=9D part of the =E2=80= =9CCBOR Web Token=E2=80=9D name can be taken as a reference to the Web of Th= ings (see https://en.wikipedia.org/wiki/Web_of_Things)= .  As Erik correctly points out JSON is not the only data representatio= n that makes things in the Web and the Web of Things.<= /span>
 
          &n= bsp;            =             &nbs= p;            &n= bsp;         -- Mike=
 
From: Ace [= mailto:ace-bounces@ietf.o= rg] On B= ehalf Of Erik Wahlstr=C3= =B6m
Sent: Tuesday, May 10, 2016 1:44 AM
T= o: Justin Richer <<= a href=3D"mailto:jricher@mit.edu" class=3D"">jricher@mit.edu>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; Kepeng Li <kepeng.lkp@alibaba-inc.com>; ace@ietf.org; Carsten B= ormann <cabo@tzi.org>; H= annes Tschofenig <hannes.tschofenig@gmx.net>; <oauth@ietf.org> <oauth@ietf.org>; cose <cose@ietf.org>
Subject: Re: [Ace] [COSE] Call for adoption f= or draft-wahlstroem-ace-cbor-web-token-00
=
 
Or keep the CBOR Web Token (CWT) for tw= o major reasons:
- To show the very close relationship to JWT. It relies heav= ily on JWT and it's iana registry. It is essentially a JWT but in CBOR/COSE i= nstead of JSON/JOSE.
- I would not say that JWT is the only format that= works for the web, and it's even used in other, non-traditional, web protoc= ols. That means I don't have a problem with the W in CWT at all. Why would J= SON be the only web protocol?
 
<= div class=3D"">
Then we also have one smaller= (a lot smaller) reason, it's the fact that it can be called "cot" just like= JWT is called a "jot" and I figured that our "cozy chairs" would very much l= ike that fact because then it's essentially a "cozy cot" :)<= /o:p>
 
/= Erik
 
 
On Tue, May 10, 2016 at 2:49 AM, Justin Ri= cher <jricher@mit.edu> wr= ote:
=
We can also call it the =E2=80=9CCOSE Token=E2= =80=9D. As a chair of the COSE working group, I=E2=80=99m fine with that amo= unt of co-branding.

 =E2=80=94 Justin

> On May 9, 2016, at 9:31 AM, Carsten Bormann &l= t;cabo@tzi.org> wrote:
>
>> draft-ietf-ace-cbor-token-00.txt;
>
> For the record, I do not think that ACE has a claim on the term "= CBOR
> Token".  While the term token is not used in RFC= 7049, there are many
> tokens that could be expressed in C= BOR or be used in applying CBOR to a
> problem.
>
> ACE CBOR Token is fine, though.
>= ; (Or, better, CBOR ACE Token, CAT.)
>
> G= r=C3=BC=C3=9Fe, Carsten
>
> ______________= _________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
Ace mailing= list
Ace@ietf.org
https://www.ietf.org/m= ailman/listinfo/ace

_______________________________________________<= /span>
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose
= --Apple-Mail-12FBE324-A738-4D06-97CC-03AF56B063ED-- From nobody Tue May 10 13:37:17 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9581D12D520; Tue, 10 May 2016 13:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 msxFJJ_Vumsj; Tue, 10 May 2016 13:37:13 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 2B62812D5FD; Tue, 10 May 2016 13:37:11 -0700 (PDT) X-AuditID: 1209190f-ca3ff70000004b9e-a5-573246761158 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 86.A7.19358.67642375; Tue, 10 May 2016 16:37:10 -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 u4AKb9XR007849; Tue, 10 May 2016 16:37:09 -0400 Received: from [172.25.194.232] ([199.244.219.64]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u4AKb0ai008166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 May 2016 16:37:02 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_15349204-7853-440C-A5EB-97A087AE6A22" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Justin Richer In-Reply-To: <7C5768D4-8293-49E4-B8A6-49910E9C4372@oracle.com> Date: Tue, 10 May 2016 15:36:57 -0500 Message-Id: <59DC8E68-F1F4-435C-AEF8-07D896B1A49A@mit.edu> References: <57309F46.9040705@tzi.org> <89B6F196-D08F-4FBD-9F0D-5B250284048F@mit.edu> <5E85AFAC-07D3-4499-A5B2-5FEC69409913@mit.edu> <7C5768D4-8293-49E4-B8A6-49910E9C4372@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDKsWRmVeSWpSXmKPExsUixCmqrFvmZhRu8Pm7ocX3bz3MFkem3GW1 mLZ1KqvF1wlNrBZLd95jtWjYmW9xeX6Rxd5pn1gsTr59xWaxYH4juwOXx8S3H1k8ds66y+6x eNN+No8lS34yebTu+Mvu8fHpLRaPaYsyPdZMm8ESwBHFZZOSmpNZllqkb5fAlfHq5HS2gutz GStW/fjL2sB4poOxi5GTQ0LARGL1geMsXYxcHEICbUwSt76cZYdwNjJKrDy5iRHCWc8ksbq1 nw2khVkgQaJt+VZ2EJtXQE9i0/q3TCC2sECYxI99X1lBbDYBVYnpa1rA4pwCdhLXDj9nAbFZ gOKzf71iAxnKLLCcWeLlt69MEIOsJN4tXMYMse0Pk8TeT7+ZQRIiAioS365ehzpWVuLJyUUs Exj5ZyE5ZBaSQyDi2hLLFr5mhrA1JfZ3L2fBFNeQ6Pw2kXUBI9sqRtmU3Crd3MTMnOLUZN3i 5MS8vNQiXRO93MwSvdSU0k2M4EiT5N/BOKfB+xCjAAejEg/vDi7DcCHWxLLiytxDjJIcTEqi vN8MjMKF+JLyUyozEosz4otKc1KLDzFKcDArifD6ugDleFMSK6tSi/JhUtIcLErivIwMDAxC AumJJanZqakFqUUwWRkODiUJXklXoEbBotT01Iq0zJwShDQTByfIcB6g4XUgNbzFBYm5xZnp EPlTjIpS4rytIFsFQBIZpXlwvaBEePzLbYdXjOJArwjzOoG08wCTKFz3K6DBTECD5dj0QQaX JCKkpBoYix/tObLRSmeyQVegi/X3aUdTnnBEc+x6nteUGMvw7HDO0n3LRKQU1fmtDe6vEXas PBYxJyuwJfvi1mU7sjc+fPRir8QPkQ1zBGP/H9kS+Y89ffHqgwt3BrZ9+bHwwkyzjZuDX6x+ wLDo4r+Fpf3X2H//7BWuC0hucFOaF/Ke7wXz6jk2Cg8cvyuxFGckGmoxFxUnAgA9RCtsXwMA AA== Archived-At: Cc: "ace@ietf.org" , "" , cose Subject: Re: [OAUTH-WG] [COSE] [Ace] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 20:37:16 -0000 --Apple-Mail=_15349204-7853-440C-A5EB-97A087AE6A22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Then how about the ACE Constrained Token (ACT)? =E2=80=94 Justin > On May 10, 2016, at 10:14 AM, Phil Hunt (IDM) = wrote: >=20 > I don't have this issue. I see your point, but I think the constrained = branding makes it clear.=20 >=20 > IOW. When the specs say "constrained web" the use means to me that the = tokens for the constrained set of binary protocols which all tend to be = in parallel architecture with web apis anyway. =20 >=20 > Phil >=20 > On May 10, 2016, at 05:57, Justin Richer > wrote: >=20 >> You=E2=80=99re missing my original complaint: Until this token can be = directly encoded into web technologies, like HTTP headers and HTML = pages, then it has no business being called a =E2=80=9CWeb=E2=80=9D = anything. As it is, it=E2=80=99s a binary encoding that would need an = additional wrapper, like base64url perhaps, to be placed into web = spaces. It can be used in CoAP and native CBOR structures as-is, which = is what it=E2=80=99s designed to do.=20 >>=20 >> The =E2=80=9Cweb=E2=80=9D part of JWT is very important. A JWT can be = used, as-is, in any part of an HTTP message: headers, query, form, etc. = It can also be encoded as a string in other data structures in just = about any language without any additional transformation, including = HTML, XML, and JSON. This makes the JWT very =E2=80=9Cwebby=E2=80=9D, = and this is a feature set that this new token doesn=E2=80=99t share. = Ergo, it has no business being called a =E2=80=9Cweb=E2=80=9D token = regardless of its heritage.=20 >>=20 >> Both CBOR Token and COSE Token are fine with me.=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On May 10, 2016, at 3:50 AM, Mike Jones > wrote: >>>=20 >>> I also feel strongly that the name should remain CBOR Web Token. = CWT is a beneficiary of the intellectual and deployment heritage from = the Simple Web Token (SWT) and JSON Web Token (JWT). CWT is = intentionally parallel to JWT. The name should stay parallel as well. >>> =20 >>> The =E2=80=9CWeb=E2=80=9D part of the =E2=80=9CCBOR Web Token=E2=80=9D= name can be taken as a reference to the Web of Things (see = https://en.wikipedia.org/wiki/Web_of_Things = ). As Erik correctly = points out JSON is not the only data representation that makes things in = the Web and the Web of Things. >>> =20 >>> -- Mike >>> =C2=A0 <> >>> From: Ace [mailto:ace-bounces@ietf.org = ] On Behalf Of Erik Wahlstr=C3=B6m >>> Sent: Tuesday, May 10, 2016 1:44 AM >>> To: Justin Richer > >>> Cc: Kathleen Moriarty >; Kepeng Li = >; = ace@ietf.org ; Carsten Bormann >; Hannes Tschofenig >; > >; cose = > >>> Subject: Re: [Ace] [COSE] Call for adoption for = draft-wahlstroem-ace-cbor-web-token-00 >>> =20 >>> Or keep the CBOR Web Token (CWT) for two major reasons: >>> - To show the very close relationship to JWT. It relies heavily on = JWT and it's iana registry. It is essentially a JWT but in CBOR/COSE = instead of JSON/JOSE. >>> - I would not say that JWT is the only format that works for the = web, and it's even used in other, non-traditional, web protocols. That = means I don't have a problem with the W in CWT at all. Why would JSON be = the only web protocol? >>> =20 >>> Then we also have one smaller (a lot smaller) reason, it's the fact = that it can be called "cot" just like JWT is called a "jot" and I = figured that our "cozy chairs" would very much like that fact because = then it's essentially a "cozy cot" :) >>> =20 >>> / Erik >>> =20 >>> =20 >>> On Tue, May 10, 2016 at 2:49 AM, Justin Richer > wrote: >>> We can also call it the =E2=80=9CCOSE Token=E2=80=9D. As a chair of = the COSE working group, I=E2=80=99m fine with that amount of = co-branding. >>>=20 >>> =E2=80=94 Justin >>>=20 >>> > On May 9, 2016, at 9:31 AM, Carsten Bormann > wrote: >>> > >>> >> draft-ietf-ace-cbor-token-00.txt; >>> > >>> > For the record, I do not think that ACE has a claim on the term = "CBOR >>> > Token". While the term token is not used in RFC 7049, there are = many >>> > tokens that could be expressed in CBOR or be used in applying CBOR = to a >>> > problem. >>> > >>> > ACE CBOR Token is fine, though. >>> > (Or, better, CBOR ACE Token, CAT.) >>> > >>> > Gr=C3=BC=C3=9Fe, Carsten >>> > >>> > _______________________________________________ >>> > COSE mailing list >>> > COSE@ietf.org >>> > https://www.ietf.org/mailman/listinfo/cose = >>>=20 >>> _______________________________________________ >>> Ace mailing list >>> Ace@ietf.org >>> https://www.ietf.org/mailman/listinfo/ace = >> _______________________________________________ >> COSE mailing list >> COSE@ietf.org >> https://www.ietf.org/mailman/listinfo/cose = --Apple-Mail=_15349204-7853-440C-A5EB-97A087AE6A22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Then how about the ACE Constrained Token (ACT)?

 =E2=80=94 = Justin

On May 10, 2016, at 10:14 AM, Phil Hunt (IDM) = <phil.hunt@oracle.com> wrote:

I don't have = this issue. I see your point, but I think the constrained branding makes = it clear. 

IOW. When the specs say "constrained web" the use means to me = that the tokens for the constrained set of binary protocols which all = tend to be in parallel architecture with web apis anyway.  

Phil

On = May 10, 2016, at 05:57, Justin Richer <jricher@mit.edu> = wrote:

You=E2=80=99re missing my original complaint: = Until this token can be directly encoded into web technologies, like = HTTP headers and HTML pages, then it has no business being called a = =E2=80=9CWeb=E2=80=9D anything. As it is, it=E2=80=99s a binary encoding = that would need an additional wrapper, like base64url perhaps, to be = placed into web spaces. It can be used in CoAP and native CBOR = structures as-is, which is what it=E2=80=99s designed to do. 

The =E2=80=9Cweb=E2=80=9D = part of JWT is very important. A JWT can be used, as-is, in any part of = an HTTP message: headers, query, form, etc. It can also be encoded as a = string in other data structures in just about any language without any = additional transformation, including HTML, XML, and JSON. This makes the = JWT very =E2=80=9Cwebby=E2=80=9D, and this is a feature set that this = new token doesn=E2=80=99t share. Ergo, it has no business being called a = =E2=80=9Cweb=E2=80=9D token regardless of its heritage. 

Both CBOR Token and COSE = Token are fine with me. 

 =E2=80=94 Justin

On May 10, 2016, at 3:50 AM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

I also feel strongly that the name should = remain CBOR Web Token.  CWT is a beneficiary of the intellectual = and deployment heritage from the Simple Web Token (SWT) and JSON Web = Token (JWT).  CWT is intentionally parallel to JWT.  The name = should stay parallel as well.
 
The =E2=80=9CWeb=E2=80=9D = part of the =E2=80=9CCBOR Web Token=E2=80=9D name can be taken as a = reference to the Web of Things (see https://en.wikipedia.org/wiki/Web_of_Things).  As = Erik correctly points out JSON is not the only data representation that = makes things in the Web and the Web of Things.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
From: Ace [mailto:ace-bounces@ietf.org] On Behalf = Of Erik = Wahlstr=C3=B6m
Sent: Tuesday, May 10, 2016 1:44 = AM
To: Justin Richer <jricher@mit.edu>
Cc: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; Kepeng Li <kepeng.lkp@alibaba-inc.com>; ace@ietf.org; Carsten = Bormann <cabo@tzi.org>; Hannes Tschofenig <hannes.tschofenig@gmx.net>; <oauth@ietf.org> <oauth@ietf.org>; cose = <cose@ietf.org>
Subject: Re: [Ace] [COSE] Call for = adoption for draft-wahlstroem-ace-cbor-web-token-00
 
Or keep the CBOR Web Token (CWT) for two major reasons:
- To show the very close relationship to JWT. It relies = heavily on JWT and it's iana registry. It is essentially a JWT but in = CBOR/COSE instead of JSON/JOSE.
- I would not say = that JWT is the only format that works for the web, and it's even used = in other, non-traditional, web protocols. That means I don't have a = problem with the W in CWT at all. Why would JSON be the only web = protocol?
 
Then we also have one smaller (a lot smaller) reason, = it's the fact that it can be called "cot" just like JWT is called a = "jot" and I figured that our "cozy chairs" would very much like that = fact because then it's essentially a "cozy cot" :)
 
/ Erik
 
 
On Tue, May 10, 2016 at 2:49 AM, Justin Richer <jricher@mit.edu> = wrote:
We = can also call it the =E2=80=9CCOSE Token=E2=80=9D. As a chair of the = COSE working group, I=E2=80=99m fine with that amount of co-branding.

 =E2=80=94 Justin

> On May 9, 2016, at 9:31 AM, Carsten Bormann <cabo@tzi.org> wrote:
>
>> draft-ietf-ace-cbor-token-00.txt;
>
> For the record, I do not think that = ACE has a claim on the term "CBOR
> Token".  While = the term token is not used in RFC 7049, there are many
> = tokens that could be expressed in CBOR or be used in applying CBOR to = a
> problem.
>
> ACE = CBOR Token is fine, though.
> (Or, better, CBOR ACE = Token, CAT.)
>
> Gr=C3=BC=C3=9Fe, = Carsten
>
> = _______________________________________________
> COSE = mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
=

_______________________________________________
COSE mailing list
COSE@ietf.org
https://www.ietf.org/mailman/listinfo/cose

= --Apple-Mail=_15349204-7853-440C-A5EB-97A087AE6A22-- From nobody Tue May 10 14:58:56 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FBC12D177 for ; Tue, 10 May 2016 14:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xH47p0yFJI7 for ; Tue, 10 May 2016 14:58:53 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BB812D15C for ; Tue, 10 May 2016 14:58:53 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id n63so15394026qkf.0 for ; Tue, 10 May 2016 14:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=fBkXnf5rWwU10A5frPIVwuNue8tSo0vrJBg/Ly3K5gg=; b=U/z9Rz2ycaovTOepBJWnenTL2Qmq839889DZLBn4Bb3G75/3Di3IxpXxZSEz5UnkQ0 AvjaI1Y0vSfgfWEjKVjsVhBK07ED+xf8rDtWscR7fKsboiEMcGbwqiSvQi6cR8wyMWQN UEX7ZKBUPrj5xyRqbDiE+Y9G4a40cnD1sz3AjXo9CNP4hKExFNq0g6CJeSimjYxEv3p9 FazrK0vh4htIwodpN9iD6yKFk8ojbKUDFOhfOVUcqvWWzxZrRITLvUEkT6keLCssWA6m rOeO74O67LsVnrkKgt67fDyJziwRcjUTacpjvksb+qj9jJlUPKWQ18xXCd4X8LfpE1t6 Oq3Q== 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; bh=fBkXnf5rWwU10A5frPIVwuNue8tSo0vrJBg/Ly3K5gg=; b=YCWA0umFehQd6j55EHunYKipii4z3oqVZ7oOtY7B98F0RtVa9FuGwTfDk9RVhq7TK4 ecsJQzhYWot7Qd0wz+1gucwye2THmnEjQ/pFZbZMkcDPimhJpftLfgIaTuQhUP+fs0Jh YVDIG3+5Gi+DizO/HPAPyqZK+LWlDSv1BM0j2XHVgP5QypCRmaercmDDG5/viss2Vdx8 LjbiKfJyqZUw1CL6hSBZR0WJh3/pR2IWwD+VOLVNuf4jbGN9BZ2aLMWRfg1T47lyUms1 sbpDL5HfI6mwaBmAPuiO+Zj13gTpiR8bJ8mnODXnh36psZFrylnc+fo0qj6mdYsH4bo0 Mkbw== X-Gm-Message-State: AOPr4FUrsL/kG26Clu+slrIEFOW3z/kVedLPloqFEdpuYhL7Q4haGbWGJOB5tevqU1WyQcV5saUMSiBknnaWqA== X-Received: by 10.55.215.25 with SMTP id m25mr12704958qki.34.1462917532834; Tue, 10 May 2016 14:58:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.102.213 with HTTP; Tue, 10 May 2016 14:58:33 -0700 (PDT) From: isciurus Date: Tue, 10 May 2016 14:58:33 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a1149adc2e161cd05328407eb Archived-At: Subject: [OAUTH-WG] Comments about PKCE / RFC7636 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 21:58:56 -0000 --001a1149adc2e161cd05328407eb Content-Type: text/plain; charset=UTF-8 Hi, I have a few comments regarding the Proof Key for Code Exchange spec: 1. I wonder how exactly PKCE guarantees the protection for native apps in the context of generic OAuth 2 flow with an external browser, considering that a malicious app can initiate an authz request itself? More precisely, I believe there are two cases PKCE doesn't cover: - Malicious app generates its own code_verifier and opens an authz request in an external browser, which allows it to follow "1.1. Protocol Flow", eavesdrop the code at the callback uri it hijacked, and exchange it for token - Malicious app abuses the "5. Compatibility" section by initiating authz request without code_verifier for clients not supporting this extension, which allows it to just eavesdrop the code at the callback uri it hijacked, and exchange it for token By using parameter such as "immediate=true" / "display=none" app can even make authz request undetectable as it would silently succeed for previously TOSed apps and considering an existing browser session on provider. 2. Is it actually meant to be a sufficient protection to just follow PKCE in the generic OAuth 2 flow case for public clients (vs. using PKCE together with other improvements, such as with native apps sso flow http://www.thread-safe.com/2015/01/napps-high-level-flow-for-ios.html)? 3. What is meant by a "secure API" in the following claim from the "1. Introduction": "Step (1) happens through a secure API that cannot be intercepted, though it may potentially be observed in advanced attack scenarios."? Thanks, Andrey --001a1149adc2e161cd05328407eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have a few comments re= garding the=C2=A0Proof Key for Code Exchange spec:

1. I wonder how exactly PKCE guarantees the protection for native apps in = the context of generic OAuth 2 flow with an external browser, considering t= hat a malicious app can initiate an authz request itself? More precisely, I= believe there are two cases PKCE doesn't cover:
- Malicious = app generates its own code_verifier and opens an authz request in an extern= al browser, which allows it to follow "1.1. Protocol Flow", eaves= drop the code at the callback uri it hijacked, and exchange it for token
- Malicious app abuses the "5. Compatibility" section by = initiating authz request without code_verifier for clients not supporting t= his extension, which allows it to just eavesdrop the code at the callback u= ri it hijacked, and exchange it for token
By using parameter such= as "immediate=3Dtrue" / "display=3Dnone" app can even = make authz request undetectable as it would silently succeed for previously= TOSed apps and considering an existing browser session on provider.
<= div>
2. Is it actually meant to be a sufficient protection to= just follow PKCE in the generic OAuth 2 flow case for public clients (vs. = using PKCE together with other improvements, such as with native apps sso f= low http://www.thread-safe.com/2015/01/napps-high-level-flow-for-ios= .html)?

3. What is meant by a "secure API= " in the following claim from the "1. Introduction":
"Step (1) happens through a secure API that cannot be
int= ercepted, though it may potentially be observed in advanced attack
scenarios."?

Thanks,
Andrey
= --001a1149adc2e161cd05328407eb-- From nobody Tue May 10 16:24:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C6C12D803 for ; Tue, 10 May 2016 16:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp6CQyymTvEN for ; Tue, 10 May 2016 16:24:37 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9466412D840 for ; Tue, 10 May 2016 16:24:37 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id s8so22939453ign.0 for ; Tue, 10 May 2016 16:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=xKLQ6fe8s/H6dXdPtM8Vve7donxvvYpMp0wayJreZ5A=; b=S80hWwiLgHQQLU9aImk7vFYD1/AAl81RXUoNLMEgE8BrmwP8m6bSzq4PhMMJJ4Q+Cc O3OOao3V6fT6DYM31zUcX2sghzAxsUm9sG7MaY5MRgdA+zQlz9AdnhQUkydohIhhEa/Z wqbPtaGGQUK/8TpOuoOrmf16O4D8TotLXdejewg/BjyKaPJvx5UH9UTnTUEdMjNf2G53 BcFz2qjbkUIQaj/bIDS/1uS5hkC9xIpPrLmoOyeKbqxkUYbGQ9rAfdNepEHoREEMtWkU 8rH/vkWf/NuyuBmKdjDpXvHBzKuG6X+GEprpQBBtFNzg6917JiXtGzl23PCk4BNaB1e7 Ou+w== 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; bh=xKLQ6fe8s/H6dXdPtM8Vve7donxvvYpMp0wayJreZ5A=; b=O3MxoAnFslp/fTnTW5cMv3ggFEL0h1mtJ6YIQtXyYUpzN3VdxmL4mVQqZK957nGbNZ mtVlKcA0o1zTAA2pOUeB8gzlzbJqZhbzNbkfvjc9Ru+P5BbuJ3kc9K0Fq7O/Zi5DV3gE 65eQXdo7j06mG59LmM8FJYdVehZyMvfwGhZkwYxa4X/eCnmkuHgYWpPPEpAwoL4tjgGw ROZ4FyNdXLSmkKlbA+y4vdej5WNBUCc7IicLThldLJLZVPXeooXo/QRew+qzLs2z4Un8 4FZ3VLx4gClLtEbu4SvM8yPY5m+/voBLCYFNlKebuE9JAbbkJCREL6gRYcKiXdvTHvzQ a48w== X-Gm-Message-State: AOPr4FXVdZuQDmW1WjP91/G3xWkAJAD4oZmj3rCg7YuixSmgtCgDDVR3hHSoET50eDDSMzsUbJb62R3GwKt5cA== X-Received: by 10.50.69.4 with SMTP id a4mr19302666igu.70.1462922676786; Tue, 10 May 2016 16:24:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.111.20 with HTTP; Tue, 10 May 2016 16:24:17 -0700 (PDT) From: Dick Hardt Date: Tue, 10 May 2016 16:24:17 -0700 Message-ID: To: Oauth Wrap Wg Content-Type: multipart/alternative; boundary=047d7bfe9aba7bdcac0532853a95 Archived-At: Subject: [OAUTH-WG] TAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 23:24:41 -0000 --047d7bfe9aba7bdcac0532853a95 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Does anyone think there are useful lessons here? Does adding TOKBIND resolve the issues? https://blog.teller.io/2016/04/26/tauth.html *Teller* Join waiting list Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it This week we released our authorisation flow making it possible for you to go from building apps that talk to your bank account, to building apps that can talk to any bank account. This is huge. Check out this SMS bot (how on trend) I hacked up yesterday morning. (and don't forget to join the beta wait list ). Getting to this point took longer than we expected. This is because there wasn't a good story for delegating authorisation for sensitive APIs. The most popular choice, OAuth 2.0 - which has been chosen by the Open Banking Working Group = , BBVA , RBS , and Mondo - is also amongst the worst from a security perspective. Teller provides an API for your bank account. The EU is forcing all European banks to expose account APIs with PSD II by end of 2017. These banks are disconcertingly converging around OAuth 2.0* without fully considering the impact on their customers, and something needs to be done before it's too late. * One notable exception is the Open Bank Project . It is sticking with OAuth 1.0a precisely because OAuth 1.0a doesn't share the same security issues as OAuth 2.0. Man-in-the-middle One of the biggest problems with OAuth 2.0 is that it delegates all security concerns to TLS but only the client authenticates the server (via it's SSL certificate), the server does not authenticate the client. This means the server has no way of knowing who is actually sending the request. Is it a bona fide user, or is an attacker tampering with the request? When an attacker is able to insinuate themselves between a legitimate user and the server, it's called a man-in-the-middle (MITM) attack. It looks like this: - client attempts to connect to service - attacker successfully reroutes traffic to a host it controls - malicious host accepts connection from client - malicious host connects to service - service accepts connection from malicious host - client communicates with service proxied through malicious host, which can see and tamper with any data sent or received You're probably thinking "hang on, isn't this the point of SSL?" Yes it is, but there are a number of ways to present a bogus certificate and a client accept it. The most realistic threat is the client developer not properly verifying the server certificate, i.e. was it ultimately signed by a trusted certificate authority? *Follow* *Tim Pope* =E2=80=8E@tpope Pull requests to disable SSL certificate verification: more common than you would think. 2:24 PM - 11 Feb 2013 - 5 5 Retweets 5 5 li= kes Unfortunately a large number of developers think that disabling SSL peer verification is the correct fix to a SSL path validation error. There are many more that will offer the same advice with the caveat that it introduces a security issue that < 100% of readers will consider. As an API provider with a duty of care to our users we can't simply hope developers on our platform don't do this. Bearer tokens Once a user authorises a client application to access its account, the application obtains a bearer token from the authorisation server. As the name suggests if you have possession of the bearer token then you are essentially the user. There is no cryptographic proof that the requesting client is the intended developer and not an attacker. If an attacker is able to successfully MITM a client it could have catastrophic implications for the user, e.g. an empty bank account, loans opened in their name, etc. OAuth 2.0 is simply a security car crash from a bank's perspective. They have no way to prove that an API transaction is bona fide, exposing them to unlimited liability. For more information on OAuth 2.0 shortcomings see OAuth Bearer Tokens are a Terrible Idea and OAuth 2.0 and the Road to Hell by Eran Hammer the original primary author of OAuth 2.0 who formally removed his name from the standard, calling it "the biggest professional disappointment of [his] career." Finding something better Sitting down to design the solution to this problem I had two high-level goals: - be the most secure solution for the user - not unnecessarily impede developer experience. Developers are users too and their needs deserve equal consideration. >From a security perspective I wanted: - cryptographic proof of client identity - to stop MITM attacks - to unimpeachably attribute a request to a given developer. In cryptography this is known as non-repudiation . (N.B. Non-repudiation is a de facto requirement of PSD II. If a bank can't prove an account owner authorised a transaction, they're liable for any losses incurred by the user.) There are solutions to the bearer token problem like JWT tokens (RFC7523 ) but in most cases these rely on a shared secret which is used to computed a HMAC-based signature. Shared secrets mean no non-repudiation. Public key cryptography can be used with JWT tokens but they don't solve the problem of how the client will generate key pairs, demonstrate proof of possession of the private key, and enrol the public key with the API. Most importantly using JWT tokens make it basically impossible for you to experiment with an API using cURL. A major impediment to developer experience. In an ideal world we'd have cryptographic proof of the client's identity without it having to leak through the application level (and stop us cURLing the API!). As I thought about it it became the clear the answer was hiding in plain sight: *SSL client certificates.* Client SSL Authentication A SSL handshake involving client certificates contains an extra message at the end of the handshake, the *CertificateVerify* message. Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Fig. 1 - Message flow for a full handshake The client collects all the handshake messages and signs them with it's private key and sends the result to the server. The server then verifies the signature using the public key of the client certificate. If the signature can be verified with the public key, the server knows the client is in possession of the private key, and is therefore a bona fide user. Let's look at this in the context of our original attack: - client attempts to connect to service - attacker successfully reroutes traffic to a host it controls - malicious host accepts connection from client accepting the client's certificate - malicious host connects to service - the malicious host will fail to SSL handshake because the host doesn= =E2=80=99t have the private key for the client=E2=80=99s certificate. The attacker = therefore cannot compute the correct *CertificateVerify* handshake message. The *CertificateVerify* message from the first handshake cannot be used because the handshake sequences diverge (different server certificates presented by the host). Introducing TAuth TAuth is Client SSL Authentication + User Tokens + Great Tooling. Client SSL authentication is often overlooked because of the poor UX of using client certificates in the browser and that generating certificates is a painful multistep process involving arcane OpenSSL CLI incantations. However as we're talking about API clients the browser UX point is irrelevant. As far as certificate generation goes, we can write better tools. These days it's possible to generate a key pair, a PKCS#10 certificate request, and sign it all in the browser. Thanks to WebCrypto the whole process is reduced to one click. This is how Teller does it: A private key and a SSL certificate signed by Teller generated in one click= . And this is what a request looks like with client certificates: Let's recap what we've achieved here: - Cryptographic proof of the client identity - The cURLability of the API is preserved - The client developer has generated a private key known only to them and no one else, meaning the bank can actually say "you did that transaction" (non-repudiation) Token security Notice in the above example. The Teller API accepts connections from clients without a client certificate. We do this because we provide developers with read-only personal access tokens for their own accounts if they want to quickly hack something up and not bother with provisioning certs. Now notice how the API does not accept the token presented, but accepts it when used with the client SSL certificate. TAuth bearer tokens are bound on the server side to a private key through an application. This means they are useless without the private key (which only the developer ever has) and therefore not sensitive. As matter of fact, here is one for my bank account: You'll need the private key it's bound to for it to be of any use, and that has never left my laptop. TAuth tokens do not expire (but can be revoked). OAuth 2.0 introduced the concept of time-limited tokens. Large internet companies found it useful for scaling purposes to issue self-encoded, encrypted tokens. The drawbacks are developers have to pay the complexity cost of refreshing tokens and most importantly tokens cannot be revoked, they're good until they expire. For bank account APIs this is an undesirable property, a token should be void as soon as the account owner wishes. TAuth checks the token revocation status at each request. Given that we have no need for self-encoded tokens and that tokens are useless to anyone without the private key, we can consider them public and directly return them in the callback further simplifying things for the developer compared to OAuth without compromising the user's security. Bonus: DDOS mitigation TAuth can help mitigate layer 7 based DDOS attacks too. If the client does not present a valid client certificate the server can just choose to bounce the connection. Conclusion OAuth 2.0 is simply not fit for use with sensitive APIs and all the pieces needed to build something that is exist today. Aside from unbound bearer tokens, OAuth is too open-ended and complicated to get right for most developers. It's so bad it even has it's own threat model as a separate RFC to offer mitigations for the endless problems that can happen. *TAuth stands for Trusted Authentication*, and it provides the best security for users while maintaining the highest possible quality developer experience. Less can go wrong when everything is simpler. *If your bank has OAuth 2.0 in production you must ask yourself, do they really know what they're doing?* TAuth is available in production today for our existing beta users and we've already begun the work to make it an open standard we hope the industry adopts. If you're at a bank and want to offer your customers the security they deserve email me - *sg at teller.io * Sign up for the beta waiting list at Teller.io . --047d7bfe9aba7bdcac0532853a95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Does anyone think there are useful lessons here?

<= /div>
Does adding TOKBIND resolve the issues?


=

Telle= r

Join = waiting list

Introducing TAuth: Why OAuth 2.0 is bad for = banking APIs and how we're fixing it

This week we released our authorisation flow= making it possible for you to go from building apps that talk to your bank= account, to building apps that can talk to any bank account. This is huge.= Check out this SMS bot (how on trend) I hacked up yesterday morning. (and = don't forget to join th= e beta wait list).


Getting to this point took longer than we ex= pected. This is because there wasn't a good story for delegating author= isation for sensitive APIs. The most popular choice, OAuth 2.0 - which has been chosen by t= he Ope= n Banking Working Group, BBVA, RBS, and Mondo - is also= amongst the worst from a security perspective.

Teller provides an API for your bank account= . The EU is forcing all European banks to expose account APIs with PSD II by end of 2017. These banks are disconcertingly co= nverging around OAuth 2.0* without fully considering the impact on their cu= stomers, and something needs to be done before it's too late.

* One notable exception is the Open Bank Project. It is sticking with OAuth 1.0a precisely because OAuth 1.0a doesn't share = the same security issues as OAuth 2.0.

Man-in-the-middle

One of the biggest problems with OAuth 2.0 i= s that it delegates all security concerns to TLS but only the client authen= ticates the server (via it's SSL certificate), the server does not auth= enticate the client. This means the server has no way of knowing who is act= ually sending the request. Is it a bona fide user, or is an attacker tamper= ing with the request? When an attacker is able to insinuate themselves betw= een a legitimate user and the server, it's called a man-in-the-middle (= MITM) attack. It looks like this:

  • client attempts to = connect to service
  • attacker successfully reroutes traffic to a= host it controls
  • malicious host accepts connection from clie= nt
  • malicious host connects to service
  • service accepts connection from malicious h= ost
  • client communicates with service proxied th= rough malicious host, which can see and tamper with any data sent or receiv= ed

You're probably thinking "hang on, = isn't this the point of SSL?" Yes it is, but there are a number of= ways to present a bogus certificate and a client accept it. The most reali= stic threat is the client developer not properly verifying the server certi= ficate, i.e. was it ultimately signed by a trusted certificate authority?

Fol= low


Tim= Pope =E2=80=8E@tpope

Pull requests to disable SSL certificate ver= ification: more common than you would think.

2:24 PM - 11 Feb 2013

Unfortunately a large number = of = developers think that disabling SSL peer verification is the cor= rect fix to a SSL path validation error. There are many more that will offe= r the same advice with the caveat that it introduces a security issue that < 100% of readers will consider. As an API provider with a duty = of care to our users we can't simply hope developers on our platform do= n't do this.

Bearer tokens

Once a user authorises a client application = to access its account, the application obtains a bearer token from the auth= orisation server. As the name suggests if you have possession of the bearer= token then you are essentially the user. There is no cryptographic proof t= hat the requesting client is the intended developer and not an attacker. If= an attacker is able to successfully MITM a client it could have catastroph= ic implications for the user, e.g. an empty bank account, loans opened in t= heir name, etc. OAuth 2.0 is simply a security car crash from a bank's = perspective. They have no way to prove that an API transaction is bona fide= , exposing them to unlimited liability.

For more information on OAuth 2.0 shortcomin= gs see OAuth Bearer Tokens are a Terrible Idea= and OAuth 2.0 and the Road to Hell by Eran Hamm= er the original primary author of OAuth 2.0 who formally removed= his name from the standard, calling it "the biggest professional disa= ppointment of [his] career."

Finding something better

Sitting down to design the solution to this = problem I had two high-level goals:

  • be the most secure = solution for the user
  • not unnecessarily impede developer experien= ce. Developers are users too and their needs deserve equal consideration.

From a security perspective I wanted:=

  • cryptographic proof= of client identity
  • to stop MITM attacks
  • to unimpeachably attribute a request to a g= iven developer. In cryptography this is known as non-repudiation= .

(N.B. Non-repudiation is a de facto requirem= ent of PSD II. If a bank can't prove an account owner authorised a tran= saction, they're liable for any losses incurred by the user.)

There are solutions to the bearer token prob= lem like JWT tokens (RFC7523) but in most cases these rely on a shared sec= ret which is used to computed a HMAC-based signature. Shared secrets mean n= o non-repudiation. Public key cryptography can be used with JWT tokens but = they don't solve the problem of how the client will generate key pairs,= demonstrate proof of possession of the private key, and enrol the public k= ey with the API. Most importantly using JWT tokens make it basically imposs= ible for you to experiment with an API using cURL. A major impediment to de= veloper experience.

In an ideal world we'd have cryptographi= c proof of the client's identity without it having to leak through the = application level (and stop us cURLing the API!). As I thought about it it = became the clear the answer was hiding in plain sight: SSL client certificates.

Client SSL Authentication

A SSL handshake involving client certificate= s contains an extra message at the end of the handshake, the CertificateVerify message.

=C2=A0 Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server


=C2=A0 ClientHello=C2=A0 =C2=A0 =C2=A0 =C2= =A0 -------->

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ServerHello

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Certificate*

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ServerKeyExchange*

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 CertificateRequest*

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <--------=C2=A0 =C2=A0 =C2=A0 ServerHell= oDone

=C2=A0 Certificate*

=C2=A0 ClientKeyExchange

=C2=A0 CertificateVerify*

=C2=A0 [ChangeCipherSpec]

=C2=A0 Finished =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 -------->

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [= ChangeCipherSpec]

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-------- =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Finished

=C2=A0 Application Data =C2=A0 <-------&g= t; =C2=A0 =C2=A0 Application Data


=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 Fig. 1 - M= essage flow for a full handshake

The client collects all the handshake messag= es and signs them with it's private key and sends the result to the ser= ver. The server then verifies the signature using the public key of the cli= ent certificate. If the signature can be verified with the public key, the = server knows the client is in possession of the private key, and is therefo= re a bona fide user.

Let's look at this in the context of our= original attack:

  • client attempts to = connect to service
  • attacker successfully reroutes traffic to a= host it controls
  • malicious host accepts connection from clie= nt accepting the client's certificate
  • malicious host connects to service
  • the malicious host will fail to SSL handsha= ke because the host doesn=E2=80=99t have the private key for the client=E2= =80=99s certificate. The attacker therefore cannot compute the correct CertificateVerify handsh= ake message. The CertificateVerify message from the first handshake cannot be used because the = handshake sequences diverge (different server certificates presented by the= host).

Introducing TAuth

TAuth is Client SSL Authentication + User To= kens + Great Tooling.

Client SSL authentication is often overlooke= d because of the poor UX of using client certificates in the browser and th= at generating certificates is a painful multistep process involving arcane = OpenSSL CLI incantations. However as we're talking about API clients th= e browser UX point is irrelevant. As far as certificate generation goes, we= can write better tools. These days it's possible to generate a key pai= r, a PKCS#10 certificate request, and sign it all in the browser. Thanks to= WebCrypto<= /span> the whole process is reduced to one click.

This is how Teller does it:

A private key and a SSL certificate signed b= y Teller generated in one click.

And this is what a request looks like with c= lient certificates:

Let's recap what we've achieved here= :

  • Cryptographic proof= of the client identity
  • The cURLability of the API is preserved
  • The client developer has generated a privat= e key known only to them and no one else, meaning the bank can actually say= "you did that transaction" (non-repudiation)

Token security

Notice in the above example. The Teller API = accepts connections from clients without a client certificate. We do this b= ecause we provide developers with read-only personal access tokens for thei= r own accounts if they want to quickly hack something up and not bother wit= h provisioning certs. Now notice how the API does not accept the token pres= ented, but accepts it when used with the client SSL certificate. TAuth bear= er tokens are bound on the server side to a private key through an applicat= ion. This means they are useless without the private key (which only the de= veloper ever has) and therefore not sensitive. As matter of fact, here is o= ne for my bank account:


You'll need the private key it's bou= nd to for it to be of any use, and that has never left my laptop.

TAuth tokens do not expire (but can be revok= ed). OAuth 2.0 introduced the concept of time-limited tokens. Large interne= t companies found it useful for scaling purposes to issue self-encoded, enc= rypted tokens. The drawbacks are developers have to pay the complexity cost= of refreshing tokens and most importantly tokens cannot be revoked, they&#= 39;re good until they expire. For bank account APIs this is an undesirable = property, a token should be void as soon as the account owner wishes. TAuth= checks the token revocation status at each request.

Given that we have no need for self-encoded = tokens and that tokens are useless to anyone without the private key, we ca= n consider them public and directly return them in the callback further sim= plifying things for the developer compared to OAuth without compromising th= e user's security.

Bonus: DDOS mitigation

TAuth can help mitigate layer = 7 based DDOS attacks too. If the client does not present a valid= client certificate the server can just choose to bounce the connection.

Conclusion

OAuth 2.0 is simply not fit for use with sen= sitive APIs and all the pieces needed to build something that is exist toda= y. Aside from unbound bearer tokens, OAuth is too open-ended and complicate= d to get right for most developers. It's so bad it even has it's ow= n threat model as a separate RFC to offer mitigations for the endless prob= lems that can happen.

TAuth stands for Trusted Authentication, and it provides the best security for users whi= le maintaining the highest possible quality developer experience. Less can = go wrong when everything is simpler. If your ban= k has OAuth 2.0 in production you must ask yourself, do they really know wh= at they're doing?

TAuth is available in production today for o= ur existing beta users and we've already begun the work to make it an o= pen standard we hope the industry adopts. If you're at a bank and want = to offer your customers the security they deserve email me - sg at teller.io

Sign up for the beta waiting list at Teller.io.

--047d7bfe9aba7bdcac0532853a95-- From nobody Tue May 10 16:44:27 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E4312D0CE for ; Tue, 10 May 2016 16:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Srfpb3CZcOai for ; Tue, 10 May 2016 16:44:20 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E1412B017 for ; Tue, 10 May 2016 16:44:20 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id iv1so10567922pac.2 for ; Tue, 10 May 2016 16:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=N1LiufLp9TOr/d2AG8P8TL3r/nfNB/z3pD0rT7XT3ZY=; b=BWjT5tvjFFn/OjrQ0swxrycotKtz35ti6aGkpa011CXoyerB89UazmxD1fqCpDUbDj c77QqSNMWRlxsdO9N1F/Z3JAX6hRfYlvhKPfnApRDeYlx+qoDkb1UcSmoHjdHYS2su3h nLsRZd1h5VK7z0daeQv7KVXhMz8/F7SdITeRrzEtcpcirGPwBsdSVFvHBV9uCexfMJWL mQ0jayBldEaL17YGkNnGq2muftes82Pp34zrl0hUG4XHrGHYcRlR+j2vSQk/iLph6vC7 gIfOuf8spQg1wOmCsNUU805FQOlki0q5uyBx1T8/YmUVTybfZKvTcFxsfZR3AnKnNEKq k/yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=N1LiufLp9TOr/d2AG8P8TL3r/nfNB/z3pD0rT7XT3ZY=; b=T/iDjNrAvPKdHE1OojeCsEYmYZV9J+aNrygcVOdHRmNjfeWA7dPfeYhv+JJvDiRZz8 wxWWNRmbjfeSzq0KTxTE2SCTlUBoNkXa64BIl2mk5FVS8m2Sdkw5TZK57akoGlBtJ2Nk QnMTkSai5RGAhco8NzgUaDKDOmqDDTVYSkG0041iL4mIMJ20p3FQL+NkmJlSOEmEjPbf 03/ICEIIv4B8bEXGQlpugucefS8SrCztxl2yYCJTbcOybQOBkXA8jWVogrlZeBDVdow9 LacXdsNDmuiqgEvdqk0OjzwRdJhbWZezlvmCKcRN2VeN49yuizJaT447bOt3H9xbC+j9 letQ== X-Gm-Message-State: AOPr4FX+xhPeeDpNk0QnNrytOgJJ5K/vnmyabq6piF3EGKRT79T4SNWheeYSNDDU5KXVeg== X-Received: by 10.66.26.110 with SMTP id k14mr401261pag.66.1462923860350; Tue, 10 May 2016 16:44:20 -0700 (PDT) Received: from [10.0.1.3] (ip68-9-116-135.ri.ri.cox.net. [68.9.116.135]) by smtp.gmail.com with ESMTPSA id 28sm6989433pfr.89.2016.05.10.16.44.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 May 2016 16:44:19 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.15.1.160411 Date: Tue, 10 May 2016 19:44:41 -0400 From: Brock Allen To: Dick Hardt , Oauth Wrap Wg Message-ID: Thread-Topic: [OAUTH-WG] TAuth References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3545754284_1590474465" Archived-At: Subject: Re: [OAUTH-WG] TAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 23:44:25 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3545754284_1590474465 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Doesn=E2=80=99t the recent PoP work address many of these concerns? Also, as for developers disabling SSL =E2=80=94 does anyone still do this and thi= nk it=E2=80=99s safe? Or are people just being lazy? Or are there certain contexts= that I=E2=80=99m unaware of where this is valid? -Brock From: OAuth on behalf of Dick Hardt Date: Tuesday, May 10, 2016 at 7:24 PM To: Oauth Wrap Wg Subject: [OAUTH-WG] TAuth Does anyone think there are useful lessons here? Does adding TOKBIND resolve the issues? https://blog.teller.io/2016/04/26/tauth.html Teller Join waiting list Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixi= ng it This week we released our authorisation flow making it possible for you to = go from building apps that talk to your bank account, to building apps that = can talk to any bank account. This is huge. Check out this SMS bot (how on t= rend) I hacked up yesterday morning. (and don't forget to join the beta wait= list). Getting to this point took longer than we expected. This is because there w= asn't a good story for delegating authorisation for sensitive APIs. The most= popular choice, OAuth 2.0 - which has been chosen by the Open Banking Worki= ng Group, BBVA, RBS, and Mondo - is also amongst the worst from a security p= erspective. Teller provides an API for your bank account. The EU is forcing all Europea= n banks to expose account APIs with PSD II by end of 2017. These banks are d= isconcertingly converging around OAuth 2.0* without fully considering the im= pact on their customers, and something needs to be done before it's too late= . * One notable exception is the Open Bank Project. It is sticking with OAuth= 1.0a precisely because OAuth 1.0a doesn't share the same security issues as= OAuth 2.0. Man-in-the-middle One of the biggest problems with OAuth 2.0 is that it delegates all securit= y concerns to TLS but only the client authenticates the server (via it's SSL= certificate), the server does not authenticate the client. This means the s= erver has no way of knowing who is actually sending the request. Is it a bon= a fide user, or is an attacker tampering with the request? When an attacker = is able to insinuate themselves between a legitimate user and the server, it= 's called a man-in-the-middle (MITM) attack. It looks like this: client attempts to connect to service attacker successfully reroutes traffic to a host it controls malicious host accepts connection from client malicious host connects to service service accepts connection from malicious host client communicates with service proxied through malicious host, which can = see and tamper with any data sent or received You're probably thinking "hang on, isn't this the point of SSL?" Yes it is,= but there are a number of ways to present a bogus certificate and a client = accept it. The most realistic threat is the client developer not properly ve= rifying the server certificate, i.e. was it ultimately signed by a trusted c= ertificate authority? Follow Tim Pope =E2=80=8E@tpope Pull requests to disable SSL certificate verification: more common than you= would think. 2:24 PM - 11 Feb 2013 5 5 Retweets 5 5 likes Unfortunately a large number of developers think that disabling SSL peer ve= rification is the correct fix to a SSL path validation error. There are many= more that will offer the same advice with the caveat that it introduces a s= ecurity issue that < 100% of readers will consider. As an API provider with = a duty of care to our users we can't simply hope developers on our platform = don't do this. Bearer tokens Once a user authorises a client application to access its account, the appl= ication obtains a bearer token from the authorisation server. As the name su= ggests if you have possession of the bearer token then you are essentially t= he user. There is no cryptographic proof that the requesting client is the i= ntended developer and not an attacker. If an attacker is able to successfull= y MITM a client it could have catastrophic implications for the user, e.g. a= n empty bank account, loans opened in their name, etc. OAuth 2.0 is simply a= security car crash from a bank's perspective. They have no way to prove tha= t an API transaction is bona fide, exposing them to unlimited liability. For more information on OAuth 2.0 shortcomings see OAuth Bearer Tokens are = a Terrible Idea and OAuth 2.0 and the Road to Hell by Eran Hammer the origin= al primary author of OAuth 2.0 who formally removed his name from the standa= rd, calling it "the biggest professional disappointment of [his] career." Finding something better Sitting down to design the solution to this problem I had two high-level go= als: be the most secure solution for the user not unnecessarily impede developer experience. Developers are users too and= their needs deserve equal consideration. >From a security perspective I wanted: cryptographic proof of client identity to stop MITM attacks to unimpeachably attribute a request to a given developer. In cryptography = this is known as non-repudiation. (N.B. Non-repudiation is a de facto requirement of PSD II. If a bank can't = prove an account owner authorised a transaction, they're liable for any loss= es incurred by the user.) There are solutions to the bearer token problem like JWT tokens (RFC7523) b= ut in most cases these rely on a shared secret which is used to computed a H= MAC-based signature. Shared secrets mean no non-repudiation. Public key cryp= tography can be used with JWT tokens but they don't solve the problem of how= the client will generate key pairs, demonstrate proof of possession of the = private key, and enrol the public key with the API. Most importantly using J= WT tokens make it basically impossible for you to experiment with an API usi= ng cURL. A major impediment to developer experience. In an ideal world we'd have cryptographic proof of the client's identity wi= thout it having to leak through the application level (and stop us cURLing t= he API!). As I thought about it it became the clear the answer was hiding in= plain sight: SSL client certificates. Client SSL Authentication A SSL handshake involving client certificates contains an extra message at = the end of the handshake, the CertificateVerify message. Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data Fig. 1 - Message flow for a full handshake The client collects all the handshake messages and signs them with it's pri= vate key and sends the result to the server. The server then verifies the si= gnature using the public key of the client certificate. If the signature can= be verified with the public key, the server knows the client is in possessi= on of the private key, and is therefore a bona fide user. Let's look at this in the context of our original attack: client attempts to connect to service attacker successfully reroutes traffic to a host it controls malicious host accepts connection from client accepting the client's certif= icate malicious host connects to service the malicious host will fail to SSL handshake because the host doesn=E2=80=99t ha= ve the private key for the client=E2=80=99s certificate. The attacker therefore ca= nnot compute the correct CertificateVerify handshake message. The Certificat= eVerify message from the first handshake cannot be used because the handshak= e sequences diverge (different server certificates presented by the host). Introducing TAuth TAuth is Client SSL Authentication + User Tokens + Great Tooling. Client SSL authentication is often overlooked because of the poor UX of usi= ng client certificates in the browser and that generating certificates is a = painful multistep process involving arcane OpenSSL CLI incantations. However= as we're talking about API clients the browser UX point is irrelevant. As f= ar as certificate generation goes, we can write better tools. These days it'= s possible to generate a key pair, a PKCS#10 certificate request, and sign i= t all in the browser. Thanks to WebCrypto the whole process is reduced to on= e click. This is how Teller does it: A private key and a SSL certificate signed by Teller generated in one click= . And this is what a request looks like with client certificates: Let's recap what we've achieved here: Cryptographic proof of the client identity The cURLability of the API is preserved The client developer has generated a private key known only to them and no = one else, meaning the bank can actually say "you did that transaction" (non-= repudiation) Token security Notice in the above example. The Teller API accepts connections from client= s without a client certificate. We do this because we provide developers wit= h read-only personal access tokens for their own accounts if they want to qu= ickly hack something up and not bother with provisioning certs. Now notice h= ow the API does not accept the token presented, but accepts it when used wit= h the client SSL certificate. TAuth bearer tokens are bound on the server si= de to a private key through an application. This means they are useless with= out the private key (which only the developer ever has) and therefore not se= nsitive. As matter of fact, here is one for my bank account: You'll need the private key it's bound to for it to be of any use, and that= has never left my laptop. TAuth tokens do not expire (but can be revoked). OAuth 2.0 introduced the c= oncept of time-limited tokens. Large internet companies found it useful for = scaling purposes to issue self-encoded, encrypted tokens. The drawbacks are = developers have to pay the complexity cost of refreshing tokens and most imp= ortantly tokens cannot be revoked, they're good until they expire. For bank = account APIs this is an undesirable property, a token should be void as soon= as the account owner wishes. TAuth checks the token revocation status at ea= ch request. Given that we have no need for self-encoded tokens and that tokens are usel= ess to anyone without the private key, we can consider them public and direc= tly return them in the callback further simplifying things for the developer= compared to OAuth without compromising the user's security. Bonus: DDOS mitigation TAuth can help mitigate layer 7 based DDOS attacks too. If the client does = not present a valid client certificate the server can just choose to bounce = the connection. Conclusion OAuth 2.0 is simply not fit for use with sensitive APIs and all the pieces = needed to build something that is exist today. Aside from unbound bearer tok= ens, OAuth is too open-ended and complicated to get right for most developer= s. It's so bad it even has it's own threat model as a separate RFC to offer = mitigations for the endless problems that can happen. TAuth stands for Trusted Authentication, and it provides the best security = for users while maintaining the highest possible quality developer experienc= e. Less can go wrong when everything is simpler. If your bank has OAuth 2.0 = in production you must ask yourself, do they really know what they're doing? TAuth is available in production today for our existing beta users and we'v= e already begun the work to make it an open standard we hope the industry ad= opts. If you're at a bank and want to offer your customers the security they= deserve email me - sg at teller.io Sign up for the beta waiting list at Teller.io. _______________________________________________ OAuth mailing list OAuth@ie= tf.org https://www.ietf.org/mailman/listinfo/oauth --B_3545754284_1590474465 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Doesn’t the rec= ent PoP work address many of these concerns?

Also, = as for developers disabling SSL — does anyone still do this and think = it’s safe? Or are people just being lazy? Or are there certain context= s that I’m unaware of where this is valid?

-Brock


From: OAuth <= ;oauth-bounces@ietf.org> on b= ehalf of Dick Hardt <dick.hardt@gma= il.com>
Date: Tuesday, May = 10, 2016 at 7:24 PM
To: Oauth Wrap= Wg <OAuth@ietf.org>
Subject: [OAUTH-WG] TAuth

Does anyone t= hink there are useful lessons here?

Does adding TOKBIND r= esolve the issues?

https://blog.teller.io/2016/04/26/tauth.html

Teller

Join waiting list

Introducing TAuth: Why OAuth 2.0 is bad for ban= king APIs and how we're fixing it

This = week we released our authorisation flow making it possible for you to go fro= m building apps that talk to your bank account, to building apps that can ta= lk to any bank account. This is huge. Check out this SMS bot (how on trend) = I hacked up yesterday morning. (and don't forget to join the beta wait list).


Getting to this = point took longer than we expected. This is because there wasn't a good stor= y for delegating authorisation for sensitive APIs. The most popular choice, = OAuth 2.0 - which has= been chosen by the Open Banking Working Group, BBVA, RBS, and Mondo - is also amon= gst the worst from a security perspective.

Teller provides an API for your bank account. The EU is forcing all Euro= pean banks to expose account APIs with PSD II by end of = 2017. These banks are disconcertingly converging around OAuth 2.0* without f= ully considering the impact on their customers, and something needs to be do= ne before it's too late.

* One notable = exception is the Op= en Bank Project. It is sticking with OAuth 1.0a precisely because OAuth 1.0a = doesn't share the same security issues as OAuth 2.0.

<= span class=3D"">Man-in-the-middle

One of = the biggest problems with OAuth 2.0 is that it delegates all security concer= ns to TLS but only the client authenticates the server (via it's SSL certifi= cate), the server does not authenticate the client. This means the server ha= s no way of knowing who is actually sending the request. Is it a bona fide u= ser, or is an attacker tampering with the request? When an attacker is able = to insinuate themselves between a legitimate user and the server, it's calle= d a man-in-the-middle (MITM) attack. It looks like this:

  • client attempts to con= nect to service
  • attacker successfully= reroutes traffic to a host it controls
  • malicious host accepts connection from client
  • malicious host connects to service
  • service accepts connection from malicious host
  • client communicates with service proxied through malicio= us host, which can see and tamper with any data sent or received
    • =

You're probably thinking "hang on, isn't thi= s the point of SSL?" Yes it is, but there are a number of ways to present a = bogus certificate and a client accept it. The most realistic threat is the c= lient developer not properly verifying the server certificate, i.e. was it u= ltimately signed by a trusted certificate authority?

<= span class=3D"">Follow


Tim Pope =E2=80=8E@tpope

Pull requests to = disable SSL certificate verification: more common than you would think.

2:24 PM - 11 Feb 2013

Unfortunately a large number<= /a> of d= evelopers think that disabling SSL peer verification is the corre= ct fix to a SSL path validation error. There are many more that will offer t= he same advice with the caveat that it introduces a security issue that &= lt; 100% of readers will consider. As an API provider with a duty of care to= our users we can't simply hope developers on our platform don't do this.

Bearer tokens

Once a user authorises a client application to access its account,= the application obtains a bearer token from the authorisation server. As th= e name suggests if you have possession of the bearer token then you are esse= ntially the user. There is no cryptographic proof that the requesting client= is the intended developer and not an attacker. If an attacker is able to su= ccessfully MITM a client it could have catastrophic implications for the use= r, e.g. an empty bank account, loans opened in their name, etc. OAuth 2.0 is= simply a security car crash from a bank's perspective. They have no way to = prove that an API transaction is bona fide, exposing them to unlimited liabi= lity.

For more information on OAuth 2.0= shortcomings see OAuth Bearer Tokens are a Terrible= Idea and OAuth 2.0 and the Road to Hell by Eran Hammer the original primary author of OAuth 2.0 who formally removed his na= me from the standard, calling it "the biggest professional disappointment of= [his] career."

Finding something bette= r

Sitting down to design the solution t= o this problem I had two high-level goals:

  • be the most secure solution for the = user
  • not unnecessarily impede develop= er experience. Developers are users too and their needs deserve equal consid= eration.

From a security perspect= ive I wanted:

  • cryptographic proof of client identity
  • to stop MITM attacks
  • to = unimpeachably attribute a request to a given developer. In cryptography this= is known as non-repudiation.

(N.B. Non-repudiation is a de facto requirement of PSD II. If a bank can'= t prove an account owner authorised a transaction, they're liable for any lo= sses incurred by the user.)

There are s= olutions to the bearer token problem like JWT tokens (RFC7523) but in most cases= these rely on a shared secret which is used to computed a HMAC-based signat= ure. Shared secrets mean no non-repudiation. Public key cryptography can be = used with JWT tokens but they don't solve the problem of how the client will= generate key pairs, demonstrate proof of possession of the private key, and= enrol the public key with the API. Most importantly using JWT tokens make i= t basically impossible for you to experiment with an API using cURL. A major= impediment to developer experience.

In= an ideal world we'd have cryptographic proof of the client's identity witho= ut it having to leak through the application level (and stop us cURLing the = API!). As I thought about it it became the clear the answer was hiding in pl= ain sight: SSL client certificates.

<= p class=3D"">Client SSL Authentication

A SSL handshake involving client certificates contains an extra= message at the end of the handshake, the CertificateVerify message.

  Client        &= nbsp;                   Server<= /span>


  ClientHello        -------->

              &nbs= p;                     Ser= verHello

        &n= bsp;                     &= nbsp;     Certificate*

 =                      = ;             ServerKeyExchange*

              &nb= sp;                     Ce= rtificateRequest*

     &= nbsp;               <--------  &n= bsp;   ServerHelloDone

  Cert= ificate*

  ClientKeyExchange

  CertificateVerify*

  [ChangeCipherSpec]

  Finished           -------->=

           &nbs= p;                     [Ch= angeCipherSpec]

     &nb= sp;               <--------   &nb= sp;         Finished

  Application Data   <------->     Application D= ata


         Fig. 1 - Message flow for a full ha= ndshake

The client collects all the han= dshake messages and signs them with it's private key and sends the result to= the server. The server then verifies the signature using the public key of = the client certificate. If the signature can be verified with the public key= , the server knows the client is in possession of the private key, and is th= erefore a bona fide user.

Let's look at= this in the context of our original attack:

  • client attempts to connect to serv= ice
  • attacker successfully reroutes tr= affic to a host it controls
  • malicious= host accepts connection from client accepting the client's certificate
  • malicious host connects to service=
  • the malicious host will fail to SSL handsha= ke because the host doesn’t have the private key for the client’= s certificate. The attacker therefore cannot compute the correct CertificateVerify handshake message.= The CertificateVerify me= ssage from the first handshake cannot be used because the handshake sequence= s diverge (different server certificates presented by the host).
    • =

Introducing TAuth

TAuth is Client SSL Authentication + User Tokens + Great Tooling.=

Client SSL authentication is often ove= rlooked because of the poor UX of using client certificates in the browser a= nd that generating certificates is a painful multistep process involving arc= ane OpenSSL CLI incantations. However as we're talking about API clients the= browser UX point is irrelevant. As far as certificate generation goes, we c= an write better tools. These days it's possible to generate a key pair, a PK= CS#10 certificate request, and sign it all in the browser. Thanks to WebCrypto th= e whole process is reduced to one click.

This is how Teller does it:

A private= key and a SSL certificate signed by Teller generated in one click.

And this is what a request looks like with clie= nt certificates:

Let's recap what we've= achieved here:

  • Cryptographic proof of the client identity
  • The cURLability of the API is preserved
  • The client developer has generated a private key known= only to them and no one else, meaning the bank can actually say "you did th= at transaction" (non-repudiation)

Token security

Notice in the above exa= mple. The Teller API accepts connections from clients without a client certi= ficate. We do this because we provide developers with read-only personal acc= ess tokens for their own accounts if they want to quickly hack something up = and not bother with provisioning certs. Now notice how the API does not acce= pt the token presented, but accepts it when used with the client SSL certifi= cate. TAuth bearer tokens are bound on the server side to a private key thro= ugh an application. This means they are useless without the private key (whi= ch only the developer ever has) and therefore not sensitive. As matter of fa= ct, here is one for my bank account:


You'll need the private key it's bou= nd to for it to be of any use, and that has never left my laptop.

=

TAuth tokens do not expire (but can be revoked). = OAuth 2.0 introduced the concept of time-limited tokens. Large internet comp= anies found it useful for scaling purposes to issue self-encoded, encrypted = tokens. The drawbacks are developers have to pay the complexity cost of refr= eshing tokens and most importantly tokens cannot be revoked, they're good un= til they expire. For bank account APIs this is an undesirable property, a to= ken should be void as soon as the account owner wishes. TAuth checks the tok= en revocation status at each request.

G= iven that we have no need for self-encoded tokens and that tokens are useles= s to anyone without the private key, we can consider them public and directl= y return them in the callback further simplifying things for the developer c= ompared to OAuth without compromising the user's security.

Bonus: DDOS mitigation

TAuth can help mitigate layer 7 based DDOS attacks t= oo. If the client does not present a valid client certificate the server can= just choose to bounce the connection.

= Conclusion

OAuth 2.0 is simply not fit = for use with sensitive APIs and all the pieces needed to build something tha= t is exist today. Aside from unbound bearer tokens, OAuth is too open-ended = and complicated to get right for most developers. It's so bad it even has it= 's own threat model as a separate RFC to offer mitigations for the endless probl= ems that can happen.

TAuth stands fo= r Trusted Authentication, and it provides the best= security for users while maintaining the highest possible quality developer= experience. Less can go wrong when everything is simpler. If your bank has OAuth 2.0 in production you must ask yourself, do t= hey really know what they're doing?

TAuth is available in production today for our existing beta users and we'v= e already begun the work to make it an open standard we hope the industry ad= opts. If you're at a bank and want to offer your customers the security they= deserve email me - sg at teller.io

Sign up for the bet= a waiting list at Teller.io.

_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/= mailman/listinfo/oauth --B_3545754284_1590474465-- From nobody Tue May 10 17:05:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A7112B02B for ; Tue, 10 May 2016 17:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 26Xn5aGf0rqH for ; Tue, 10 May 2016 17:05:47 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 6A5E012B027 for ; Tue, 10 May 2016 17:05:46 -0700 (PDT) X-AuditID: 12074422-913ff7000000760a-cb-57327758889f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 8E.07.30218.85772375; Tue, 10 May 2016 20:05:44 -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 u4B05hPc011339; Tue, 10 May 2016 20:05:44 -0400 Received: from [IPv6:2607:fb90:6c4b:14ac:280b:7ee1:d991:c0d4] ([172.58.56.174]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u4B05d9S009203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 May 2016 20:05:41 -0400 Date: Tue, 10 May 2016 19:05:37 -0500 Message-ID: Importance: normal From: Justin Richer To: Brock Allen , Dick Hardt , Oauth Wrap Wg MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_353449515129040" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrBtRbhRusHeHpsWMH0fZLR7PLLI4 +fYVmwOzx85Zd9k9liz5yRTAFMVlk5Kak1mWWqRvl8CVMfndVLaCvS+YKj6v9mhgbL3P1MXI ySEhYCLRcnI9cxcjF4eQQBuTxMv5IAkQZyOjxLvNi9khnDNMElfWTQFrYRFQlWhu2MsIYgsL yEo07drCCmLzCrhJnDw1naWLkYODU0BIomuXBEiYDah8+poWsFYRgSKJDTcmMUKUC0qcnPkE rJxZIEbiSl/8BEaeWUgysxAyIGFmAXWJP/MuMUPYihJTuh+yQ5SoSSxrVUIWXsDItopRNiW3 Sjc3MTOnODVZtzg5MS8vtUjXVC83s0QvNaV0EyMoKNldlHYwTvzndYhRgINRiYd3B5dhuBBr YllxZe4hRkkOJiVR3i35RuFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHhzioFyvCmJlVWpRfkw KWkOFiVx3qDIY2FCAumJJanZqakFqUUwWRkODiUJXskyoEbBotT01Iq0zJwShDQTByfIcB6g 4VogNbzFBYm5xZnpEPlTjKZS4rzuIAkBkERGaR5cr5KQkIAa++8JOd4iazS46x7enHjgCii5 rLGyWPeKURzoPWHeDpBOHmBigpv4CmgZE9AyOTZ9kGUliQgpqQZGMbtHd3Qlt9oyiLYLqmcs U+KvbhOO/pXnum1W7ju+dNkDFlETzafvf858JFitbPJmZZ24fUbHCt2CZ9mG/bq/3fPQS9ui 1c0Sx/izlmzfHanAFL2Y/VCBZDHPMya213qRv/7XBGi9Y5M1kTqbYiRlFGr04pn4sZWLLYp7 5P2P2z3ffspQSkuJpTgj0VCLuag4EQA98qFKCQMAAA== Archived-At: Subject: Re: [OAUTH-WG] TAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 00:05:52 -0000 ----_com.samsung.android.email_353449515129040 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBwb3N0ZWQgYWJvdXQgdGhpcyB0aGUgb3RoZXIgZGF5LiBXaGF0IEkgZG9uJ3QgdW5kZXJzdGFu ZCBpcyB0aGF0IGhlJ3Mgc2F5aW5nIHBlb3BsZSBkaXNhYmxlIFRMUyBjaGVja3Mgc28gaGUncyBn b2luZyB0byBzb2x2ZSBpdCB3aXRoIG11dHVhbCBUTFM/wqAKSSBuZWVkIHRvIGVtYWlsIHRoaXMg Z3V5IGFuZCBsZWFybiBtb3JlIGFib3V0IHdoYXQgaGUncyBkb2luZy7CoAotLUp1c3RpbgrCoFNl bnQgZnJvbSBteSBwaG9uZQotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJvbTog QnJvY2sgQWxsZW4gPGJyb2NrYWxsZW5AZ21haWwuY29tPiBEYXRlOiA1LzEwLzE2ICA2OjQ0IFBN ICAoR01ULTA2OjAwKSBUbzogRGljayBIYXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb20+LCBPYXV0 aCBXcmFwIFdnIDxPQXV0aEBpZXRmLm9yZz4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gVEF1dGgg CkRvZXNu4oCZdCB0aGUgcmVjZW50IFBvUCB3b3JrIGFkZHJlc3MgbWFueSBvZiB0aGVzZSBjb25j ZXJucz8KQWxzbywgYXMgZm9yIGRldmVsb3BlcnMgZGlzYWJsaW5nIFNTTCDigJQgZG9lcyBhbnlv bmUgc3RpbGwgZG8gdGhpcyBhbmQgdGhpbmsgaXTigJlzIHNhZmU/IE9yIGFyZSBwZW9wbGUganVz dCBiZWluZyBsYXp5PyBPciBhcmUgdGhlcmUgY2VydGFpbiBjb250ZXh0cyB0aGF0IEnigJltIHVu YXdhcmUgb2Ygd2hlcmUgdGhpcyBpcyB2YWxpZD8KLUJyb2NrCgpGcm9tOiAgT0F1dGggPG9hdXRo LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdt YWlsLmNvbT4KRGF0ZTogIFR1ZXNkYXksIE1heSAxMCwgMjAxNiBhdCA3OjI0IFBNClRvOiAgT2F1 dGggV3JhcCBXZyA8T0F1dGhAaWV0Zi5vcmc+ClN1YmplY3Q6ICBbT0FVVEgtV0ddIFRBdXRoCgpE b2VzIGFueW9uZSB0aGluayB0aGVyZSBhcmUgdXNlZnVsIGxlc3NvbnMgaGVyZT8KRG9lcyBhZGRp bmcgVE9LQklORCByZXNvbHZlIHRoZSBpc3N1ZXM/CgpodHRwczovL2Jsb2cudGVsbGVyLmlvLzIw MTYvMDQvMjYvdGF1dGguaHRtbAoKVGVsbGVySm9pbiB3YWl0aW5nIGxpc3RJbnRyb2R1Y2luZyBU QXV0aDogV2h5IE9BdXRoIDIuMCBpcyBiYWQgZm9yIGJhbmtpbmcgQVBJcyBhbmQgaG93IHdlJ3Jl IGZpeGluZyBpdFRoaXMgd2VlayB3ZSByZWxlYXNlZCBvdXIgYXV0aG9yaXNhdGlvbiBmbG93IG1h a2luZyBpdCBwb3NzaWJsZSBmb3IgeW91IHRvIGdvIGZyb20gYnVpbGRpbmcgYXBwcyB0aGF0IHRh bGsgdG8geW91ciBiYW5rIGFjY291bnQsIHRvIGJ1aWxkaW5nIGFwcHMgdGhhdCBjYW4gdGFsayB0 byBhbnkgYmFuayBhY2NvdW50LiBUaGlzIGlzIGh1Z2UuIENoZWNrIG91dCB0aGlzIFNNUyBib3Qg KGhvdyBvbiB0cmVuZCkgSSBoYWNrZWQgdXAgeWVzdGVyZGF5IG1vcm5pbmcuIChhbmQgZG9uJ3Qg Zm9yZ2V0IHRvIGpvaW4gdGhlIGJldGEgd2FpdCBsaXN0KS4KR2V0dGluZyB0byB0aGlzIHBvaW50 IHRvb2sgbG9uZ2VyIHRoYW4gd2UgZXhwZWN0ZWQuIFRoaXMgaXMgYmVjYXVzZSB0aGVyZSB3YXNu J3QgYSBnb29kIHN0b3J5IGZvciBkZWxlZ2F0aW5nIGF1dGhvcmlzYXRpb24gZm9yIHNlbnNpdGl2 ZSBBUElzLiBUaGUgbW9zdCBwb3B1bGFyIGNob2ljZSwgT0F1dGggMi4wIC0gd2hpY2ggaGFzIGJl ZW4gY2hvc2VuIGJ5IHRoZSBPcGVuIEJhbmtpbmcgV29ya2luZyBHcm91cCwgQkJWQSwgUkJTLCBh bmQgTW9uZG8gLSBpcyBhbHNvIGFtb25nc3QgdGhlIHdvcnN0IGZyb20gYSBzZWN1cml0eSBwZXJz cGVjdGl2ZS5UZWxsZXIgcHJvdmlkZXMgYW4gQVBJIGZvciB5b3VyIGJhbmsgYWNjb3VudC4gVGhl IEVVIGlzIGZvcmNpbmcgYWxsIEV1cm9wZWFuIGJhbmtzIHRvIGV4cG9zZSBhY2NvdW50IEFQSXMg d2l0aCBQU0QgSUkgYnkgZW5kIG9mIDIwMTcuIFRoZXNlIGJhbmtzIGFyZSBkaXNjb25jZXJ0aW5n bHkgY29udmVyZ2luZyBhcm91bmQgT0F1dGggMi4wKiB3aXRob3V0IGZ1bGx5IGNvbnNpZGVyaW5n IHRoZSBpbXBhY3Qgb24gdGhlaXIgY3VzdG9tZXJzLCBhbmQgc29tZXRoaW5nIG5lZWRzIHRvIGJl IGRvbmUgYmVmb3JlIGl0J3MgdG9vIGxhdGUuKiBPbmUgbm90YWJsZSBleGNlcHRpb24gaXMgdGhl IE9wZW4gQmFuayBQcm9qZWN0LiBJdCBpcyBzdGlja2luZyB3aXRoIE9BdXRoIDEuMGEgcHJlY2lz ZWx5IGJlY2F1c2UgT0F1dGggMS4wYSBkb2Vzbid0IHNoYXJlIHRoZSBzYW1lIHNlY3VyaXR5IGlz c3VlcyBhcyBPQXV0aCAyLjAuTWFuLWluLXRoZS1taWRkbGVPbmUgb2YgdGhlIGJpZ2dlc3QgcHJv YmxlbXMgd2l0aCBPQXV0aCAyLjAgaXMgdGhhdCBpdCBkZWxlZ2F0ZXMgYWxsIHNlY3VyaXR5IGNv bmNlcm5zIHRvIFRMUyBidXQgb25seSB0aGUgY2xpZW50IGF1dGhlbnRpY2F0ZXMgdGhlIHNlcnZl ciAodmlhIGl0J3MgU1NMIGNlcnRpZmljYXRlKSwgdGhlIHNlcnZlciBkb2VzIG5vdCBhdXRoZW50 aWNhdGUgdGhlIGNsaWVudC4gVGhpcyBtZWFucyB0aGUgc2VydmVyIGhhcyBubyB3YXkgb2Yga25v d2luZyB3aG8gaXMgYWN0dWFsbHkgc2VuZGluZyB0aGUgcmVxdWVzdC4gSXMgaXQgYSBib25hIGZp ZGUgdXNlciwgb3IgaXMgYW4gYXR0YWNrZXIgdGFtcGVyaW5nIHdpdGggdGhlIHJlcXVlc3Q/IFdo ZW4gYW4gYXR0YWNrZXIgaXMgYWJsZSB0byBpbnNpbnVhdGUgdGhlbXNlbHZlcyBiZXR3ZWVuIGEg bGVnaXRpbWF0ZSB1c2VyIGFuZCB0aGUgc2VydmVyLCBpdCdzIGNhbGxlZCBhIG1hbi1pbi10aGUt bWlkZGxlIChNSVRNKSBhdHRhY2suIEl0IGxvb2tzIGxpa2UgdGhpczpjbGllbnQgYXR0ZW1wdHMg dG8gY29ubmVjdCB0byBzZXJ2aWNlYXR0YWNrZXIgc3VjY2Vzc2Z1bGx5IHJlcm91dGVzIHRyYWZm aWMgdG8gYSBob3N0IGl0IGNvbnRyb2xzbWFsaWNpb3VzIGhvc3QgYWNjZXB0cyBjb25uZWN0aW9u IGZyb20gY2xpZW50bWFsaWNpb3VzIGhvc3QgY29ubmVjdHMgdG8gc2VydmljZXNlcnZpY2UgYWNj ZXB0cyBjb25uZWN0aW9uIGZyb20gbWFsaWNpb3VzIGhvc3RjbGllbnQgY29tbXVuaWNhdGVzIHdp dGggc2VydmljZSBwcm94aWVkIHRocm91Z2ggbWFsaWNpb3VzIGhvc3QsIHdoaWNoIGNhbiBzZWUg YW5kIHRhbXBlciB3aXRoIGFueSBkYXRhIHNlbnQgb3IgcmVjZWl2ZWRZb3UncmUgcHJvYmFibHkg dGhpbmtpbmcgImhhbmcgb24sIGlzbid0IHRoaXMgdGhlIHBvaW50IG9mIFNTTD8iIFllcyBpdCBp cywgYnV0IHRoZXJlIGFyZSBhIG51bWJlciBvZiB3YXlzIHRvIHByZXNlbnQgYSBib2d1cyBjZXJ0 aWZpY2F0ZSBhbmQgYSBjbGllbnQgYWNjZXB0IGl0LiBUaGUgbW9zdCByZWFsaXN0aWMgdGhyZWF0 IGlzIHRoZSBjbGllbnQgZGV2ZWxvcGVyIG5vdCBwcm9wZXJseSB2ZXJpZnlpbmcgdGhlIHNlcnZl ciBjZXJ0aWZpY2F0ZSwgaS5lLiB3YXMgaXQgdWx0aW1hdGVseSBzaWduZWQgYnkgYSB0cnVzdGVk IGNlcnRpZmljYXRlIGF1dGhvcml0eT9Gb2xsb3cKVGltIFBvcGUg4oCOQHRwb3BlUHVsbCByZXF1 ZXN0cyB0byBkaXNhYmxlIFNTTCBjZXJ0aWZpY2F0ZSB2ZXJpZmljYXRpb246IG1vcmUgY29tbW9u IHRoYW4geW91IHdvdWxkIHRoaW5rLjI6MjQgUE0gLSAxMSBGZWIgMjAxMzUgNSBSZXR3ZWV0cwo1 IDUgbGlrZXNVbmZvcnR1bmF0ZWx5IGEgbGFyZ2UgbnVtYmVyIG9mIGRldmVsb3BlcnMgdGhpbmsg dGhhdCBkaXNhYmxpbmcgU1NMIHBlZXIgdmVyaWZpY2F0aW9uIGlzIHRoZSBjb3JyZWN0IGZpeCB0 byBhIFNTTCBwYXRoIHZhbGlkYXRpb24gZXJyb3IuIFRoZXJlIGFyZSBtYW55IG1vcmUgdGhhdCB3 aWxsIG9mZmVyIHRoZSBzYW1lIGFkdmljZSB3aXRoIHRoZSBjYXZlYXQgdGhhdCBpdCBpbnRyb2R1 Y2VzIGEgc2VjdXJpdHkgaXNzdWUgdGhhdCA8IDEwMCUgb2YgcmVhZGVycyB3aWxsIGNvbnNpZGVy LiBBcyBhbiBBUEkgcHJvdmlkZXIgd2l0aCBhIGR1dHkgb2YgY2FyZSB0byBvdXIgdXNlcnMgd2Ug Y2FuJ3Qgc2ltcGx5IGhvcGUgZGV2ZWxvcGVycyBvbiBvdXIgcGxhdGZvcm0gZG9uJ3QgZG8gdGhp cy5CZWFyZXIgdG9rZW5zT25jZSBhIHVzZXIgYXV0aG9yaXNlcyBhIGNsaWVudCBhcHBsaWNhdGlv biB0byBhY2Nlc3MgaXRzIGFjY291bnQsIHRoZSBhcHBsaWNhdGlvbiBvYnRhaW5zIGEgYmVhcmVy IHRva2VuIGZyb20gdGhlIGF1dGhvcmlzYXRpb24gc2VydmVyLiBBcyB0aGUgbmFtZSBzdWdnZXN0 cyBpZiB5b3UgaGF2ZSBwb3NzZXNzaW9uIG9mIHRoZSBiZWFyZXIgdG9rZW4gdGhlbiB5b3UgYXJl IGVzc2VudGlhbGx5IHRoZSB1c2VyLiBUaGVyZSBpcyBubyBjcnlwdG9ncmFwaGljIHByb29mIHRo YXQgdGhlIHJlcXVlc3RpbmcgY2xpZW50IGlzIHRoZSBpbnRlbmRlZCBkZXZlbG9wZXIgYW5kIG5v dCBhbiBhdHRhY2tlci4gSWYgYW4gYXR0YWNrZXIgaXMgYWJsZSB0byBzdWNjZXNzZnVsbHkgTUlU TSBhIGNsaWVudCBpdCBjb3VsZCBoYXZlIGNhdGFzdHJvcGhpYyBpbXBsaWNhdGlvbnMgZm9yIHRo ZSB1c2VyLCBlLmcuIGFuIGVtcHR5IGJhbmsgYWNjb3VudCwgbG9hbnMgb3BlbmVkIGluIHRoZWly IG5hbWUsIGV0Yy4gT0F1dGggMi4wIGlzIHNpbXBseSBhIHNlY3VyaXR5IGNhciBjcmFzaCBmcm9t IGEgYmFuaydzIHBlcnNwZWN0aXZlLiBUaGV5IGhhdmUgbm8gd2F5IHRvIHByb3ZlIHRoYXQgYW4g QVBJIHRyYW5zYWN0aW9uIGlzIGJvbmEgZmlkZSwgZXhwb3NpbmcgdGhlbSB0byB1bmxpbWl0ZWQg bGlhYmlsaXR5LkZvciBtb3JlIGluZm9ybWF0aW9uIG9uIE9BdXRoIDIuMCBzaG9ydGNvbWluZ3Mg c2VlIE9BdXRoIEJlYXJlciBUb2tlbnMgYXJlIGEgVGVycmlibGUgSWRlYSBhbmQgT0F1dGggMi4w IGFuZCB0aGUgUm9hZCB0byBIZWxsIGJ5IEVyYW4gSGFtbWVyIHRoZSBvcmlnaW5hbCBwcmltYXJ5 IGF1dGhvciBvZiBPQXV0aCAyLjAgd2hvIGZvcm1hbGx5IHJlbW92ZWQgaGlzIG5hbWUgZnJvbSB0 aGUgc3RhbmRhcmQsIGNhbGxpbmcgaXQgInRoZSBiaWdnZXN0IHByb2Zlc3Npb25hbCBkaXNhcHBv aW50bWVudCBvZiBbaGlzXSBjYXJlZXIuIkZpbmRpbmcgc29tZXRoaW5nIGJldHRlclNpdHRpbmcg ZG93biB0byBkZXNpZ24gdGhlIHNvbHV0aW9uIHRvIHRoaXMgcHJvYmxlbSBJIGhhZCB0d28gaGln aC1sZXZlbCBnb2FsczpiZSB0aGUgbW9zdCBzZWN1cmUgc29sdXRpb24gZm9yIHRoZSB1c2Vybm90 IHVubmVjZXNzYXJpbHkgaW1wZWRlIGRldmVsb3BlciBleHBlcmllbmNlLiBEZXZlbG9wZXJzIGFy ZSB1c2VycyB0b28gYW5kIHRoZWlyIG5lZWRzIGRlc2VydmUgZXF1YWwgY29uc2lkZXJhdGlvbi5G cm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmUgSSB3YW50ZWQ6Y3J5cHRvZ3JhcGhpYyBwcm9vZiBv ZiBjbGllbnQgaWRlbnRpdHl0byBzdG9wIE1JVE0gYXR0YWNrc3RvIHVuaW1wZWFjaGFibHkgYXR0 cmlidXRlIGEgcmVxdWVzdCB0byBhIGdpdmVuIGRldmVsb3Blci4gSW4gY3J5cHRvZ3JhcGh5IHRo aXMgaXMga25vd24gYXMgbm9uLXJlcHVkaWF0aW9uLihOLkIuIE5vbi1yZXB1ZGlhdGlvbiBpcyBh IGRlIGZhY3RvIHJlcXVpcmVtZW50IG9mIFBTRCBJSS4gSWYgYSBiYW5rIGNhbid0IHByb3ZlIGFu IGFjY291bnQgb3duZXIgYXV0aG9yaXNlZCBhIHRyYW5zYWN0aW9uLCB0aGV5J3JlIGxpYWJsZSBm b3IgYW55IGxvc3NlcyBpbmN1cnJlZCBieSB0aGUgdXNlci4pVGhlcmUgYXJlIHNvbHV0aW9ucyB0 byB0aGUgYmVhcmVyIHRva2VuIHByb2JsZW0gbGlrZSBKV1QgdG9rZW5zIChSRkM3NTIzKSBidXQg aW4gbW9zdCBjYXNlcyB0aGVzZSByZWx5IG9uIGEgc2hhcmVkIHNlY3JldCB3aGljaCBpcyB1c2Vk IHRvIGNvbXB1dGVkIGEgSE1BQy1iYXNlZCBzaWduYXR1cmUuIFNoYXJlZCBzZWNyZXRzIG1lYW4g bm8gbm9uLXJlcHVkaWF0aW9uLiBQdWJsaWMga2V5IGNyeXB0b2dyYXBoeSBjYW4gYmUgdXNlZCB3 aXRoIEpXVCB0b2tlbnMgYnV0IHRoZXkgZG9uJ3Qgc29sdmUgdGhlIHByb2JsZW0gb2YgaG93IHRo ZSBjbGllbnQgd2lsbCBnZW5lcmF0ZSBrZXkgcGFpcnMsIGRlbW9uc3RyYXRlIHByb29mIG9mIHBv c3Nlc3Npb24gb2YgdGhlIHByaXZhdGUga2V5LCBhbmQgZW5yb2wgdGhlIHB1YmxpYyBrZXkgd2l0 aCB0aGUgQVBJLiBNb3N0IGltcG9ydGFudGx5IHVzaW5nIEpXVCB0b2tlbnMgbWFrZSBpdCBiYXNp Y2FsbHkgaW1wb3NzaWJsZSBmb3IgeW91IHRvIGV4cGVyaW1lbnQgd2l0aCBhbiBBUEkgdXNpbmcg Y1VSTC4gQSBtYWpvciBpbXBlZGltZW50IHRvIGRldmVsb3BlciBleHBlcmllbmNlLkluIGFuIGlk ZWFsIHdvcmxkIHdlJ2QgaGF2ZSBjcnlwdG9ncmFwaGljIHByb29mIG9mIHRoZSBjbGllbnQncyBp ZGVudGl0eSB3aXRob3V0IGl0IGhhdmluZyB0byBsZWFrIHRocm91Z2ggdGhlIGFwcGxpY2F0aW9u IGxldmVsIChhbmQgc3RvcCB1cyBjVVJMaW5nIHRoZSBBUEkhKS4gQXMgSSB0aG91Z2h0IGFib3V0 IGl0IGl0IGJlY2FtZSB0aGUgY2xlYXIgdGhlIGFuc3dlciB3YXMgaGlkaW5nIGluIHBsYWluIHNp Z2h0OiBTU0wgY2xpZW50IGNlcnRpZmljYXRlcy5DbGllbnQgU1NMIEF1dGhlbnRpY2F0aW9uQSBT U0wgaGFuZHNoYWtlIGludm9sdmluZyBjbGllbnQgY2VydGlmaWNhdGVzIGNvbnRhaW5zIGFuIGV4 dHJhIG1lc3NhZ2UgYXQgdGhlIGVuZCBvZiB0aGUgaGFuZHNoYWtlLCB0aGUgQ2VydGlmaWNhdGVW ZXJpZnkgbWVzc2FnZS7CoCBDbGllbnTCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBTZXJ2ZXIKwqAgQ2xpZW50SGVsbG/CoCDCoCDCoCDCoCAtLS0tLS0tLT7CoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTZXJ2ZXJIZWxs b8KgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIENl cnRpZmljYXRlKsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIFNlcnZlcktleUV4Y2hhbmdlKsKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIENlcnRpZmljYXRlUmVxdWVzdCrCoMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIDwtLS0tLS0tLcKgIMKgIMKgIFNlcnZlckhlbGxvRG9uZcKgIENlcnRp ZmljYXRlKsKgIENsaWVudEtleUV4Y2hhbmdlwqAgQ2VydGlmaWNhdGVWZXJpZnkqwqAgW0NoYW5n ZUNpcGhlclNwZWNdwqAgRmluaXNoZWQgwqAgwqAgwqAgwqAgwqAgLS0tLS0tLS0+wqDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBbQ2hhbmdlQ2lwaGVyU3Bl Y13CoMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIDwtLS0tLS0tLSDCoCDCoCDCoCDCoCDC oCDCoCBGaW5pc2hlZMKgIEFwcGxpY2F0aW9uIERhdGEgwqAgPC0tLS0tLS0+IMKgIMKgIEFwcGxp Y2F0aW9uIERhdGEKwqDCoCDCoCDCoCDCoCBGaWcuIDEgLSBNZXNzYWdlIGZsb3cgZm9yIGEgZnVs bCBoYW5kc2hha2VUaGUgY2xpZW50IGNvbGxlY3RzIGFsbCB0aGUgaGFuZHNoYWtlIG1lc3NhZ2Vz IGFuZCBzaWducyB0aGVtIHdpdGggaXQncyBwcml2YXRlIGtleSBhbmQgc2VuZHMgdGhlIHJlc3Vs dCB0byB0aGUgc2VydmVyLiBUaGUgc2VydmVyIHRoZW4gdmVyaWZpZXMgdGhlIHNpZ25hdHVyZSB1 c2luZyB0aGUgcHVibGljIGtleSBvZiB0aGUgY2xpZW50IGNlcnRpZmljYXRlLiBJZiB0aGUgc2ln bmF0dXJlIGNhbiBiZSB2ZXJpZmllZCB3aXRoIHRoZSBwdWJsaWMga2V5LCB0aGUgc2VydmVyIGtu b3dzIHRoZSBjbGllbnQgaXMgaW4gcG9zc2Vzc2lvbiBvZiB0aGUgcHJpdmF0ZSBrZXksIGFuZCBp cyB0aGVyZWZvcmUgYSBib25hIGZpZGUgdXNlci5MZXQncyBsb29rIGF0IHRoaXMgaW4gdGhlIGNv bnRleHQgb2Ygb3VyIG9yaWdpbmFsIGF0dGFjazpjbGllbnQgYXR0ZW1wdHMgdG8gY29ubmVjdCB0 byBzZXJ2aWNlYXR0YWNrZXIgc3VjY2Vzc2Z1bGx5IHJlcm91dGVzIHRyYWZmaWMgdG8gYSBob3N0 IGl0IGNvbnRyb2xzbWFsaWNpb3VzIGhvc3QgYWNjZXB0cyBjb25uZWN0aW9uIGZyb20gY2xpZW50 IGFjY2VwdGluZyB0aGUgY2xpZW50J3MgY2VydGlmaWNhdGVtYWxpY2lvdXMgaG9zdCBjb25uZWN0 cyB0byBzZXJ2aWNldGhlIG1hbGljaW91cyBob3N0IHdpbGwgZmFpbCB0byBTU0wgaGFuZHNoYWtl IGJlY2F1c2UgdGhlIGhvc3QgZG9lc27igJl0IGhhdmUgdGhlIHByaXZhdGUga2V5IGZvciB0aGUg Y2xpZW504oCZcyBjZXJ0aWZpY2F0ZS4gVGhlIGF0dGFja2VyIHRoZXJlZm9yZSBjYW5ub3QgY29t cHV0ZSB0aGUgY29ycmVjdCBDZXJ0aWZpY2F0ZVZlcmlmeSBoYW5kc2hha2UgbWVzc2FnZS4gVGhl IENlcnRpZmljYXRlVmVyaWZ5IG1lc3NhZ2UgZnJvbSB0aGUgZmlyc3QgaGFuZHNoYWtlIGNhbm5v dCBiZSB1c2VkIGJlY2F1c2UgdGhlIGhhbmRzaGFrZSBzZXF1ZW5jZXMgZGl2ZXJnZSAoZGlmZmVy ZW50IHNlcnZlciBjZXJ0aWZpY2F0ZXMgcHJlc2VudGVkIGJ5IHRoZSBob3N0KS5JbnRyb2R1Y2lu ZyBUQXV0aFRBdXRoIGlzIENsaWVudCBTU0wgQXV0aGVudGljYXRpb24gKyBVc2VyIFRva2VucyAr IEdyZWF0IFRvb2xpbmcuQ2xpZW50IFNTTCBhdXRoZW50aWNhdGlvbiBpcyBvZnRlbiBvdmVybG9v a2VkIGJlY2F1c2Ugb2YgdGhlIHBvb3IgVVggb2YgdXNpbmcgY2xpZW50IGNlcnRpZmljYXRlcyBp biB0aGUgYnJvd3NlciBhbmQgdGhhdCBnZW5lcmF0aW5nIGNlcnRpZmljYXRlcyBpcyBhIHBhaW5m dWwgbXVsdGlzdGVwIHByb2Nlc3MgaW52b2x2aW5nIGFyY2FuZSBPcGVuU1NMIENMSSBpbmNhbnRh dGlvbnMuIEhvd2V2ZXIgYXMgd2UncmUgdGFsa2luZyBhYm91dCBBUEkgY2xpZW50cyB0aGUgYnJv d3NlciBVWCBwb2ludCBpcyBpcnJlbGV2YW50LiBBcyBmYXIgYXMgY2VydGlmaWNhdGUgZ2VuZXJh dGlvbiBnb2VzLCB3ZSBjYW4gd3JpdGUgYmV0dGVyIHRvb2xzLiBUaGVzZSBkYXlzIGl0J3MgcG9z c2libGUgdG8gZ2VuZXJhdGUgYSBrZXkgcGFpciwgYSBQS0NTIzEwIGNlcnRpZmljYXRlIHJlcXVl c3QsIGFuZCBzaWduIGl0IGFsbCBpbiB0aGUgYnJvd3Nlci4gVGhhbmtzIHRvIFdlYkNyeXB0byB0 aGUgd2hvbGUgcHJvY2VzcyBpcyByZWR1Y2VkIHRvIG9uZSBjbGljay5UaGlzIGlzIGhvdyBUZWxs ZXIgZG9lcyBpdDpBIHByaXZhdGUga2V5IGFuZCBhIFNTTCBjZXJ0aWZpY2F0ZSBzaWduZWQgYnkg VGVsbGVyIGdlbmVyYXRlZCBpbiBvbmUgY2xpY2suQW5kIHRoaXMgaXMgd2hhdCBhIHJlcXVlc3Qg bG9va3MgbGlrZSB3aXRoIGNsaWVudCBjZXJ0aWZpY2F0ZXM6TGV0J3MgcmVjYXAgd2hhdCB3ZSd2 ZSBhY2hpZXZlZCBoZXJlOkNyeXB0b2dyYXBoaWMgcHJvb2Ygb2YgdGhlIGNsaWVudCBpZGVudGl0 eVRoZSBjVVJMYWJpbGl0eSBvZiB0aGUgQVBJIGlzIHByZXNlcnZlZFRoZSBjbGllbnQgZGV2ZWxv cGVyIGhhcyBnZW5lcmF0ZWQgYSBwcml2YXRlIGtleSBrbm93biBvbmx5IHRvIHRoZW0gYW5kIG5v IG9uZSBlbHNlLCBtZWFuaW5nIHRoZSBiYW5rIGNhbiBhY3R1YWxseSBzYXkgInlvdSBkaWQgdGhh dCB0cmFuc2FjdGlvbiIgKG5vbi1yZXB1ZGlhdGlvbilUb2tlbiBzZWN1cml0eU5vdGljZSBpbiB0 aGUgYWJvdmUgZXhhbXBsZS4gVGhlIFRlbGxlciBBUEkgYWNjZXB0cyBjb25uZWN0aW9ucyBmcm9t IGNsaWVudHMgd2l0aG91dCBhIGNsaWVudCBjZXJ0aWZpY2F0ZS4gV2UgZG8gdGhpcyBiZWNhdXNl IHdlIHByb3ZpZGUgZGV2ZWxvcGVycyB3aXRoIHJlYWQtb25seSBwZXJzb25hbCBhY2Nlc3MgdG9r ZW5zIGZvciB0aGVpciBvd24gYWNjb3VudHMgaWYgdGhleSB3YW50IHRvIHF1aWNrbHkgaGFjayBz b21ldGhpbmcgdXAgYW5kIG5vdCBib3RoZXIgd2l0aCBwcm92aXNpb25pbmcgY2VydHMuIE5vdyBu b3RpY2UgaG93IHRoZSBBUEkgZG9lcyBub3QgYWNjZXB0IHRoZSB0b2tlbiBwcmVzZW50ZWQsIGJ1 dCBhY2NlcHRzIGl0IHdoZW4gdXNlZCB3aXRoIHRoZSBjbGllbnQgU1NMIGNlcnRpZmljYXRlLiBU QXV0aCBiZWFyZXIgdG9rZW5zIGFyZSBib3VuZCBvbiB0aGUgc2VydmVyIHNpZGUgdG8gYSBwcml2 YXRlIGtleSB0aHJvdWdoIGFuIGFwcGxpY2F0aW9uLiBUaGlzIG1lYW5zIHRoZXkgYXJlIHVzZWxl c3Mgd2l0aG91dCB0aGUgcHJpdmF0ZSBrZXkgKHdoaWNoIG9ubHkgdGhlIGRldmVsb3BlciBldmVy IGhhcykgYW5kIHRoZXJlZm9yZSBub3Qgc2Vuc2l0aXZlLiBBcyBtYXR0ZXIgb2YgZmFjdCwgaGVy ZSBpcyBvbmUgZm9yIG15IGJhbmsgYWNjb3VudDoKWW91J2xsIG5lZWQgdGhlIHByaXZhdGUga2V5 IGl0J3MgYm91bmQgdG8gZm9yIGl0IHRvIGJlIG9mIGFueSB1c2UsIGFuZCB0aGF0IGhhcyBuZXZl ciBsZWZ0IG15IGxhcHRvcC5UQXV0aCB0b2tlbnMgZG8gbm90IGV4cGlyZSAoYnV0IGNhbiBiZSBy ZXZva2VkKS4gT0F1dGggMi4wIGludHJvZHVjZWQgdGhlIGNvbmNlcHQgb2YgdGltZS1saW1pdGVk IHRva2Vucy4gTGFyZ2UgaW50ZXJuZXQgY29tcGFuaWVzIGZvdW5kIGl0IHVzZWZ1bCBmb3Igc2Nh bGluZyBwdXJwb3NlcyB0byBpc3N1ZSBzZWxmLWVuY29kZWQsIGVuY3J5cHRlZCB0b2tlbnMuIFRo ZSBkcmF3YmFja3MgYXJlIGRldmVsb3BlcnMgaGF2ZSB0byBwYXkgdGhlIGNvbXBsZXhpdHkgY29z dCBvZiByZWZyZXNoaW5nIHRva2VucyBhbmQgbW9zdCBpbXBvcnRhbnRseSB0b2tlbnMgY2Fubm90 IGJlIHJldm9rZWQsIHRoZXkncmUgZ29vZCB1bnRpbCB0aGV5IGV4cGlyZS4gRm9yIGJhbmsgYWNj b3VudCBBUElzIHRoaXMgaXMgYW4gdW5kZXNpcmFibGUgcHJvcGVydHksIGEgdG9rZW4gc2hvdWxk IGJlIHZvaWQgYXMgc29vbiBhcyB0aGUgYWNjb3VudCBvd25lciB3aXNoZXMuIFRBdXRoIGNoZWNr cyB0aGUgdG9rZW4gcmV2b2NhdGlvbiBzdGF0dXMgYXQgZWFjaCByZXF1ZXN0LkdpdmVuIHRoYXQg d2UgaGF2ZSBubyBuZWVkIGZvciBzZWxmLWVuY29kZWQgdG9rZW5zIGFuZCB0aGF0IHRva2VucyBh cmUgdXNlbGVzcyB0byBhbnlvbmUgd2l0aG91dCB0aGUgcHJpdmF0ZSBrZXksIHdlIGNhbiBjb25z aWRlciB0aGVtIHB1YmxpYyBhbmQgZGlyZWN0bHkgcmV0dXJuIHRoZW0gaW4gdGhlIGNhbGxiYWNr IGZ1cnRoZXIgc2ltcGxpZnlpbmcgdGhpbmdzIGZvciB0aGUgZGV2ZWxvcGVyIGNvbXBhcmVkIHRv IE9BdXRoIHdpdGhvdXQgY29tcHJvbWlzaW5nIHRoZSB1c2VyJ3Mgc2VjdXJpdHkuQm9udXM6IERE T1MgbWl0aWdhdGlvblRBdXRoIGNhbiBoZWxwIG1pdGlnYXRlIGxheWVyIDcgYmFzZWQgRERPUyBh dHRhY2tzIHRvby4gSWYgdGhlIGNsaWVudCBkb2VzIG5vdCBwcmVzZW50IGEgdmFsaWQgY2xpZW50 IGNlcnRpZmljYXRlIHRoZSBzZXJ2ZXIgY2FuIGp1c3QgY2hvb3NlIHRvIGJvdW5jZSB0aGUgY29u bmVjdGlvbi5Db25jbHVzaW9uT0F1dGggMi4wIGlzIHNpbXBseSBub3QgZml0IGZvciB1c2Ugd2l0 aCBzZW5zaXRpdmUgQVBJcyBhbmQgYWxsIHRoZSBwaWVjZXMgbmVlZGVkIHRvIGJ1aWxkIHNvbWV0 aGluZyB0aGF0IGlzIGV4aXN0IHRvZGF5LiBBc2lkZSBmcm9tIHVuYm91bmQgYmVhcmVyIHRva2Vu cywgT0F1dGggaXMgdG9vIG9wZW4tZW5kZWQgYW5kIGNvbXBsaWNhdGVkIHRvIGdldCByaWdodCBm b3IgbW9zdCBkZXZlbG9wZXJzLiBJdCdzIHNvIGJhZCBpdCBldmVuIGhhcyBpdCdzIG93biB0aHJl YXQgbW9kZWwgYXMgYSBzZXBhcmF0ZSBSRkMgdG8gb2ZmZXIgbWl0aWdhdGlvbnMgZm9yIHRoZSBl bmRsZXNzIHByb2JsZW1zIHRoYXQgY2FuIGhhcHBlbi5UQXV0aCBzdGFuZHMgZm9yIFRydXN0ZWQg QXV0aGVudGljYXRpb24sIGFuZCBpdCBwcm92aWRlcyB0aGUgYmVzdCBzZWN1cml0eSBmb3IgdXNl cnMgd2hpbGUgbWFpbnRhaW5pbmcgdGhlIGhpZ2hlc3QgcG9zc2libGUgcXVhbGl0eSBkZXZlbG9w ZXIgZXhwZXJpZW5jZS4gTGVzcyBjYW4gZ28gd3Jvbmcgd2hlbiBldmVyeXRoaW5nIGlzIHNpbXBs ZXIuIElmIHlvdXIgYmFuayBoYXMgT0F1dGggMi4wIGluIHByb2R1Y3Rpb24geW91IG11c3QgYXNr IHlvdXJzZWxmLCBkbyB0aGV5IHJlYWxseSBrbm93IHdoYXQgdGhleSdyZSBkb2luZz9UQXV0aCBp cyBhdmFpbGFibGUgaW4gcHJvZHVjdGlvbiB0b2RheSBmb3Igb3VyIGV4aXN0aW5nIGJldGEgdXNl cnMgYW5kIHdlJ3ZlIGFscmVhZHkgYmVndW4gdGhlIHdvcmsgdG8gbWFrZSBpdCBhbiBvcGVuIHN0 YW5kYXJkIHdlIGhvcGUgdGhlIGluZHVzdHJ5IGFkb3B0cy4gSWYgeW91J3JlIGF0IGEgYmFuayBh bmQgd2FudCB0byBvZmZlciB5b3VyIGN1c3RvbWVycyB0aGUgc2VjdXJpdHkgdGhleSBkZXNlcnZl IGVtYWlsIG1lIC0gc2cgYXQgdGVsbGVyLmlvU2lnbiB1cCBmb3IgdGhlIGJldGEgd2FpdGluZyBs aXN0IGF0IFRlbGxlci5pby4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KT0F1dGggbWFpbGluZyBsaXN0Ck9BdXRoQGlldGYub3JnCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgK ----_com.samsung.android.email_353449515129040 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkkgcG9zdGVkIGFib3V0IHRo aXMgdGhlIG90aGVyIGRheS4gV2hhdCBJIGRvbid0IHVuZGVyc3RhbmQgaXMgdGhhdCBoZSdzIHNh eWluZyBwZW9wbGUgZGlzYWJsZSBUTFMgY2hlY2tzIHNvIGhlJ3MgZ29pbmcgdG8gc29sdmUgaXQg d2l0aCBtdXR1YWwgVExTPyZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBuZWVkIHRv IGVtYWlsIHRoaXMgZ3V5IGFuZCBsZWFybiBtb3JlIGFib3V0IHdoYXQgaGUncyBkb2luZy4mbmJz cDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1cmUiPjxtZXRh IGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVU Ri04Ij48ZGl2IHN0eWxlPSJmb250LXNpemU6ODUlO2NvbG9yOiM1NzU3NTciPi0tSnVzdGluPC9k aXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3Ij48YnI+PC9kaXY+PGRp diBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3Ij4mbmJzcDs8aT5TZW50IGZyb20g bXkgcGhvbmU8L2k+PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1z aXplOjEwMCU7Y29sb3I6IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0t LS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBCcm9jayBBbGxl biAmbHQ7YnJvY2thbGxlbkBnbWFpbC5jb20mZ3Q7IDwvZGl2PjxkaXY+RGF0ZTogNS8xMC8xNiAg Njo0NCBQTSAgKEdNVC0wNjowMCkgPC9kaXY+PGRpdj5UbzogRGljayBIYXJkdCAmbHQ7ZGljay5o YXJkdEBnbWFpbC5jb20mZ3Q7LCBPYXV0aCBXcmFwIFdnICZsdDtPQXV0aEBpZXRmLm9yZyZndDsg PC9kaXY+PGRpdj5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBUQXV0aCA8L2Rpdj48ZGl2Pjxicj48 L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PGRpdj5Eb2VzbuKAmXQgdGhlIHJlY2VudCBQb1Agd29yayBh ZGRyZXNzIG1hbnkgb2YgdGhlc2UgY29uY2VybnM/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5B bHNvLCBhcyBmb3IgZGV2ZWxvcGVycyBkaXNhYmxpbmcgU1NMIOKAlCBkb2VzIGFueW9uZSBzdGls bCBkbyB0aGlzIGFuZCB0aGluayBpdOKAmXMgc2FmZT8gT3IgYXJlIHBlb3BsZSBqdXN0IGJlaW5n IGxhenk/IE9yIGFyZSB0aGVyZSBjZXJ0YWluIGNvbnRleHRzIHRoYXQgSeKAmW0gdW5hd2FyZSBv ZiB3aGVyZSB0aGlzIGlzIHZhbGlkPzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGRpdiBpZD0i TUFDX09VVExPT0tfU0lHTkFUVVJFIj48ZGl2Pi1Ccm9jazwvZGl2PjxkaXY+PGJyPjwvZGl2Pjwv ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxzcGFuIGlkPSJPTEtfU1JDX0JP RFlfU0VDVElPTiI+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEy cHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBu b25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJ TkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0 IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij48c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiBPQXV0aCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2su aGFyZHRAZ21haWwuY29tIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+IFR1ZXNkYXksIE1heSAxMCwgMjAx NiBhdCA3OjI0IFBNPGJyPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFu PiBPYXV0aCBXcmFwIFdnICZsdDs8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRo QGlldGYub3JnPC9hPiZndDs8YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1Ympl Y3Q6IDwvc3Bhbj4gW09BVVRILVdHXSBUQXV0aDxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48ZGl2IGRpcj0ibHRyIj5E b2VzIGFueW9uZSB0aGluayB0aGVyZSBhcmUgdXNlZnVsIGxlc3NvbnMgaGVyZT88ZGl2Pjxicj48 L2Rpdj48ZGl2PkRvZXMgYWRkaW5nIFRPS0JJTkQgcmVzb2x2ZSB0aGUgaXNzdWVzPzxicj48ZGl2 Pjxicj48L2Rpdj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vYmxvZy50ZWxsZXIuaW8vMjAxNi8wNC8y Ni90YXV0aC5odG1sIj5odHRwczovL2Jsb2cudGVsbGVyLmlvLzIwMTYvMDQvMjYvdGF1dGguaHRt bDwvYT48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48cCBjbGFzcz0iIj48c3BhbiBjbGFz cz0iIj48YSBocmVmPSJodHRwczovL2Jsb2cudGVsbGVyLmlvLyI+PGI+VGVsbGVyPC9iPjwvYT48 L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHA6Ly90ZWxs ZXIuaW8vI3dhaXRsaXN0Ij5Kb2luIHdhaXRpbmcgbGlzdDxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48 L2E+PC9zcGFuPjwvcD48cCBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj5JbnRyb2R1Y2luZyBUQXV0 aDogV2h5IE9BdXRoIDIuMCBpcyBiYWQgZm9yIGJhbmtpbmcgQVBJcyBhbmQgaG93IHdlJ3JlIGZp eGluZyBpdDwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+VGhpcyB3ZWVrIHdl IHJlbGVhc2VkIG91ciBhdXRob3Jpc2F0aW9uIGZsb3cgbWFraW5nIGl0IHBvc3NpYmxlIGZvciB5 b3UgdG8gZ28gZnJvbSBidWlsZGluZyBhcHBzIHRoYXQgdGFsayB0byB5b3VyIGJhbmsgYWNjb3Vu dCwgdG8gYnVpbGRpbmcgYXBwcyB0aGF0IGNhbiB0YWxrIHRvIGFueSBiYW5rIGFjY291bnQuIFRo aXMgaXMgaHVnZS4gQ2hlY2sgb3V0IHRoaXMgU01TIGJvdCAoaG93IG9uIHRyZW5kKSBJIGhhY2tl ZCB1cCB5ZXN0ZXJkYXkgbW9ybmluZy4gKGFuZCA8YSBocmVmPSJodHRwczovL3RlbGxlci5pby8i PjxzcGFuIGNsYXNzPSIiPmRvbid0IGZvcmdldCB0byBqb2luIHRoZSBiZXRhIHdhaXQgbGlzdDwv c3Bhbj48L2E+KS48L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48 YnI+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPkdldHRpbmcgdG8gdGhpcyBwb2ludCB0 b29rIGxvbmdlciB0aGFuIHdlIGV4cGVjdGVkLiBUaGlzIGlzIGJlY2F1c2UgdGhlcmUgd2Fzbid0 IGEgZ29vZCBzdG9yeSBmb3IgZGVsZWdhdGluZyBhdXRob3Jpc2F0aW9uIGZvciBzZW5zaXRpdmUg QVBJcy4gVGhlIG1vc3QgcG9wdWxhciBjaG9pY2UsIDxhIGhyZWY9Imh0dHA6Ly9vYXV0aC5uZXQv MiI+PHNwYW4gY2xhc3M9IiI+T0F1dGggMi4wPC9zcGFuPjwvYT4gLSB3aGljaCBoYXMgYmVlbiBj aG9zZW4gYnkgdGhlIDxhIGhyZWY9Imh0dHA6Ly90aGVvZGkub3JnL29wZW4tYmFua2luZy1zdGFu ZGFyZCI+PHNwYW4gY2xhc3M9IiI+T3BlbiBCYW5raW5nIFdvcmtpbmcgR3JvdXA8L3NwYW4+PC9h PiwgPGEgaHJlZj0iaHR0cHM6Ly93d3cuYmJ2YWFwaW1hcmtldC5jb20vd2ViL2FwaV9tYXJrZXQv YmJ2YS9iYnZhLWNvbm5lY3QvZG9jdW1lbnRhdGlvbiMzLWxlZ2dlZC1mbG93Ij48c3BhbiBjbGFz cz0iIj5CQlZBPC9zcGFuPjwvYT4sIDxhIGhyZWY9Imh0dHBzOi8vYmx1ZWJhbmsucG9ydGFsLmF6 dXJlLWFwaS5uZXQvZ2V0dGluZy1zdGFydGVkIj48c3BhbiBjbGFzcz0iIj5SQlM8L3NwYW4+PC9h PiwgYW5kIDxhIGhyZWY9Imh0dHBzOi8vZ2V0bW9uZG8uY28udWsvZG9jcy8jYXV0aGVudGljYXRp b24iPjxzcGFuIGNsYXNzPSIiPk1vbmRvPC9zcGFuPjwvYT4gLSBpcyBhbHNvIGFtb25nc3QgdGhl IHdvcnN0IGZyb20gYSBzZWN1cml0eSBwZXJzcGVjdGl2ZS48L3NwYW4+PC9wPjxwIGNsYXNzPSIi PjxzcGFuIGNsYXNzPSIiPlRlbGxlciBwcm92aWRlcyBhbiBBUEkgZm9yIHlvdXIgYmFuayBhY2Nv dW50LiBUaGUgRVUgaXMgZm9yY2luZyBhbGwgRXVyb3BlYW4gYmFua3MgdG8gZXhwb3NlIGFjY291 bnQgQVBJcyB3aXRoIDxhIGhyZWY9Imh0dHA6Ly9lYy5ldXJvcGEuZXUvZmluYW5jZS9wYXltZW50 cy9mcmFtZXdvcmsvaW5kZXhfZW4uaHRtIj48c3BhbiBjbGFzcz0iIj5QU0QgSUk8L3NwYW4+PC9h PiBieSBlbmQgb2YgMjAxNy4gVGhlc2UgYmFua3MgYXJlIGRpc2NvbmNlcnRpbmdseSBjb252ZXJn aW5nIGFyb3VuZCBPQXV0aCAyLjAqIHdpdGhvdXQgZnVsbHkgY29uc2lkZXJpbmcgdGhlIGltcGFj dCBvbiB0aGVpciBjdXN0b21lcnMsIGFuZCBzb21ldGhpbmcgbmVlZHMgdG8gYmUgZG9uZSBiZWZv cmUgaXQncyB0b28gbGF0ZS48L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPiog T25lIG5vdGFibGUgZXhjZXB0aW9uIGlzIHRoZSA8YSBocmVmPSJodHRwOi8vd3d3Lm9wZW5iYW5r cHJvamVjdC5jb20vIj48c3BhbiBjbGFzcz0iIj5PcGVuIEJhbmsgUHJvamVjdDwvc3Bhbj48L2E+ LiBJdCBpcyBzdGlja2luZyB3aXRoIDxhIGhyZWY9Imh0dHA6Ly9vYXV0aC5uZXQvY29yZS8xLjBh LyI+PHNwYW4gY2xhc3M9IiI+T0F1dGggMS4wYTwvc3Bhbj48L2E+IHByZWNpc2VseSBiZWNhdXNl IE9BdXRoIDEuMGEgZG9lc24ndCBzaGFyZSB0aGUgc2FtZSBzZWN1cml0eSBpc3N1ZXMgYXMgT0F1 dGggMi4wLjwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+TWFuLWluLXRoZS1t aWRkbGU8L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPk9uZSBvZiB0aGUgYmln Z2VzdCBwcm9ibGVtcyB3aXRoIE9BdXRoIDIuMCBpcyB0aGF0IGl0IGRlbGVnYXRlcyBhbGwgc2Vj dXJpdHkgY29uY2VybnMgdG8gVExTIGJ1dCBvbmx5IHRoZSBjbGllbnQgYXV0aGVudGljYXRlcyB0 aGUgc2VydmVyICh2aWEgaXQncyBTU0wgY2VydGlmaWNhdGUpLCB0aGUgc2VydmVyIGRvZXMgbm90 IGF1dGhlbnRpY2F0ZSB0aGUgY2xpZW50LiBUaGlzIG1lYW5zIHRoZSBzZXJ2ZXIgaGFzIG5vIHdh eSBvZiBrbm93aW5nIHdobyBpcyBhY3R1YWxseSBzZW5kaW5nIHRoZSByZXF1ZXN0LiBJcyBpdCBh IGJvbmEgZmlkZSB1c2VyLCBvciBpcyBhbiBhdHRhY2tlciB0YW1wZXJpbmcgd2l0aCB0aGUgcmVx dWVzdD8gV2hlbiBhbiBhdHRhY2tlciBpcyBhYmxlIHRvIGluc2ludWF0ZSB0aGVtc2VsdmVzIGJl dHdlZW4gYSBsZWdpdGltYXRlIHVzZXIgYW5kIHRoZSBzZXJ2ZXIsIGl0J3MgY2FsbGVkIGEgbWFu LWluLXRoZS1taWRkbGUgKE1JVE0pIGF0dGFjay4gSXQgbG9va3MgbGlrZSB0aGlzOjwvc3Bhbj48 L3A+PHVsIGNsYXNzPSIiPjxsaSBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj48L3NwYW4+PHNwYW4g Y2xhc3M9IiI+Y2xpZW50IGF0dGVtcHRzIHRvIGNvbm5lY3QgdG8gc2VydmljZTwvc3Bhbj48L2xp PjxsaSBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj5hdHRhY2tlciBzdWNjZXNzZnVsbHkgcmVyb3V0 ZXMgdHJhZmZpYyB0byBhIGhvc3QgaXQgY29udHJvbHM8L3NwYW4+PC9saT48bGkgY2xhc3M9IiI+ PHNwYW4gY2xhc3M9IiI+bWFsaWNpb3VzIGhvc3QgYWNjZXB0cyBjb25uZWN0aW9uIGZyb20gY2xp ZW50PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPm1hbGljaW91cyBob3N0 IGNvbm5lY3RzIHRvIHNlcnZpY2U8L3NwYW4+PC9saT48bGkgY2xhc3M9IiI+PHNwYW4gY2xhc3M9 IiI+c2VydmljZSBhY2NlcHRzIGNvbm5lY3Rpb24gZnJvbSBtYWxpY2lvdXMgaG9zdDwvc3Bhbj48 L2xpPjxsaSBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj5jbGllbnQgY29tbXVuaWNhdGVzIHdpdGgg c2VydmljZSBwcm94aWVkIHRocm91Z2ggbWFsaWNpb3VzIGhvc3QsIHdoaWNoIGNhbiBzZWUgYW5k IHRhbXBlciB3aXRoIGFueSBkYXRhIHNlbnQgb3IgcmVjZWl2ZWQ8L3NwYW4+PC9saT48L3VsPjxw IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPllvdSdyZSBwcm9iYWJseSB0aGlua2luZyAiaGFuZyBv biwgaXNuJ3QgdGhpcyB0aGUgcG9pbnQgb2YgU1NMPyIgWWVzIGl0IGlzLCBidXQgdGhlcmUgYXJl IGEgbnVtYmVyIG9mIHdheXMgdG8gcHJlc2VudCBhIGJvZ3VzIGNlcnRpZmljYXRlIGFuZCBhIGNs aWVudCBhY2NlcHQgaXQuIFRoZSBtb3N0IHJlYWxpc3RpYyB0aHJlYXQgaXMgdGhlIGNsaWVudCBk ZXZlbG9wZXIgbm90IHByb3Blcmx5IHZlcmlmeWluZyB0aGUgc2VydmVyIGNlcnRpZmljYXRlLCBp LmUuIHdhcyBpdCB1bHRpbWF0ZWx5IHNpZ25lZCBieSBhIHRydXN0ZWQgY2VydGlmaWNhdGUgYXV0 aG9yaXR5Pzwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGEgaHJlZj0iaHR0 cHM6Ly90d2l0dGVyLmNvbS90cG9wZSI+PGI+Rm9sbG93PC9iPjxzcGFuIGNsYXNzPSIiPjxiPjwv Yj48L3NwYW4+PC9hPjwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGEgaHJl Zj0iaHR0cHM6Ly90d2l0dGVyLmNvbS90cG9wZSI+PC9hPjwvc3Bhbj48YnI+PC9wPjxwIGNsYXNz PSIiPjxzcGFuIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vdHBvcGUiPjxi PlRpbSBQb3BlPC9iPjxzcGFuIGNsYXNzPSIiPiA8L3NwYW4+PHNwYW4gY2xhc3M9IiI+4oCOQHRw b3BlPC9zcGFuPjwvYT48L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPlB1bGwg cmVxdWVzdHMgdG8gZGlzYWJsZSBTU0wgY2VydGlmaWNhdGUgdmVyaWZpY2F0aW9uOiBtb3JlIGNv bW1vbiB0aGFuIHlvdSB3b3VsZCB0aGluay48L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNs YXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vdHBvcGUvc3RhdHVzLzMwMTA5NDM1 MjQzNDg5MjgwMCI+MjoyNCBQTSAtIDExIEZlYiAyMDEzPHNwYW4gY2xhc3M9IiI+PC9zcGFuPjwv YT48L3NwYW4+PC9wPjx1bCBjbGFzcz0iIj48bGkgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PGEg aHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9pbnRlbnQvcmV0d2VldD90d2VldF9pZD0zMDEwOTQz NTI0MzQ4OTI4MDAiPjxzcGFuIGNsYXNzPSIiPjU8L3NwYW4+PHNwYW4gY2xhc3M9IiI+IDUgUmV0 d2VldHM8YnI+PC9zcGFuPjwvYT48YSBocmVmPSJodHRwczovL3R3aXR0ZXIuY29tL2ludGVudC9s aWtlP3R3ZWV0X2lkPTMwMTA5NDM1MjQzNDg5MjgwMCI+PHNwYW4gY2xhc3M9IiI+NTwvc3Bhbj48 c3BhbiBjbGFzcz0iIj4gNSBsaWtlczwvc3Bhbj48L2E+PC9zcGFuPjwvbGk+PC91bD48cCBjbGFz cz0iIj48c3BhbiBjbGFzcz0iIj5VbmZvcnR1bmF0ZWx5IGEgPGEgaHJlZj0iaHR0cDovL3N0YWNr b3ZlcmZsb3cuY29tL2EvNzMzMjk4My8yMjMyMTMiPjxzcGFuIGNsYXNzPSIiPmxhcmdlPC9zcGFu PjwvYT4gPGEgaHJlZj0iaHR0cDovL3N0YWNrb3ZlcmZsb3cuY29tL2EvMTYyOTg5OTkvMjIzMjEz Ij48c3BhbiBjbGFzcz0iIj5udW1iZXI8L3NwYW4+PC9hPiBvZiA8YSBocmVmPSJodHRwOi8vc3Rh Y2tvdmVyZmxvdy5jb20vYS8zNjE1NDUyMS8yMjMyMTMiPjxzcGFuIGNsYXNzPSIiPmRldmVsb3Bl cnM8L3NwYW4+PC9hPiB0aGluayB0aGF0IGRpc2FibGluZyBTU0wgcGVlciB2ZXJpZmljYXRpb24g aXMgdGhlIGNvcnJlY3QgZml4IHRvIGEgU1NMIHBhdGggdmFsaWRhdGlvbiBlcnJvci4gVGhlcmUg YXJlIG1hbnkgbW9yZSB0aGF0IHdpbGwgb2ZmZXIgdGhlIHNhbWUgYWR2aWNlIHdpdGggdGhlIDxh IGhyZWY9Imh0dHA6Ly9zdGFja292ZXJmbG93LmNvbS9hLzEyMjkzODk4LzIyMzIxMyI+PHNwYW4g Y2xhc3M9IiI+Y2F2ZWF0IHRoYXQgaXQgaW50cm9kdWNlcyBhIHNlY3VyaXR5IGlzc3VlPC9zcGFu PjwvYT4gdGhhdCAmbHQ7IDEwMCUgb2YgcmVhZGVycyB3aWxsIGNvbnNpZGVyLiBBcyBhbiBBUEkg cHJvdmlkZXIgd2l0aCBhIGR1dHkgb2YgY2FyZSB0byBvdXIgdXNlcnMgd2UgY2FuJ3Qgc2ltcGx5 IGhvcGUgZGV2ZWxvcGVycyBvbiBvdXIgcGxhdGZvcm0gZG9uJ3QgZG8gdGhpcy48L3NwYW4+PC9w PjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPkJlYXJlciB0b2tlbnM8L3NwYW4+PC9wPjxwIGNs YXNzPSIiPjxzcGFuIGNsYXNzPSIiPk9uY2UgYSB1c2VyIGF1dGhvcmlzZXMgYSBjbGllbnQgYXBw bGljYXRpb24gdG8gYWNjZXNzIGl0cyBhY2NvdW50LCB0aGUgYXBwbGljYXRpb24gb2J0YWlucyBh IGJlYXJlciB0b2tlbiBmcm9tIHRoZSBhdXRob3Jpc2F0aW9uIHNlcnZlci4gQXMgdGhlIG5hbWUg c3VnZ2VzdHMgaWYgeW91IGhhdmUgcG9zc2Vzc2lvbiBvZiB0aGUgYmVhcmVyIHRva2VuIHRoZW4g eW91IGFyZSBlc3NlbnRpYWxseSB0aGUgdXNlci4gVGhlcmUgaXMgbm8gY3J5cHRvZ3JhcGhpYyBw cm9vZiB0aGF0IHRoZSByZXF1ZXN0aW5nIGNsaWVudCBpcyB0aGUgaW50ZW5kZWQgZGV2ZWxvcGVy IGFuZCBub3QgYW4gYXR0YWNrZXIuIElmIGFuIGF0dGFja2VyIGlzIGFibGUgdG8gc3VjY2Vzc2Z1 bGx5IE1JVE0gYSBjbGllbnQgaXQgY291bGQgaGF2ZSBjYXRhc3Ryb3BoaWMgaW1wbGljYXRpb25z IGZvciB0aGUgdXNlciwgZS5nLiBhbiBlbXB0eSBiYW5rIGFjY291bnQsIGxvYW5zIG9wZW5lZCBp biB0aGVpciBuYW1lLCBldGMuIE9BdXRoIDIuMCBpcyBzaW1wbHkgYSBzZWN1cml0eSBjYXIgY3Jh c2ggZnJvbSBhIGJhbmsncyBwZXJzcGVjdGl2ZS4gVGhleSBoYXZlIG5vIHdheSB0byBwcm92ZSB0 aGF0IGFuIEFQSSB0cmFuc2FjdGlvbiBpcyBib25hIGZpZGUsIGV4cG9zaW5nIHRoZW0gdG8gdW5s aW1pdGVkIGxpYWJpbGl0eS48L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPkZv ciBtb3JlIGluZm9ybWF0aW9uIG9uIE9BdXRoIDIuMCBzaG9ydGNvbWluZ3Mgc2VlIDxhIGhyZWY9 Imh0dHBzOi8vaHVlbml2ZXJzZS5jb20vMjAxMC8wOS8yOS9vYXV0aC1iZWFyZXItdG9rZW5zLWFy ZS1hLXRlcnJpYmxlLWlkZWEvIj48c3BhbiBjbGFzcz0iIj5PQXV0aCBCZWFyZXIgVG9rZW5zIGFy ZSBhIFRlcnJpYmxlIElkZWE8L3NwYW4+PC9hPiBhbmQgPGEgaHJlZj0iaHR0cHM6Ly9odWVuaXZl cnNlLmNvbS8yMDEyLzA3LzI2L29hdXRoLTItMC1hbmQtdGhlLXJvYWQtdG8taGVsbC8iPjxzcGFu IGNsYXNzPSIiPk9BdXRoIDIuMCBhbmQgdGhlIFJvYWQgdG8gSGVsbDwvc3Bhbj48L2E+IGJ5IDxh IGhyZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vZXJhbmhhbW1lciI+PHNwYW4gY2xhc3M9IiI+RXJh biBIYW1tZXI8L3NwYW4+PC9hPiB0aGUgb3JpZ2luYWwgcHJpbWFyeSBhdXRob3Igb2YgT0F1dGgg Mi4wIHdobyBmb3JtYWxseSByZW1vdmVkIGhpcyBuYW1lIGZyb20gdGhlIHN0YW5kYXJkLCBjYWxs aW5nIGl0ICJ0aGUgYmlnZ2VzdCBwcm9mZXNzaW9uYWwgZGlzYXBwb2ludG1lbnQgb2YgW2hpc10g Y2FyZWVyLiI8L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPkZpbmRpbmcgc29t ZXRoaW5nIGJldHRlcjwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+U2l0dGlu ZyBkb3duIHRvIGRlc2lnbiB0aGUgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtIEkgaGFkIHR3byBo aWdoLWxldmVsIGdvYWxzOjwvc3Bhbj48L3A+PHVsIGNsYXNzPSIiPjxsaSBjbGFzcz0iIj48c3Bh biBjbGFzcz0iIj48L3NwYW4+PHNwYW4gY2xhc3M9IiI+YmUgdGhlIG1vc3Qgc2VjdXJlIHNvbHV0 aW9uIGZvciB0aGUgdXNlcjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj5u b3QgdW5uZWNlc3NhcmlseSBpbXBlZGUgZGV2ZWxvcGVyIGV4cGVyaWVuY2UuIERldmVsb3BlcnMg YXJlIHVzZXJzIHRvbyBhbmQgdGhlaXIgbmVlZHMgZGVzZXJ2ZSBlcXVhbCBjb25zaWRlcmF0aW9u Ljwvc3Bhbj48L2xpPjwvdWw+PHAgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+RnJvbSBhIHNlY3Vy aXR5IHBlcnNwZWN0aXZlIEkgd2FudGVkOjwvc3Bhbj48L3A+PHVsIGNsYXNzPSIiPjxsaSBjbGFz cz0iIj48c3BhbiBjbGFzcz0iIj48L3NwYW4+PHNwYW4gY2xhc3M9IiI+Y3J5cHRvZ3JhcGhpYyBw cm9vZiBvZiBjbGllbnQgaWRlbnRpdHk8L3NwYW4+PC9saT48bGkgY2xhc3M9IiI+PHNwYW4gY2xh c3M9IiI+dG8gc3RvcCBNSVRNIGF0dGFja3M8L3NwYW4+PC9saT48bGkgY2xhc3M9IiI+PHNwYW4g Y2xhc3M9IiI+dG8gdW5pbXBlYWNoYWJseSBhdHRyaWJ1dGUgYSByZXF1ZXN0IHRvIGEgZ2l2ZW4g ZGV2ZWxvcGVyLiBJbiBjcnlwdG9ncmFwaHkgdGhpcyBpcyBrbm93biBhcyA8YSBocmVmPSJodHRw czovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9Ob24tcmVwdWRpYXRpb24iPjxzcGFuIGNsYXNzPSIi Pm5vbi1yZXB1ZGlhdGlvbjwvc3Bhbj48L2E+Ljwvc3Bhbj48L2xpPjwvdWw+PHAgY2xhc3M9IiI+ PHNwYW4gY2xhc3M9IiI+KE4uQi4gTm9uLXJlcHVkaWF0aW9uIGlzIGEgZGUgZmFjdG8gcmVxdWly ZW1lbnQgb2YgUFNEIElJLiBJZiBhIGJhbmsgY2FuJ3QgcHJvdmUgYW4gYWNjb3VudCBvd25lciBh dXRob3Jpc2VkIGEgdHJhbnNhY3Rpb24sIHRoZXkncmUgbGlhYmxlIGZvciBhbnkgbG9zc2VzIGlu Y3VycmVkIGJ5IHRoZSB1c2VyLik8L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIi PlRoZXJlIGFyZSBzb2x1dGlvbnMgdG8gdGhlIGJlYXJlciB0b2tlbiBwcm9ibGVtIGxpa2UgSldU IHRva2VucyAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MjMiPjxz cGFuIGNsYXNzPSIiPlJGQzc1MjM8L3NwYW4+PC9hPikgYnV0IGluIG1vc3QgY2FzZXMgdGhlc2Ug cmVseSBvbiBhIHNoYXJlZCBzZWNyZXQgd2hpY2ggaXMgdXNlZCB0byBjb21wdXRlZCBhIEhNQUMt YmFzZWQgc2lnbmF0dXJlLiBTaGFyZWQgc2VjcmV0cyBtZWFuIG5vIG5vbi1yZXB1ZGlhdGlvbi4g UHVibGljIGtleSBjcnlwdG9ncmFwaHkgY2FuIGJlIHVzZWQgd2l0aCBKV1QgdG9rZW5zIGJ1dCB0 aGV5IGRvbid0IHNvbHZlIHRoZSBwcm9ibGVtIG9mIGhvdyB0aGUgY2xpZW50IHdpbGwgZ2VuZXJh dGUga2V5IHBhaXJzLCBkZW1vbnN0cmF0ZSBwcm9vZiBvZiBwb3NzZXNzaW9uIG9mIHRoZSBwcml2 YXRlIGtleSwgYW5kIGVucm9sIHRoZSBwdWJsaWMga2V5IHdpdGggdGhlIEFQSS4gTW9zdCBpbXBv cnRhbnRseSB1c2luZyBKV1QgdG9rZW5zIG1ha2UgaXQgYmFzaWNhbGx5IGltcG9zc2libGUgZm9y IHlvdSB0byBleHBlcmltZW50IHdpdGggYW4gQVBJIHVzaW5nIGNVUkwuIEEgbWFqb3IgaW1wZWRp bWVudCB0byBkZXZlbG9wZXIgZXhwZXJpZW5jZS48L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFu IGNsYXNzPSIiPkluIGFuIGlkZWFsIHdvcmxkIHdlJ2QgaGF2ZSBjcnlwdG9ncmFwaGljIHByb29m IG9mIHRoZSBjbGllbnQncyBpZGVudGl0eSB3aXRob3V0IGl0IGhhdmluZyB0byBsZWFrIHRocm91 Z2ggdGhlIGFwcGxpY2F0aW9uIGxldmVsIChhbmQgc3RvcCB1cyBjVVJMaW5nIHRoZSBBUEkhKS4g QXMgSSB0aG91Z2h0IGFib3V0IGl0IGl0IGJlY2FtZSB0aGUgY2xlYXIgdGhlIGFuc3dlciB3YXMg aGlkaW5nIGluIHBsYWluIHNpZ2h0OiA8L3NwYW4+PHNwYW4gY2xhc3M9IiI+PGI+U1NMIGNsaWVu dCBjZXJ0aWZpY2F0ZXMuPC9iPjwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+ Q2xpZW50IFNTTCBBdXRoZW50aWNhdGlvbjwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xh c3M9IiI+QSBTU0wgaGFuZHNoYWtlIGludm9sdmluZyBjbGllbnQgY2VydGlmaWNhdGVzIGNvbnRh aW5zIGFuIGV4dHJhIG1lc3NhZ2UgYXQgdGhlIGVuZCBvZiB0aGUgaGFuZHNoYWtlLCB0aGUgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjL3JmYzIyNDYudHh0Ij48c3BhbiBjbGFzcz0i Ij48Yj5DZXJ0aWZpY2F0ZVZlcmlmeTwvYj48L3NwYW4+PC9hPiBtZXNzYWdlLjwvc3Bhbj48L3A+ PHAgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7IENsaWVudCZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2VydmVyPC9zcGFuPjwvcD48cCBjbGFzcz0iIj48c3Bh biBjbGFzcz0iIj48L3NwYW4+PGJyPjwvcD48cCBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj4mbmJz cDsgQ2xpZW50SGVsbG8mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0tLS0tLS0mZ3Q7PC9z cGFuPjwvcD48cCBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTZXJ2ZXJIZWxs bzwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2VydGlm aWNhdGUqPC9zcGFuPjwvcD48cCBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBT ZXJ2ZXJLZXlFeGNoYW5nZSo8L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IENlcnRpZmljYXRlUmVxdWVzdCo8L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFu IGNsYXNzPSIiPiZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7LS0tLS0tLS0mbmJzcDsgJm5ic3A7ICZu YnNwOyBTZXJ2ZXJIZWxsb0RvbmU8L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIi PiZuYnNwOyBDZXJ0aWZpY2F0ZSo8L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIi PiZuYnNwOyBDbGllbnRLZXlFeGNoYW5nZTwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xh c3M9IiI+Jm5ic3A7IENlcnRpZmljYXRlVmVyaWZ5Kjwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNw YW4gY2xhc3M9IiI+Jm5ic3A7IFtDaGFuZ2VDaXBoZXJTcGVjXTwvc3Bhbj48L3A+PHAgY2xhc3M9 IiI+PHNwYW4gY2xhc3M9IiI+Jm5ic3A7IEZpbmlzaGVkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgLS0tLS0tLS0mZ3Q7PC9zcGFuPjwvcD48cCBjbGFzcz0iIj48c3BhbiBjbGFz cz0iIj4mbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgW0NoYW5nZUNpcGhlclNwZWNdPC9zcGFuPjwvcD48cCBjbGFzcz0iIj48c3BhbiBj bGFzcz0iIj4mbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy0tLS0tLS0tICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbmlzaGVkPC9zcGFuPjwvcD48cCBjbGFzcz0iIj48 c3BhbiBjbGFzcz0iIj4mbmJzcDsgQXBwbGljYXRpb24gRGF0YSAmbmJzcDsgJmx0Oy0tLS0tLS0m Z3Q7ICZuYnNwOyAmbmJzcDsgQXBwbGljYXRpb24gRGF0YTwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+ PHNwYW4gY2xhc3M9IiI+PC9zcGFuPjxicj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+ Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpZy4gMSAtIE1lc3NhZ2UgZmxvdyBm b3IgYSBmdWxsIGhhbmRzaGFrZTwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+ VGhlIGNsaWVudCBjb2xsZWN0cyBhbGwgdGhlIGhhbmRzaGFrZSBtZXNzYWdlcyBhbmQgc2lnbnMg dGhlbSB3aXRoIGl0J3MgcHJpdmF0ZSBrZXkgYW5kIHNlbmRzIHRoZSByZXN1bHQgdG8gdGhlIHNl cnZlci4gVGhlIHNlcnZlciB0aGVuIHZlcmlmaWVzIHRoZSBzaWduYXR1cmUgdXNpbmcgdGhlIHB1 YmxpYyBrZXkgb2YgdGhlIGNsaWVudCBjZXJ0aWZpY2F0ZS4gSWYgdGhlIHNpZ25hdHVyZSBjYW4g YmUgdmVyaWZpZWQgd2l0aCB0aGUgcHVibGljIGtleSwgdGhlIHNlcnZlciBrbm93cyB0aGUgY2xp ZW50IGlzIGluIHBvc3Nlc3Npb24gb2YgdGhlIHByaXZhdGUga2V5LCBhbmQgaXMgdGhlcmVmb3Jl IGEgYm9uYSBmaWRlIHVzZXIuPC9zcGFuPjwvcD48cCBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj5M ZXQncyBsb29rIGF0IHRoaXMgaW4gdGhlIGNvbnRleHQgb2Ygb3VyIG9yaWdpbmFsIGF0dGFjazo8 L3NwYW4+PC9wPjx1bCBjbGFzcz0iIj48bGkgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PC9zcGFu PjxzcGFuIGNsYXNzPSIiPmNsaWVudCBhdHRlbXB0cyB0byBjb25uZWN0IHRvIHNlcnZpY2U8L3Nw YW4+PC9saT48bGkgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+YXR0YWNrZXIgc3VjY2Vzc2Z1bGx5 IHJlcm91dGVzIHRyYWZmaWMgdG8gYSBob3N0IGl0IGNvbnRyb2xzPC9zcGFuPjwvbGk+PGxpIGNs YXNzPSIiPjxzcGFuIGNsYXNzPSIiPm1hbGljaW91cyBob3N0IGFjY2VwdHMgY29ubmVjdGlvbiBm cm9tIGNsaWVudCBhY2NlcHRpbmcgdGhlIGNsaWVudCdzIGNlcnRpZmljYXRlPC9zcGFuPjwvbGk+ PGxpIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPm1hbGljaW91cyBob3N0IGNvbm5lY3RzIHRvIHNl cnZpY2U8L3NwYW4+PC9saT48bGkgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+dGhlIG1hbGljaW91 cyBob3N0IHdpbGwgZmFpbCB0byBTU0wgaGFuZHNoYWtlIGJlY2F1c2UgdGhlIGhvc3QgZG9lc27i gJl0IGhhdmUgdGhlIHByaXZhdGUga2V5IGZvciB0aGUgY2xpZW504oCZcyBjZXJ0aWZpY2F0ZS4g VGhlIGF0dGFja2VyIHRoZXJlZm9yZSBjYW5ub3QgY29tcHV0ZSB0aGUgY29ycmVjdCA8L3NwYW4+ PHNwYW4gY2xhc3M9IiI+PGI+Q2VydGlmaWNhdGVWZXJpZnk8L2I+PC9zcGFuPjxzcGFuIGNsYXNz PSIiPiBoYW5kc2hha2UgbWVzc2FnZS4gVGhlIDwvc3Bhbj48c3BhbiBjbGFzcz0iIj48Yj5DZXJ0 aWZpY2F0ZVZlcmlmeTwvYj48L3NwYW4+PHNwYW4gY2xhc3M9IiI+IG1lc3NhZ2UgZnJvbSB0aGUg Zmlyc3QgaGFuZHNoYWtlIGNhbm5vdCBiZSB1c2VkIGJlY2F1c2UgdGhlIGhhbmRzaGFrZSBzZXF1 ZW5jZXMgZGl2ZXJnZSAoZGlmZmVyZW50IHNlcnZlciBjZXJ0aWZpY2F0ZXMgcHJlc2VudGVkIGJ5 IHRoZSBob3N0KS48L3NwYW4+PC9saT48L3VsPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPklu dHJvZHVjaW5nIFRBdXRoPC9zcGFuPjwvcD48cCBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj5UQXV0 aCBpcyBDbGllbnQgU1NMIEF1dGhlbnRpY2F0aW9uICsgVXNlciBUb2tlbnMgKyBHcmVhdCBUb29s aW5nLjwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+Q2xpZW50IFNTTCBhdXRo ZW50aWNhdGlvbiBpcyBvZnRlbiBvdmVybG9va2VkIGJlY2F1c2Ugb2YgdGhlIHBvb3IgVVggb2Yg dXNpbmcgY2xpZW50IGNlcnRpZmljYXRlcyBpbiB0aGUgYnJvd3NlciBhbmQgdGhhdCBnZW5lcmF0 aW5nIGNlcnRpZmljYXRlcyBpcyBhIHBhaW5mdWwgbXVsdGlzdGVwIHByb2Nlc3MgaW52b2x2aW5n IGFyY2FuZSBPcGVuU1NMIENMSSBpbmNhbnRhdGlvbnMuIEhvd2V2ZXIgYXMgd2UncmUgdGFsa2lu ZyBhYm91dCBBUEkgY2xpZW50cyB0aGUgYnJvd3NlciBVWCBwb2ludCBpcyBpcnJlbGV2YW50LiBB cyBmYXIgYXMgY2VydGlmaWNhdGUgZ2VuZXJhdGlvbiBnb2VzLCB3ZSBjYW4gd3JpdGUgYmV0dGVy IHRvb2xzLiBUaGVzZSBkYXlzIGl0J3MgcG9zc2libGUgdG8gZ2VuZXJhdGUgYSBrZXkgcGFpciwg YSBQS0NTIzEwIGNlcnRpZmljYXRlIHJlcXVlc3QsIGFuZCBzaWduIGl0IGFsbCBpbiB0aGUgYnJv d3Nlci4gVGhhbmtzIHRvIDxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3JnL1RSL1dlYkNyeXB0b0FQ SS8iPjxzcGFuIGNsYXNzPSIiPldlYkNyeXB0bzwvc3Bhbj48L2E+IHRoZSB3aG9sZSBwcm9jZXNz IGlzIHJlZHVjZWQgdG8gb25lIGNsaWNrLjwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xh c3M9IiI+VGhpcyBpcyBob3cgVGVsbGVyIGRvZXMgaXQ6PC9zcGFuPjwvcD48cCBjbGFzcz0iIj48 c3BhbiBjbGFzcz0iIj5BIHByaXZhdGUga2V5IGFuZCBhIFNTTCBjZXJ0aWZpY2F0ZSBzaWduZWQg YnkgVGVsbGVyIGdlbmVyYXRlZCBpbiBvbmUgY2xpY2suPC9zcGFuPjwvcD48cCBjbGFzcz0iIj48 c3BhbiBjbGFzcz0iIj5BbmQgdGhpcyBpcyB3aGF0IGEgcmVxdWVzdCBsb29rcyBsaWtlIHdpdGgg Y2xpZW50IGNlcnRpZmljYXRlczo8L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIi PkxldCdzIHJlY2FwIHdoYXQgd2UndmUgYWNoaWV2ZWQgaGVyZTo8L3NwYW4+PC9wPjx1bCBjbGFz cz0iIj48bGkgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+PC9zcGFuPjxzcGFuIGNsYXNzPSIiPkNy eXB0b2dyYXBoaWMgcHJvb2Ygb2YgdGhlIGNsaWVudCBpZGVudGl0eTwvc3Bhbj48L2xpPjxsaSBj bGFzcz0iIj48c3BhbiBjbGFzcz0iIj5UaGUgY1VSTGFiaWxpdHkgb2YgdGhlIEFQSSBpcyBwcmVz ZXJ2ZWQ8L3NwYW4+PC9saT48bGkgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+VGhlIGNsaWVudCBk ZXZlbG9wZXIgaGFzIGdlbmVyYXRlZCBhIHByaXZhdGUga2V5IGtub3duIG9ubHkgdG8gdGhlbSBh bmQgbm8gb25lIGVsc2UsIG1lYW5pbmcgdGhlIGJhbmsgY2FuIGFjdHVhbGx5IHNheSAieW91IGRp ZCB0aGF0IHRyYW5zYWN0aW9uIiAobm9uLXJlcHVkaWF0aW9uKTwvc3Bhbj48L2xpPjwvdWw+PHAg Y2xhc3M9IiI+PHNwYW4gY2xhc3M9IiI+VG9rZW4gc2VjdXJpdHk8L3NwYW4+PC9wPjxwIGNsYXNz PSIiPjxzcGFuIGNsYXNzPSIiPk5vdGljZSBpbiB0aGUgYWJvdmUgZXhhbXBsZS4gVGhlIFRlbGxl ciBBUEkgYWNjZXB0cyBjb25uZWN0aW9ucyBmcm9tIGNsaWVudHMgd2l0aG91dCBhIGNsaWVudCBj ZXJ0aWZpY2F0ZS4gV2UgZG8gdGhpcyBiZWNhdXNlIHdlIHByb3ZpZGUgZGV2ZWxvcGVycyB3aXRo IHJlYWQtb25seSBwZXJzb25hbCBhY2Nlc3MgdG9rZW5zIGZvciB0aGVpciBvd24gYWNjb3VudHMg aWYgdGhleSB3YW50IHRvIHF1aWNrbHkgaGFjayBzb21ldGhpbmcgdXAgYW5kIG5vdCBib3RoZXIg d2l0aCBwcm92aXNpb25pbmcgY2VydHMuIE5vdyBub3RpY2UgaG93IHRoZSBBUEkgZG9lcyBub3Qg YWNjZXB0IHRoZSB0b2tlbiBwcmVzZW50ZWQsIGJ1dCBhY2NlcHRzIGl0IHdoZW4gdXNlZCB3aXRo IHRoZSBjbGllbnQgU1NMIGNlcnRpZmljYXRlLiBUQXV0aCBiZWFyZXIgdG9rZW5zIGFyZSBib3Vu ZCBvbiB0aGUgc2VydmVyIHNpZGUgdG8gYSBwcml2YXRlIGtleSB0aHJvdWdoIGFuIGFwcGxpY2F0 aW9uLiBUaGlzIG1lYW5zIHRoZXkgYXJlIHVzZWxlc3Mgd2l0aG91dCB0aGUgcHJpdmF0ZSBrZXkg KHdoaWNoIG9ubHkgdGhlIGRldmVsb3BlciBldmVyIGhhcykgYW5kIHRoZXJlZm9yZSBub3Qgc2Vu c2l0aXZlLiBBcyBtYXR0ZXIgb2YgZmFjdCwgaGVyZSBpcyBvbmUgZm9yIG15IGJhbmsgYWNjb3Vu dDo8L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPjwvc3Bhbj48YnI+PC9wPjxw IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPllvdSdsbCBuZWVkIHRoZSBwcml2YXRlIGtleSBpdCdz IGJvdW5kIHRvIGZvciBpdCB0byBiZSBvZiBhbnkgdXNlLCBhbmQgdGhhdCBoYXMgbmV2ZXIgbGVm dCBteSBsYXB0b3AuPC9zcGFuPjwvcD48cCBjbGFzcz0iIj48c3BhbiBjbGFzcz0iIj5UQXV0aCB0 b2tlbnMgZG8gbm90IGV4cGlyZSAoYnV0IGNhbiBiZSByZXZva2VkKS4gT0F1dGggMi4wIGludHJv ZHVjZWQgdGhlIGNvbmNlcHQgb2YgdGltZS1saW1pdGVkIHRva2Vucy4gTGFyZ2UgaW50ZXJuZXQg Y29tcGFuaWVzIGZvdW5kIGl0IHVzZWZ1bCBmb3Igc2NhbGluZyBwdXJwb3NlcyB0byBpc3N1ZSBz ZWxmLWVuY29kZWQsIGVuY3J5cHRlZCB0b2tlbnMuIFRoZSBkcmF3YmFja3MgYXJlIGRldmVsb3Bl cnMgaGF2ZSB0byBwYXkgdGhlIGNvbXBsZXhpdHkgY29zdCBvZiByZWZyZXNoaW5nIHRva2VucyBh bmQgbW9zdCBpbXBvcnRhbnRseSB0b2tlbnMgY2Fubm90IGJlIHJldm9rZWQsIHRoZXkncmUgZ29v ZCB1bnRpbCB0aGV5IGV4cGlyZS4gRm9yIGJhbmsgYWNjb3VudCBBUElzIHRoaXMgaXMgYW4gdW5k ZXNpcmFibGUgcHJvcGVydHksIGEgdG9rZW4gc2hvdWxkIGJlIHZvaWQgYXMgc29vbiBhcyB0aGUg YWNjb3VudCBvd25lciB3aXNoZXMuIFRBdXRoIGNoZWNrcyB0aGUgdG9rZW4gcmV2b2NhdGlvbiBz dGF0dXMgYXQgZWFjaCByZXF1ZXN0Ljwvc3Bhbj48L3A+PHAgY2xhc3M9IiI+PHNwYW4gY2xhc3M9 IiI+R2l2ZW4gdGhhdCB3ZSBoYXZlIG5vIG5lZWQgZm9yIHNlbGYtZW5jb2RlZCB0b2tlbnMgYW5k IHRoYXQgdG9rZW5zIGFyZSB1c2VsZXNzIHRvIGFueW9uZSB3aXRob3V0IHRoZSBwcml2YXRlIGtl eSwgd2UgY2FuIGNvbnNpZGVyIHRoZW0gcHVibGljIGFuZCBkaXJlY3RseSByZXR1cm4gdGhlbSBp biB0aGUgY2FsbGJhY2sgZnVydGhlciBzaW1wbGlmeWluZyB0aGluZ3MgZm9yIHRoZSBkZXZlbG9w ZXIgY29tcGFyZWQgdG8gT0F1dGggd2l0aG91dCBjb21wcm9taXNpbmcgdGhlIHVzZXIncyBzZWN1 cml0eS48L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPkJvbnVzOiBERE9TIG1p dGlnYXRpb248L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPlRBdXRoIGNhbiBo ZWxwIG1pdGlnYXRlIDxhIGhyZWY9Imh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0FwcGxp Y2F0aW9uX2xheWVyX0REb1NfYXR0YWNrIj48c3BhbiBjbGFzcz0iIj5sYXllciA3IGJhc2VkIERE T1MgYXR0YWNrczwvc3Bhbj48L2E+IHRvby4gSWYgdGhlIGNsaWVudCBkb2VzIG5vdCBwcmVzZW50 IGEgdmFsaWQgY2xpZW50IGNlcnRpZmljYXRlIHRoZSBzZXJ2ZXIgY2FuIGp1c3QgY2hvb3NlIHRv IGJvdW5jZSB0aGUgY29ubmVjdGlvbi48L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNz PSIiPkNvbmNsdXNpb248L3NwYW4+PC9wPjxwIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSIiPk9BdXRo IDIuMCBpcyBzaW1wbHkgbm90IGZpdCBmb3IgdXNlIHdpdGggc2Vuc2l0aXZlIEFQSXMgYW5kIGFs bCB0aGUgcGllY2VzIG5lZWRlZCB0byBidWlsZCBzb21ldGhpbmcgdGhhdCBpcyBleGlzdCB0b2Rh eS4gQXNpZGUgZnJvbSB1bmJvdW5kIGJlYXJlciB0b2tlbnMsIE9BdXRoIGlzIHRvbyBvcGVuLWVu ZGVkIGFuZCBjb21wbGljYXRlZCB0byBnZXQgcmlnaHQgZm9yIG1vc3QgZGV2ZWxvcGVycy4gSXQn cyBzbyBiYWQgaXQgZXZlbiBoYXMgaXQncyBvd24gdGhyZWF0IG1vZGVsIGFzIGEgPGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4MTkiPjxzcGFuIGNsYXNzPSIiPnNlcGFy YXRlIFJGQzwvc3Bhbj48L2E+IHRvIG9mZmVyIG1pdGlnYXRpb25zIGZvciB0aGUgZW5kbGVzcyBw cm9ibGVtcyB0aGF0IGNhbiBoYXBwZW4uPC9zcGFuPjwvcD48cCBjbGFzcz0iIj48c3BhbiBjbGFz cz0iIj48Yj5UQXV0aCBzdGFuZHMgZm9yIFRydXN0ZWQgQXV0aGVudGljYXRpb248L2I+PC9zcGFu PjxzcGFuIGNsYXNzPSIiPiwgYW5kIGl0IHByb3ZpZGVzIHRoZSBiZXN0IHNlY3VyaXR5IGZvciB1 c2VycyB3aGlsZSBtYWludGFpbmluZyB0aGUgaGlnaGVzdCBwb3NzaWJsZSBxdWFsaXR5IGRldmVs b3BlciBleHBlcmllbmNlLiBMZXNzIGNhbiBnbyB3cm9uZyB3aGVuIGV2ZXJ5dGhpbmcgaXMgc2lt cGxlci4gPC9zcGFuPjxzcGFuIGNsYXNzPSIiPjxiPklmIHlvdXIgYmFuayBoYXMgT0F1dGggMi4w IGluIHByb2R1Y3Rpb24geW91IG11c3QgYXNrIHlvdXJzZWxmLCBkbyB0aGV5IHJlYWxseSBrbm93 IHdoYXQgdGhleSdyZSBkb2luZz88L2I+PC9zcGFuPjwvcD48cCBjbGFzcz0iIj48c3BhbiBjbGFz cz0iIj5UQXV0aCBpcyBhdmFpbGFibGUgaW4gcHJvZHVjdGlvbiB0b2RheSBmb3Igb3VyIGV4aXN0 aW5nIGJldGEgdXNlcnMgYW5kIHdlJ3ZlIGFscmVhZHkgYmVndW4gdGhlIHdvcmsgdG8gbWFrZSBp dCBhbiBvcGVuIHN0YW5kYXJkIHdlIGhvcGUgdGhlIGluZHVzdHJ5IGFkb3B0cy4gSWYgeW91J3Jl IGF0IGEgYmFuayBhbmQgd2FudCB0byBvZmZlciB5b3VyIGN1c3RvbWVycyB0aGUgc2VjdXJpdHkg dGhleSBkZXNlcnZlIGVtYWlsIG1lIC0gPC9zcGFuPjxzcGFuIGNsYXNzPSIiPjxiPnNnIGF0IDxh IGhyZWY9Imh0dHA6Ly90ZWxsZXIuaW8iPnRlbGxlci5pbzwvYT48L2I+PC9zcGFuPjwvcD48cCBj bGFzcz0iIj48c3BhbiBjbGFzcz0iIj5TaWduIHVwIGZvciB0aGUgYmV0YSB3YWl0aW5nIGxpc3Qg YXQgPGEgaHJlZj0iaHR0cDovL3RlbGxlci5pby8iPjxzcGFuIGNsYXNzPSIiPlRlbGxlci5pbzwv c3Bhbj48L2E+Ljwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+Cl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk9BdXRoIG1haWxpbmcgbGlzdAo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPgo8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPgo8L3NwYW4+PC9zcGFuPjwvYm9keT48L2h0 bWw+ ----_com.samsung.android.email_353449515129040-- From nobody Tue May 10 17:23:03 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62D612B02B for ; Tue, 10 May 2016 17:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UReaGuptr4P for ; Tue, 10 May 2016 17:22:57 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6FBA12B02A for ; Tue, 10 May 2016 17:22:57 -0700 (PDT) Received: by mail-ig0-x22f.google.com with SMTP id bi2so145736014igb.0 for ; Tue, 10 May 2016 17:22: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:from:date:message-id:subject:to :cc; bh=uCxSB9l5+3UYgSyvwT1BenzOyjO1WWHguEkr3BSqSlc=; b=m2JEnbDNrxkG3s0hIpk3mBE/p3TRk+uSqibVHGAIeX46lqSYJ6sbbxQ+4kycFmy9BL 0gTxGO84BCyD0vLT+CLbyax2xBgZ2Rv6xHvLpJkGkHF8wHZ4W7RA0c9SrQa50l9Heoku WkEJ8i7QysMQ6xLy2CJ0HI0mLi8SpwNs+tQVEC272X6LQsE8BizDA26mNEwI0MPdYNwc ewpI1AyXJpW8FOgHBtOkCu84dXugjJXeJE3dQlkr2DTgzPFLk8B44k43+BvBgX43AKb0 gwsiyqfBnSuLx+FJ6FzTqMjUiiv0SDR+vfpB/GY8IuofUE0Zrq4fM+jpndQ59jlf18RJ FLUA== 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; bh=uCxSB9l5+3UYgSyvwT1BenzOyjO1WWHguEkr3BSqSlc=; b=gIHxVsGMzZys8LBDFjk7hrbRo7A17ndxN9OH67TWQuh6Rf3WLMtRFkduurOzDXRzH3 sIx8KD9jQg5w/WZUf4SlPktCIqc2mESfpDZ8V15KGkyU2jXjU0F9fikkuUznJqQcUmO+ q0PmWzvZICaegVd26qmhzgKiNBeBFDhKwvV/k04yfPvcpyCnJtwuIHBU6LAKNHsOg5KS KlSXPahwpaCQwX1/YTsW0Lz2/cKUJ1t9Oq356AtfB2lrP60CnwP8dAid5uzdC40DcBa6 y0ymujs0ZpddO2EbfsRbiJNlbPetK/hNf8x4XVhZJLpdmdOIO5fqCpO9w5f7jkbSp28y tZAw== X-Gm-Message-State: AOPr4FUsTa43H2StSooeG9Qf3LXv9+vom5TXnHkMTxWUtKlQVpTCUQKEtHl8YzZHBwlsRvT67vFiVtiKHQ0PCw== X-Received: by 10.50.70.197 with SMTP id o5mr822069igu.70.1462926175558; Tue, 10 May 2016 17:22:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.111.20 with HTTP; Tue, 10 May 2016 17:22:36 -0700 (PDT) In-Reply-To: References: From: Dick Hardt Date: Tue, 10 May 2016 17:22:36 -0700 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=bcaec505533906e9590532860b43 Archived-At: Cc: Oauth Wrap Wg Subject: Re: [OAUTH-WG] TAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 00:23:02 -0000 --bcaec505533906e9590532860b43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Let us know what you learn Justin! On Tue, May 10, 2016 at 5:05 PM, Justin Richer wrote: > I posted about this the other day. What I don't understand is that he's > saying people disable TLS checks so he's going to solve it with mutual TL= S? > > I need to email this guy and learn more about what he's doing. > > --Justin > > *Sent from my phone* > > -------- Original message -------- > From: Brock Allen > Date: 5/10/16 6:44 PM (GMT-06:00) > To: Dick Hardt , Oauth Wrap Wg > Subject: Re: [OAUTH-WG] TAuth > > Doesn=E2=80=99t the recent PoP work address many of these concerns? > > Also, as for developers disabling SSL =E2=80=94 does anyone still do this= and > think it=E2=80=99s safe? Or are people just being lazy? Or are there cert= ain > contexts that I=E2=80=99m unaware of where this is valid? > > -Brock > > > From: OAuth on behalf of Dick Hardt < > dick.hardt@gmail.com> > Date: Tuesday, May 10, 2016 at 7:24 PM > To: Oauth Wrap Wg > Subject: [OAUTH-WG] TAuth > > Does anyone think there are useful lessons here? > > Does adding TOKBIND resolve the issues? > > https://blog.teller.io/2016/04/26/tauth.html > > *Teller* > > Join waiting list > > Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're > fixing it > > This week we released our authorisation flow making it possible for you t= o > go from building apps that talk to your bank account, to building apps th= at > can talk to any bank account. This is huge. Check out this SMS bot (how o= n > trend) I hacked up yesterday morning. (and don't forget to join the beta > wait list ). > > > Getting to this point took longer than we expected. This is because there > wasn't a good story for delegating authorisation for sensitive APIs. The > most popular choice, OAuth 2.0 - which has been > chosen by the Open Banking Working Group > , BBVA > , > RBS , and Mondo > - is also amongst the worst > from a security perspective. > > Teller provides an API for your bank account. The EU is forcing all > European banks to expose account APIs with PSD II > by end of > 2017. These banks are disconcertingly converging around OAuth 2.0* withou= t > fully considering the impact on their customers, and something needs to b= e > done before it's too late. > > * One notable exception is the Open Bank Project > . It is sticking with OAuth 1.0a > precisely because OAuth 1.0a doesn't share > the same security issues as OAuth 2.0. > > Man-in-the-middle > > One of the biggest problems with OAuth 2.0 is that it delegates all > security concerns to TLS but only the client authenticates the server (vi= a > it's SSL certificate), the server does not authenticate the client. This > means the server has no way of knowing who is actually sending the reques= t. > Is it a bona fide user, or is an attacker tampering with the request? Whe= n > an attacker is able to insinuate themselves between a legitimate user and > the server, it's called a man-in-the-middle (MITM) attack. It looks like > this: > > - client attempts to connect to service > - attacker successfully reroutes traffic to a host it controls > - malicious host accepts connection from client > - malicious host connects to service > - service accepts connection from malicious host > - client communicates with service proxied through malicious host, > which can see and tamper with any data sent or received > > You're probably thinking "hang on, isn't this the point of SSL?" Yes it > is, but there are a number of ways to present a bogus certificate and a > client accept it. The most realistic threat is the client developer not > properly verifying the server certificate, i.e. was it ultimately signed = by > a trusted certificate authority? > > *Follow* > > > > *Tim Pope* =E2=80=8E@tpope > > Pull requests to disable SSL certificate verification: more common than > you would think. > > 2:24 PM - 11 Feb 2013 > > > - 5 5 Retweets > 5 5 > likes > > Unfortunately a large number > of developers > think that disabling SSL > peer verification is the correct fix to a SSL path validation error. Ther= e > are many more that will offer the same advice with the caveat that it > introduces a security issue > that < 100% of readers will consider. As an API provider with a duty of > care to our users we can't simply hope developers on our platform don't d= o > this. > > Bearer tokens > > Once a user authorises a client application to access its account, the > application obtains a bearer token from the authorisation server. As the > name suggests if you have possession of the bearer token then you are > essentially the user. There is no cryptographic proof that the requesting > client is the intended developer and not an attacker. If an attacker is > able to successfully MITM a client it could have catastrophic implication= s > for the user, e.g. an empty bank account, loans opened in their name, etc= . > OAuth 2.0 is simply a security car crash from a bank's perspective. They > have no way to prove that an API transaction is bona fide, exposing them = to > unlimited liability. > > For more information on OAuth 2.0 shortcomings see OAuth Bearer Tokens > are a Terrible Idea > > and OAuth 2.0 and the Road to Hell > by Er= an > Hammer the original primary author of > OAuth 2.0 who formally removed his name from the standard, calling it "th= e > biggest professional disappointment of [his] career." > > Finding something better > > Sitting down to design the solution to this problem I had two high-level > goals: > > - be the most secure solution for the user > - not unnecessarily impede developer experience. Developers are users > too and their needs deserve equal consideration. > > From a security perspective I wanted: > > - cryptographic proof of client identity > - to stop MITM attacks > - to unimpeachably attribute a request to a given developer. In > cryptography this is known as non-repudiation > . > > (N.B. Non-repudiation is a de facto requirement of PSD II. If a bank can'= t > prove an account owner authorised a transaction, they're liable for any > losses incurred by the user.) > > There are solutions to the bearer token problem like JWT tokens (RFC7523 > ) but in most cases these rely on a > shared secret which is used to computed a HMAC-based signature. Shared > secrets mean no non-repudiation. Public key cryptography can be used with > JWT tokens but they don't solve the problem of how the client will genera= te > key pairs, demonstrate proof of possession of the private key, and enrol > the public key with the API. Most importantly using JWT tokens make it > basically impossible for you to experiment with an API using cURL. A majo= r > impediment to developer experience. > > In an ideal world we'd have cryptographic proof of the client's identity > without it having to leak through the application level (and stop us > cURLing the API!). As I thought about it it became the clear the answer w= as > hiding in plain sight: *SSL client certificates.* > > Client SSL Authentication > > A SSL handshake involving client certificates contains an extra message a= t > the end of the handshake, the *CertificateVerify* > message. > > Client Server > > > ClientHello --------> > > ServerHello > > Certificate* > > ServerKeyExchange* > > CertificateRequest* > > <-------- ServerHelloDone > > Certificate* > > ClientKeyExchange > > CertificateVerify* > > [ChangeCipherSpec] > > Finished --------> > > [ChangeCipherSpec] > > <-------- Finished > > Application Data <-------> Application Data > > > Fig. 1 - Message flow for a full handshake > > The client collects all the handshake messages and signs them with it's > private key and sends the result to the server. The server then verifies > the signature using the public key of the client certificate. If the > signature can be verified with the public key, the server knows the clien= t > is in possession of the private key, and is therefore a bona fide user. > > Let's look at this in the context of our original attack: > > - client attempts to connect to service > - attacker successfully reroutes traffic to a host it controls > - malicious host accepts connection from client accepting the client's > certificate > - malicious host connects to service > - the malicious host will fail to SSL handshake because the host > doesn=E2=80=99t have the private key for the client=E2=80=99s certific= ate. The attacker > therefore cannot compute the correct *CertificateVerify* handshake > message. The *CertificateVerify* message from the first handshake > cannot be used because the handshake sequences diverge (different serv= er > certificates presented by the host). > > Introducing TAuth > > TAuth is Client SSL Authentication + User Tokens + Great Tooling. > > Client SSL authentication is often overlooked because of the poor UX of > using client certificates in the browser and that generating certificates > is a painful multistep process involving arcane OpenSSL CLI incantations. > However as we're talking about API clients the browser UX point is > irrelevant. As far as certificate generation goes, we can write better > tools. These days it's possible to generate a key pair, a PKCS#10 > certificate request, and sign it all in the browser. Thanks to WebCrypto > the whole process is reduced to one > click. > > This is how Teller does it: > > A private key and a SSL certificate signed by Teller generated in one > click. > > And this is what a request looks like with client certificates: > > Let's recap what we've achieved here: > > - Cryptographic proof of the client identity > - The cURLability of the API is preserved > - The client developer has generated a private key known only to them > and no one else, meaning the bank can actually say "you did that > transaction" (non-repudiation) > > Token security > > Notice in the above example. The Teller API accepts connections from > clients without a client certificate. We do this because we provide > developers with read-only personal access tokens for their own accounts i= f > they want to quickly hack something up and not bother with provisioning > certs. Now notice how the API does not accept the token presented, but > accepts it when used with the client SSL certificate. TAuth bearer tokens > are bound on the server side to a private key through an application. Thi= s > means they are useless without the private key (which only the developer > ever has) and therefore not sensitive. As matter of fact, here is one for > my bank account: > > > You'll need the private key it's bound to for it to be of any use, and > that has never left my laptop. > > TAuth tokens do not expire (but can be revoked). OAuth 2.0 introduced the > concept of time-limited tokens. Large internet companies found it useful > for scaling purposes to issue self-encoded, encrypted tokens. The drawbac= ks > are developers have to pay the complexity cost of refreshing tokens and > most importantly tokens cannot be revoked, they're good until they expire= . > For bank account APIs this is an undesirable property, a token should be > void as soon as the account owner wishes. TAuth checks the token revocati= on > status at each request. > > Given that we have no need for self-encoded tokens and that tokens are > useless to anyone without the private key, we can consider them public an= d > directly return them in the callback further simplifying things for the > developer compared to OAuth without compromising the user's security. > > Bonus: DDOS mitigation > > TAuth can help mitigate layer 7 based DDOS attacks > too. If the > client does not present a valid client certificate the server can just > choose to bounce the connection. > > Conclusion > > OAuth 2.0 is simply not fit for use with sensitive APIs and all the piece= s > needed to build something that is exist today. Aside from unbound bearer > tokens, OAuth is too open-ended and complicated to get right for most > developers. It's so bad it even has it's own threat model as a separate > RFC to offer mitigations for the > endless problems that can happen. > > *TAuth stands for Trusted Authentication*, and it provides the best > security for users while maintaining the highest possible quality develop= er > experience. Less can go wrong when everything is simpler. *If your bank > has OAuth 2.0 in production you must ask yourself, do they really know wh= at > they're doing?* > > TAuth is available in production today for our existing beta users and > we've already begun the work to make it an open standard we hope the > industry adopts. If you're at a bank and want to offer your customers the > security they deserve email me - *sg at teller.io * > > Sign up for the beta waiting list at Teller.io . > _______________________________________________ OAuth mailing list > OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth > --=20 Subscribe to the HARDTWARE mail list to learn about projects I am working on! --bcaec505533906e9590532860b43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let us know what you learn Justin!

On Tue, May 10, 2016 at 5:05 PM, Ju= stin Richer <jricher@mit.edu> wrote:
I posted about this the other day. What I don't unde= rstand is that he's saying people disable TLS checks so he's going = to solve it with mutual TLS?=C2=A0

I need to email= this guy and learn more about what he's doing.=C2=A0

--Justin

=C2=A0Sent from my phone

-------- = Original message --------
From: Brock Allen <brockallen@gmail.com>
Date: 5/10/16 6:44 PM (GMT-06:00)
To: Dick Hardt <dick.hardt@gmail.com= >, Oauth Wrap Wg <OAuth@ietf.org>
Subject: Re: [OAUTH-WG] TAuth
=

Doesn=E2=80=99t the recent PoP work add= ress many of these concerns?

Also, as for develope= rs disabling SSL =E2=80=94 does anyone still do this and think it=E2=80=99s= safe? Or are people just being lazy? Or are there certain contexts that I= =E2=80=99m unaware of where this is valid?

-Brock


=
From: O= Auth <oauth-= bounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Tuesday, May 10, 2016 at 7:24 PMTo: Oauth Wrap Wg <OAuth@ietf.org>
Subject: [OAUTH-WG] TAuth
Does anyone think there are useful lessons h= ere?

Does adding TOKBIND resolve the issues?
=

Teller

Join waiting list

Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're= fixing it

This week we released our authorisation flow = making it possible for you to go from building apps that talk to your bank = account, to building apps that can talk to any bank account. This is huge. = Check out this SMS bot (how on trend) I hacked up yesterday morning. (and <= a href=3D"https://teller.io/" target=3D"_blank">don't forget to j= oin the beta wait list).


Getting to this point took longer than we expected. This is because the= re wasn't a good story for delegating authorisation for sensitive APIs.= The most popular choice, = OAuth 2.0 - which has been chosen by the Open Banking Wor= king Group, = BBVA, RBS, and Mondo -= is also amongst the worst from a security perspective.

= Teller provides an API for your bank account. The EU is forcing all Europea= n banks to expose account APIs with PSD II = by end of 2017. These banks are disconcertingly converging around OAuth 2.0= * without fully considering the impact on their customers, and something ne= eds to be done before it's too late.

* One notable e= xception is the Open Bank Project. It is sticking with OAuth 1.0a preci= sely because OAuth 1.0a doesn't share the same security issues as OAuth= 2.0.

Man-in-the-middle

One of the bi= ggest problems with OAuth 2.0 is that it delegates all security concerns to= TLS but only the client authenticates the server (via it's SSL certifi= cate), the server does not authenticate the client. This means the server h= as no way of knowing who is actually sending the request. Is it a bona fide= user, or is an attacker tampering with the request? When an attacker is ab= le to insinuate themselves between a legitimate user and the server, it'= ;s called a man-in-the-middle (MITM) attack. It looks like this:

=
  • client attempts to connect to service
  • attacker successfully reroutes traffic to a host it controls
  • malicious host accepts connection from client
    • =
  • malicious host connects to service
  • service a= ccepts connection from malicious host
  • client communica= tes with service proxied through malicious host, which can see and tamper w= ith any data sent or received

You're probably = thinking "hang on, isn't this the point of SSL?" Yes it is, b= ut there are a number of ways to present a bogus certificate and a client a= ccept it. The most realistic threat is the client developer not properly ve= rifying the server certificate, i.e. was it ultimately signed by a trusted = certificate authority?

Follow

<= span>

Ti= m Pope =E2=80=8E@tpope

Pull requests to disable SSL certificate verification: more common than yo= u would think.

2:24 PM - 11 Feb 2013=

Unfortunately a large number of developers think that disabling SSL peer verif= ication is the correct fix to a SSL path validation error. There are many m= ore that will offer the same advice with the caveat that it introduces = a security issue that < 100% of readers will consider. As an = API provider with a duty of care to our users we can't simply hope deve= lopers on our platform don't do this.

Bearer tokens<= /span>

Once a user authorises a client application to access it= s account, the application obtains a bearer token from the authorisation se= rver. As the name suggests if you have possession of the bearer token then = you are essentially the user. There is no cryptographic proof that the requ= esting client is the intended developer and not an attacker. If an attacker= is able to successfully MITM a client it could have catastrophic implicati= ons for the user, e.g. an empty bank account, loans opened in their name, e= tc. OAuth 2.0 is simply a security car crash from a bank's perspective.= They have no way to prove that an API transaction is bona fide, exposing t= hem to unlimited liability.

For more information on OAut= h 2.0 shortcomings see OAuth Bearer Tok= ens are a Terrible Idea and OAuth 2.0= and the Road to Hell by Eran Hammer the original primary aut= hor of OAuth 2.0 who formally removed his name from the standard, calling i= t "the biggest professional disappointment of [his] career."

Finding something better

Sitting down to = design the solution to this problem I had two high-level goals:

<= ul>
  • be the most secure solution for the user
  • not unnecessarily impede developer experience. Developers are = users too and their needs deserve equal consideration.

    • <= span>From a security perspective I wanted:

    • <= span>cryptographic proof of client identity
    • to stop MI= TM attacks
    • to unimpeachably attribute a request to a g= iven developer. In cryptography this is known as non-repudiation.

    (N.B. Non-repudiation is a de facto requi= rement of PSD II. If a bank can't prove an account owner authorised a t= ransaction, they're liable for any losses incurred by the user.)=

    There are solutions to the bearer token problem like JWT token= s (= RFC7523) but in most cases these rely on a shared secret which i= s used to computed a HMAC-based signature. Shared secrets mean no non-repud= iation. Public key cryptography can be used with JWT tokens but they don= 9;t solve the problem of how the client will generate key pairs, demonstrat= e proof of possession of the private key, and enrol the public key with the= API. Most importantly using JWT tokens make it basically impossible for yo= u to experiment with an API using cURL. A major impediment to developer exp= erience.

    In an ideal world we'd have cryptographic p= roof of the client's identity without it having to leak through the app= lication level (and stop us cURLing the API!). As I thought about it it bec= ame the clear the answer was hiding in plain sight: SSL cli= ent certificates.

    Client SSL Authentication

    A SSL handshake involving client certificates contains an extra = message at the end of the handshake, the CertificateVerify = message.

    =C2=A0 Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server


    =C2=A0 ClientHello=C2=A0 =C2=A0 =C2= =A0 =C2=A0 -------->

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 ServerHello

    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate*

    =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ServerKeyExchange*

    <= span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CertificateRequest*=

    =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 <--------=C2=A0 =C2=A0 =C2=A0 ServerHelloDone

    =C2=A0 Certificate*

    =C2=A0 ClientKeyExchan= ge

    =C2=A0 CertificateVerify*

    =C2=A0 [= ChangeCipherSpec]

    =C2=A0 Finished =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 -------->

    =C2=A0=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 [ChangeCipherSpec]

    =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-------- =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Finished

    =C2=A0 A= pplication Data =C2=A0 <-------> =C2=A0 =C2=A0 Application Data


    =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 Fig= . 1 - Message flow for a full handshake

    The client colle= cts all the handshake messages and signs them with it's private key and= sends the result to the server. The server then verifies the signature usi= ng the public key of the client certificate. If the signature can be verifi= ed with the public key, the server knows the client is in possession of the= private key, and is therefore a bona fide user.

    Let'= ;s look at this in the context of our original attack:

    • client attempts to connect to service
    • attacker successfully reroutes traffic to a host it controls
      • malicious host accepts connection from client accepting the client&= #39;s certificate
    • malicious host connects to service
    • the malicious host will fail to SSL handshake because t= he host doesn=E2=80=99t have the private key for the client=E2=80=99s certi= ficate. The attacker therefore cannot compute the correct C= ertificateVerify handshake message. The Ce= rtificateVerify message from the first handshake cannot be= used because the handshake sequences diverge (different server certificate= s presented by the host).

    Introducing TAuth=

    TAuth is Client SSL Authentication + User Tokens + Great Tooli= ng.

    Client SSL authentication is often overlooked becaus= e of the poor UX of using client certificates in the browser and that gener= ating certificates is a painful multistep process involving arcane OpenSSL = CLI incantations. However as we're talking about API clients the browse= r UX point is irrelevant. As far as certificate generation goes, we can wri= te better tools. These days it's possible to generate a key pair, a PKC= S#10 certificate request, and sign it all in the browser. Thanks to WebCrypto the whole process is reduced to one click.

    Thi= s is how Teller does it:

    A private key and a SSL certifi= cate signed by Teller generated in one click.

    And this i= s what a request looks like with client certificates:

    Le= t's recap what we've achieved here:

    • = Cryptographic proof of the client identity
    • The c= URLability of the API is preserved
    • The client develope= r has generated a private key known only to them and no one else, meaning t= he bank can actually say "you did that transaction" (non-repudiat= ion)

    Token security

    Notice in t= he above example. The Teller API accepts connections from clients without a= client certificate. We do this because we provide developers with read-onl= y personal access tokens for their own accounts if they want to quickly hac= k something up and not bother with provisioning certs. Now notice how the A= PI does not accept the token presented, but accepts it when used with the c= lient SSL certificate. TAuth bearer tokens are bound on the server side to = a private key through an application. This means they are useless without t= he private key (which only the developer ever has) and therefore not sensit= ive. As matter of fact, here is one for my bank account:


    You'll need the private key it's bound to = for it to be of any use, and that has never left my laptop.

    TAuth tokens do not expire (but can be revoked). OAuth 2.0 introduced t= he concept of time-limited tokens. Large internet companies found it useful= for scaling purposes to issue self-encoded, encrypted tokens. The drawback= s are developers have to pay the complexity cost of refreshing tokens and m= ost importantly tokens cannot be revoked, they're good until they expir= e. For bank account APIs this is an undesirable property, a token should be= void as soon as the account owner wishes. TAuth checks the token revocatio= n status at each request.

    Given that we have no need for= self-encoded tokens and that tokens are useless to anyone without the priv= ate key, we can consider them public and directly return them in the callba= ck further simplifying things for the developer compared to OAuth without c= ompromising the user's security.

    Bonus: DDOS mitigat= ion

    TAuth can help mitigate layer 7= based DDOS attacks too. If the client does not present a valid = client certificate the server can just choose to bounce the connection.

    Conclusion

    OAuth 2.0 is simply not fit f= or use with sensitive APIs and all the pieces needed to build something tha= t is exist today. Aside from unbound bearer tokens, OAuth is too open-ended= and complicated to get right for most developers. It's so bad it even = has it's own threat model as a separate RFC to offer mitigation= s for the endless problems that can happen.

    TAuth sta= nds for Trusted Authentication, and it provides the best s= ecurity for users while maintaining the highest possible quality developer = experience. Less can go wrong when everything is simpler. I= f your bank has OAuth 2.0 in production you must ask yourself, do they real= ly know what they're doing?

    TAuth is available i= n production today for our existing beta users and we've already begun = the work to make it an open standard we hope the industry adopts. If you= 9;re at a bank and want to offer your customers the security they deserve e= mail me - sg at teller.io

    Sign up for the beta waiting list = at Teller.io.

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



    --
    Subscribe to the HARDTWARE mail list to learn about proje= cts I am working on!
    --bcaec505533906e9590532860b43-- From nobody Wed May 11 03:47:47 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264C512D662 for ; Wed, 11 May 2016 03:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 COlH1TQB5hzD for ; Wed, 11 May 2016 03:47: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 2730512D907 for ; Wed, 11 May 2016 03:47:42 -0700 (PDT) Received: from [192.168.10.140] ([80.92.119.69]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LtEtL-1bk39j2fgh-012oN7 for ; Wed, 11 May 2016 12:47:40 +0200 From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 To: "oauth@ietf.org" Message-ID: <57330DCC.1040109@gmx.net> Date: Wed, 11 May 2016 12:47:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8ec1ocVXxbqk4tcTtD1h3GdMmUt5MHc1b" X-Provags-ID: V03:K0:kIfwQib8wlTNq7NUY/+2xWmcSSEqfmtGZLD2yDihTiRhAqkqKCW eduyr6XPkRrYPmAAuAaS3GSO+4tAIcUEUr1bMHbyErF8hI6n5XXqprbF7K/wn1KgCdy8laU +14vnf2D9omXqt612fA908VGJ184Tz53KLa8auLu7UGvaXq6JE2Jf9pYnZIU9FyBta1Jkb2 GVaGZdXjWSwlqBIPyku4Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:cdLjTkSE6oY=:XhwmGECYY5g+BzmHmMVcAk sPsBU66wUSHpnR+R4WecWd1SJWFeYZNJBtfDbB4/E7uVXmqNSHK1zjawe6IlyQKyPa5IF//w4 5t+SjyJqlcYVtusaUmj3Dv6FSbjqxqTiEutqYZykacEm7WBIgtu6unLqVlcCb1+Zdnjy9KFLT av7+zyy0/dKHyDsguU7pi81mFmjw9mvkRA8qIbN6msmzEsHFxVVzxtyoiEwGRtJeh4Ai0v8Eo RQBcGh1SCoXWSHCNYOaP+GqleJD0cJM6+DYRHU/l0ULlC8c+HsXkLVkIq2RmzNhDV6piOh93S adUkTihj/OU0JlN9t7tC1TADAR2pZVDUo6AOZ/cY6JHAva3+iI9RRiFSVui8CANhs7Luc2RRv MWgEf49XNIiTjLLM0TxLnOQkyN3Y8jC3B5jBBVMhZrlSy8bANLJaymDUUKnLtaQkenEIwSjk0 4ItdYu6ZOBRz4TP/wBHwjjwmxWY2VL1y3EMqQnA1dEJ2AAlQMiD9OWaCPy8kiObfOw4244GsP 9H6efdCRT7L64Nhd5xnKprOl+d7hprTcz+LinC6pFqTI7GBz7ybtUnDTee84LSmNY9v97yKnk +/TT/F3n/0VYnmjnFIFii+jTwe9S9cfwsL5ccosASXxDBQ6sMjCNKR8OA7BL54q4IyfT+Htrr b+hZGrco7qwYOsTGGe04BT7POIyXGwcOJ9xq1YAFaSy/eLVerERm4A8byYiDxiQ7AQOSxaibv ay17vtGWL2vLTOezV1xzZHajuzl45/xYbI0bY+kL5YDMA8C0IBIPQ2Snqrg= Archived-At: Subject: [OAUTH-WG] OAuth 2.0 for broadcasters X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 10:47:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8ec1ocVXxbqk4tcTtD1h3GdMmUt5MHc1b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, End of April I had the chance to talk to Michael Barroco (from the European Broadcasting Union) and to Chris Needham (from the BBC) regarding their use of OAuth 2.0 for broadcasters. In March Michael dropped a mail to the OAuth mailing list to make us aware of their work, see https://www.ietf.org/mail-archive/web/oauth/current/msg15969.html The specification they are working on is based on the OAuth Device flow. Michael and Chris walked me through a slide deck offering me more background regarding their work. (I will upload the slide deck to our Wiki but the IETF meeting site seems to be down at the moment.) In addition to the specification code and tutorials have been developed and you can find them here: https://github.com/ebu/cpa-tutorial https://tech.ebu.ch/code I gave Chris & Michael an update of what we are doing in the OAuth working group since I believe some of our currently chartered items could be relevant for them, such as the native apps BCP or the PoP/Token Binding work. I also mentioned that we are looking for feedback from their group on the Device Flow specification. Ciao Hannes --8ec1ocVXxbqk4tcTtD1h3GdMmUt5MHc1b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXMw3MAAoJEGhJURNOOiAtoncIAJB1Z8jGPFrTUItfJ200jRSk sCB9u5dEJKhdJ4WQwQyXgCD9Dk42koHCgYKow5v2CS7VJEaxgSevYOV+95q6PCmR dvazjKRVGFYOHsQl5L69XeA0JwTRW/Fh7oBFmMAICU+Sdzo4sZsgmGlQ1Nqwtp/p FR5R5mxQSD04sl+/06Pafbh3MmrIm6XCPze7FH18QmWKDXm+RP1r0KdEFs6hFTkD pKlxUGs8qECzVrMnBQZ+o3nvCTkPePz7yBh6ekeuKyfBj3EjCdhg6TvbqX8ylCYO iNVxtquQNer79U5M5c0DkZEJJjhKPJyy7l3rhThXvcCLDcgyQh75lo5VfejYEA0= =rXF3 -----END PGP SIGNATURE----- --8ec1ocVXxbqk4tcTtD1h3GdMmUt5MHc1b-- From nobody Wed May 11 04:43:39 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B415212DA49 for ; Wed, 11 May 2016 04:43:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wahlstromstekniska-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzwL_bnnYD3b for ; Wed, 11 May 2016 04:43:32 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC6B12D9FA for ; Wed, 11 May 2016 04:42:19 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id j8so46090631lfd.2 for ; Wed, 11 May 2016 04:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wahlstromstekniska-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=V/5uyXhRz57b+dBXJLXV0qEIfOO5q3B90mczNrMKxG0=; b=IFM6MRSohXEzsjmZ9jDvspEpLR469KdmsGi6y016y3FiAMmqhJPUcUmuWz0+X0KAZg Wu29Q7/yOhFTb9+UcW1ADORrdX4uUmqW3l89psHiVmLPYkEDcjmMm7puPBITpjMjqpM5 BhOxsgPFWjIyLjvjMPaDRRRz2R0Wt5unM8GvXjKLkG9DS7bs3CrlJMOvgUCN9MHwTuyt ur6aFGuipfgQ2aj4ggJvIGZFnzb3YSzN9dkflao4E2IWcSMMtaGzxXwCOaaSJCdgalZN LmHoMwL7yrShNoXTHDwBm7zrYaxhrf5fTJtn5kssGm1caNpz0oupt9UcQBfth4QKTsNX Yv8w== 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:date :message-id:subject:from:to:cc; bh=V/5uyXhRz57b+dBXJLXV0qEIfOO5q3B90mczNrMKxG0=; b=AllclDOvEw3tkZysJm210i9h1UGPlPYKES1X5fwKGtuOTdykpUvxJezqq9hGRhTEjY Q5XpdewuRZSMEuq33xiCED39E7yw1T7h7ucicRxkVGV6q66ZdNQYU5aB1LQvOQOyWnsk DPScHZsKW+51bklX2sGUirFjJhEmi6uD3etd66aUvCkHqrIQTsR/tQkpZG9uvSpyNXzc fxFMrWNPpi5KcMr29NgvPTZPjGGgvSy+jyO+7HGw//9wxWy3YkEz6S3g1WOG4rMKum/J bfskq00NX7DFI432DQeymv2rMcLGwXIbVZYYfNbiDXhEykBz/kasuNoP2D30Avfe6OVD 26sw== X-Gm-Message-State: AOPr4FXF+wNhvSynVyepAt2P+OaHKNEllZ5+lGdehKSh+/FXLRFB/sCsch9JmdeOMnu4vGpjaCgHQ8Vqmxos7Q== MIME-Version: 1.0 X-Received: by 10.112.61.39 with SMTP id m7mr1311562lbr.72.1462966937603; Wed, 11 May 2016 04:42:17 -0700 (PDT) Received: by 10.25.136.5 with HTTP; Wed, 11 May 2016 04:42:17 -0700 (PDT) X-Originating-IP: [95.192.127.168] In-Reply-To: <5E85AFAC-07D3-4499-A5B2-5FEC69409913@mit.edu> References: <57309F46.9040705@tzi.org> <89B6F196-D08F-4FBD-9F0D-5B250284048F@mit.edu> <5E85AFAC-07D3-4499-A5B2-5FEC69409913@mit.edu> Date: Wed, 11 May 2016 13:42:17 +0200 Message-ID: From: =?UTF-8?Q?Erik_Wahlstr=C3=B6m?= To: Justin Richer Content-Type: multipart/alternative; boundary=e89a8f503798a2668c05328f88c1 Archived-At: Cc: "ace@ietf.org" , "" , cose Subject: Re: [OAUTH-WG] [Ace] [COSE] Call for adoption for draft-wahlstroem-ace-cbor-web-token-00 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 11:43:36 -0000 --e89a8f503798a2668c05328f88c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's a very value scenario actually. Even so that it should actually be handled in the draft. Scenario: In the continuum of large and small devices an unconstrained client and AS goes through the hoops of issuing a token using standard (HTTP/JSON). The Resource Server however is constrained and would very much like a CWT when it communicates with the Client. That means that in the AS to Client response from the token endpoint the binary token should actually be wrapped by base64url. I can definitely see that being added to the draft. / Erik On Tue, May 10, 2016 at 2:57 PM, Justin Richer wrote: > You=E2=80=99re missing my original complaint: Until this token can be dir= ectly > encoded into web technologies, like HTTP headers and HTML pages, then it > has no business being called a =E2=80=9CWeb=E2=80=9D anything. As it is, = it=E2=80=99s a binary > encoding that would need an additional wrapper, like base64url perhaps, t= o > be placed into web spaces. It can be used in CoAP and native CBOR > structures as-is, which is what it=E2=80=99s designed to do. > > The =E2=80=9Cweb=E2=80=9D part of JWT is very important. A JWT can be use= d, as-is, in any > part of an HTTP message: headers, query, form, etc. It can also be encode= d > as a string in other data structures in just about any language without a= ny > additional transformation, including HTML, XML, and JSON. This makes the > JWT very =E2=80=9Cwebby=E2=80=9D, and this is a feature set that this new= token doesn=E2=80=99t > share. Ergo, it has no business being called a =E2=80=9Cweb=E2=80=9D toke= n regardless of > its heritage. > > Both CBOR Token and COSE Token are fine with me. > > =E2=80=94 Justin > > On May 10, 2016, at 3:50 AM, Mike Jones > wrote: > > I also feel strongly that the name should remain CBOR Web Token. CWT is = a > beneficiary of the intellectual and deployment heritage from the Simple W= eb > Token (SWT) and JSON Web Token (JWT). CWT is intentionally parallel to > JWT. The name should stay parallel as well. > > The =E2=80=9CWeb=E2=80=9D part of the =E2=80=9CCBOR Web Token=E2=80=9D na= me can be taken as a reference to > the Web of Things (see https://en.wikipedia.org/wiki/Web_of_Things). As > Erik correctly points out JSON is not the only data representation that > makes things in the Web and the Web of Things. > > -- Mike > > *From:* Ace [mailto:ace-bounces@ietf.org ] *On > Behalf Of *Erik Wahlstr=C3=B6m > *Sent:* Tuesday, May 10, 2016 1:44 AM > *To:* Justin Richer > *Cc:* Kathleen Moriarty ; Kepeng Li < > kepeng.lkp@alibaba-inc.com>; ace@ietf.org; Carsten Bormann = ; > Hannes Tschofenig ; < > oauth@ietf.org>; cose > *Subject:* Re: [Ace] [COSE] Call for adoption for > draft-wahlstroem-ace-cbor-web-token-00 > > Or keep the CBOR Web Token (CWT) for two major reasons: > - To show the very close relationship to JWT. It relies heavily on JWT an= d > it's iana registry. It is essentially a JWT but in CBOR/COSE instead of > JSON/JOSE. > - I would not say that JWT is the only format that works for the web, and > it's even used in other, non-traditional, web protocols. That means I don= 't > have a problem with the W in CWT at all. Why would JSON be the only web > protocol? > > Then we also have one smaller (a lot smaller) reason, it's the fact that > it can be called "cot" just like JWT is called a "jot" and I figured that > our "cozy chairs" would very much like that fact because then it's > essentially a "cozy cot" :) > > / Erik > > > On Tue, May 10, 2016 at 2:49 AM, Justin Richer wrote: > > We can also call it the =E2=80=9CCOSE Token=E2=80=9D. As a chair of the C= OSE working > group, I=E2=80=99m fine with that amount of co-branding. > > =E2=80=94 Justin > > > On May 9, 2016, at 9:31 AM, Carsten Bormann wrote: > > > >> draft-ietf-ace-cbor-token-00.txt; > > > > For the record, I do not think that ACE has a claim on the term "CBOR > > Token". While the term token is not used in RFC 7049, there are many > > tokens that could be expressed in CBOR or be used in applying CBOR to a > > problem. > > > > ACE CBOR Token is fine, though. > > (Or, better, CBOR ACE Token, CAT.) > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > _______________________________________________ > > COSE mailing list > > COSE@ietf.org > > https://www.ietf.org/mailman/listinfo/cose > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > > > --e89a8f503798a2668c05328f88c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    That's a very value scenario actually. Even so that it= should actually be handled in the draft.
    Scenario: In the continuum of= large and small devices an unconstrained client and AS goes through the ho= ops of issuing a token using standard (HTTP/JSON). The Resource Server howe= ver is constrained and would very much like a CWT when it communicates with= the Client. That means that in the AS to Client response from the token en= dpoint the binary token should actually be wrapped by base64url.=C2=A0
    I can definitely see that being added to the draft.
    / Erik<= /div>

    On Tue= , May 10, 2016 at 2:57 PM, Justin Richer <jricher@mit.edu> wro= te:
    Y= ou=E2=80=99re missing my original complaint: Until this token can be direct= ly encoded into web technologies, like HTTP headers and HTML pages, then it= has no business being called a =E2=80=9CWeb=E2=80=9D anything. As it is, i= t=E2=80=99s a binary encoding that would need an additional wrapper, like b= ase64url perhaps, to be placed into web spaces. It can be used in CoAP and = native CBOR structures as-is, which is what it=E2=80=99s designed to do.=C2= =A0

    The =E2=80=9Cweb=E2=80=9D part of JWT is very import= ant. A JWT can be used, as-is, in any part of an HTTP message: headers, que= ry, form, etc. It can also be encoded as a string in other data structures = in just about any language without any additional transformation, including= HTML, XML, and JSON. This makes the JWT very =E2=80=9Cwebby=E2=80=9D, and = this is a feature set that this new token doesn=E2=80=99t share. Ergo, it h= as no business being called a =E2=80=9Cweb=E2=80=9D token regardless of its= heritage.=C2=A0

    Both CBOR Token and COSE Token ar= e fine with me.=C2=A0

    =C2=A0=E2=80=94 Justin

    On May 10, 2016, at 3:= 50 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

    I = also feel strongly that the name should remain CBOR Web Token.=C2=A0 CWT is= a beneficiary of the intellectual and deployment heritage from the Simple = Web Token (SWT) and JSON Web Token (JWT).=C2=A0 CWT is intentionally parall= el to JWT.=C2=A0 The name should stay parallel as well.
    =C2=A0
    The =E2=80=9CWeb=E2=80=9D part of the =E2=80=9CCBOR = Web Token=E2=80=9D name can be taken as a reference to the Web of Things (s= ee=C2=A0https:= //en.wikipedia.org/wiki/Web_of_Things).=C2=A0 As Erik correctly points = out JSON is not the only data representation that makes things in the Web a= nd the Web of Things.
    =C2=A0
    =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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:=C2=A0= Ace [mailt= o:ace-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Erik Wahlstr=C3=B6m
    Sent:=C2=A0Tuesday, May= 10, 2016 1:44 AM
    To:=C2=A0Justin Richer <jricher@mit.edu>
    Cc:    =C2=A0Kathleen Moriarty <kathleen.moriarty.ietf@gmail.co= m>; Kepeng Li <kepeng.lkp@alibaba-inc.com>; ace@ietf.org; Carsten Bormann <cabo@tzi.org>; Hannes Tschofen= ig <hanne= s.tschofenig@gmx.net>; <oauth@ietf.org> <oauth@ietf.org>; cose <cose@ietf.org>
    Subject:=C2= =A0Re: [Ace] [COSE] Call for adoption for draft-wahlstroem-ace-cbor-= web-token-00
    =C2=A0=
    Or keep the CBOR Web Token (CWT) f= or two major reasons:
    - To s= how the very close relationship to JWT. It relies heavily on JWT and it'= ;s iana registry. It is essentially a JWT but in CBOR/COSE instead of JSON/= JOSE.
    - I would not sa= y that JWT is the only format that works for the web, and it's even use= d in other, non-traditional, web protocols. That means I don't have a p= roblem with the W in CWT at all. Why would JSON be the only web protocol?
    =C2=A0
    Then we also have one smaller (a lot s= maller) reason, it's the fact that it can be called "cot" jus= t like JWT is called a "jot" and I figured that our "cozy ch= airs" would very much like that fact because then it's essentially= a "cozy cot" :)
    =C2=A0
    / Erik<= /u>
    =C2=A0
    =C2=A0
    On Tue, May 10, 2016 at 2:49 AM, Justin Richer <jricher@mit.edu> wrote:
    We can also call it the =E2=80= =9CCOSE Token=E2=80=9D. As a chair of the COSE working group, I=E2=80=99m f= ine with that amount of co-branding.

    =C2=A0=E2=80=94 Justin

    &= gt; On May 9, 2016, at 9:31 AM, Carsten Bormann <cabo@tzi.org> wrote:
    >
    >> draft-ietf-ace-cbor-token-= 00.txt;
    >
    > For the record, I do not think that ACE has a claim= on the term "CBOR
    > Token".=C2=A0 While the term token is = not used in RFC 7049, there are many
    > tokens that could be expressed= in CBOR or be used in applying CBOR to a
    > problem.
    >
    > = ACE CBOR Token is fine, though.
    > (Or, better, CBOR ACE Token, CAT.)<= br>>
    > Gr=C3=BC=C3=9Fe, Carsten
    >
    > __________________= _____________________________
    > COSE mailing list
    >=C2=A0= COSE@ietf.org
    >=C2=A0https://www.ietf.org/mailma= n/listinfo/cose
    _______________________________________________
    Ace mailing list
    Ace@ietf.org
    https://www.ietf.org/mailman/listinfo/ace
    =


    --e89a8f503798a2668c05328f88c1-- From nobody Wed May 11 14:59:45 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E8612D716 for ; Wed, 11 May 2016 14:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjklNoSBp1D6 for ; Wed, 11 May 2016 14:59:41 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EBB012D60F for ; Wed, 11 May 2016 14:59:41 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id 90so31941686qgz.1 for ; Wed, 11 May 2016 14:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wkaON4LRzOBw9hD0sCxIQ/dhUWS4Z1lW0M6D2WF4ZYk=; b=bG2e4CRW+4s15cYxU1D0RSMbW/D8GMTAOQa+J9OA1g+fMinKTajIRuKxBG1flo6M2F A4E6ijXIYSdFL0Tel0iS3zqVEPEwhFJe5wzBY6wV8EbNvP11TWuT4drS9z3niRU3R5yv M218evVX4aZkJYn0jHXcJ0G8P/fuX/eSd35WFN7QPyG8nkOF1RDLGv9691YEHNozYWTq 0HmNzEniBX7fn/KmJM0fU3UOvC+CavJRLVbD/X4mpuWpf/2A1N3fcnG+Wm7n9diLR4Dc DgbhKrHS6cBK9j/fUO0hfZ9tw3frpm/TbqXEB/EEKmrCg0iIkQVgl+P3n3f/Qx+ZVaog DiDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wkaON4LRzOBw9hD0sCxIQ/dhUWS4Z1lW0M6D2WF4ZYk=; b=JrepKokxHn5OyFoIJ9uRKxPjHO6PytHiYLdgC0KvqZyCA1H0qzjY3q/Hu6Kz6HMhgW v3tgtql+UninetGSi1MBxYNWasd4eTmOSFPUyceGz30vrmqte9UB7gzJmkZ1FEPGOv2y MrhB/AfH7R4xW26yNlTlJUDJQ+zUYepTU+jSJjO7sg5Wqt18Ru6LKt8Na6xxF4yPJVm6 18YjpmvuGOjqnDPrtqHfmRgJcwbdb8QAtM6ncxrrNokFCslwq677hTcd2EgXys1EZVq1 ZsGGCayn9k5Flft+7Zqf+BQNo/xvQEBG2lqJKMMc8e9KbwDUhjvY4M19AQQpAyz/GOOL 0Nrw== X-Gm-Message-State: AOPr4FUQLNluUskYM4MarV96T9IyLVexe9jJoNewdzKxvsQoUma/+CVj9NGnbqPJvxC++/+gdCQic6evKOx48Q== X-Received: by 10.140.19.131 with SMTP id 3mr6191267qgh.83.1463003980333; Wed, 11 May 2016 14:59:40 -0700 (PDT) MIME-Version: 1.0 References: <571A33E0.6070401@uni-trier.de> <5730D36A.4050601@gtrs.de> <5731ABD3.2070502@uni-trier.de> In-Reply-To: <5731ABD3.2070502@uni-trier.de> From: Nat Sakimura Date: Wed, 11 May 2016 21:59:29 +0000 Message-ID: To: Daniel Fett , oauth@ietf.org Content-Type: multipart/alternative; boundary=001a1135522a8d8b6d0532982859 Archived-At: Subject: Re: [OAUTH-WG] Multi-AS State Re-Use X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 21:59:44 -0000 --001a1135522a8d8b6d0532982859 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed. Also, pointing to OWASP guide or something for CSRF token may be useful. On Tue, May 10, 2016 at 11:37 Daniel Fett wrote: > Regardless of what state actually is, the documentation (also the one > for OIDC) should make clear that the same state should not be sent to > two different AS, and that a state issued for AS #1 should be invalid > for AS #2. > > Am 10.05.2016 um 09:31 schrieb Anthony Nadalin: > > STATE can be anything, it does not have to be a NONCE so changing this > > would cause issues at this time for existing deployments > > > > > > > > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Nat Sakimur= a > > *Sent:* Monday, May 9, 2016 7:34 PM > > *To:* Guido Schmitz ; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Multi-AS State Re-Use > > > > > > > > As far as I am aware of, state was meant to be nonce. Replay possibilit= y > > etc. were known. It is probably a bad documentation that every reviewer= s > > missed because they were assuming it. > > > -- > Informationssicherheit und Kryptografie > Universit=C3=A4t Trier - Tel. 0651 201 2847 - H436 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura Chairman of the Board, OpenID Foundation Trustee, Kantara Initiative --001a1135522a8d8b6d0532982859 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed. Also, pointing to OWASP guide or something for CSRF token may be us= eful.
    On Tue, May 10, 2016 = at 11:37 Daniel Fett <fett@uni-trie= r.de> wrote:
    Regardless of w= hat state actually is, the documentation (also the one
    for OIDC) should make clear that the same state should not be sent to
    two different AS, and that a state issued for AS #1 should be invalid
    for AS #2.

    Am 10.05.2016 um 09:31 schrieb Anthony Nadalin:
    > STATE can be anything, it does not have to be a NONCE so changing this=
    > would cause issues at this time for existing deployments
    >
    >
    >
    > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Nat Sakimura
    > *Sent:* Monday, May 9, 2016 7:34 PM
    > *To:* Guido Schmitz <g.schmitz@gtrs.de>; oauth@ietf.org
    > *Subject:* Re: [OAUTH-WG] Multi-AS State Re-Use
    >
    >
    >
    > As far as I am aware of, state was meant to be nonce. Replay possibili= ty
    > etc. were known. It is probably a bad documentation that every reviewe= rs
    > missed because they were assuming it.


    --
    Informationssicherheit und Kryptografie
    Universit=C3=A4t Trier - Tel. 0651 201 2847 - H436

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --
    --001a114b0d568d93560532a5bcc2-- From nobody Thu May 12 15:14:36 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D58F12D0C1 for ; Thu, 12 May 2016 15:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emnenr9XueVE for ; Thu, 12 May 2016 15:14:33 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2FA712B03C for ; Thu, 12 May 2016 15:14:32 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id f89so111670227ioi.0 for ; Thu, 12 May 2016 15:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dTdd6OjPeLZtuw4JEsPMiIFOuFPzpIAxbo3q+iAMViY=; b=bjr0XP+QnvjXk8ewkLICB3iHLZHMvYbpdVneyWiBYklfVt71Tg3BQjvIWxBAUeAQM+ HdWNqFGImdbJ8JkITLaCXH6cJf89lQoXXKTj7Kus0pNaUVYdPuLqphdf9HtO+T1pdVxe lErbOZkSOEHNVkkGG+5+2PNZyXrG6FRGZckHk= 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; bh=dTdd6OjPeLZtuw4JEsPMiIFOuFPzpIAxbo3q+iAMViY=; b=AJrOfkv+sxLNokSmzcQJ9j61GNIni2RBLW2Tj3VW1DFFDfu3R9UTcJ2Dvqf/1dyMSm BgQkU1WwSCrIKmp1obs3S1BM4v9nHDqeg2P5C8u79JGeLz2gj3y4f7L5UwKrBRD+ToqR oGj18CBaip3LGU4vBCd0gVomcZK3t2xaWM0NlVv0dcYizmzDNczv0VX1fgkSZvnmtiSE ZlUOuEFVfffVx952PtheNZ7NDF8pWrO+8OeG2dQnstdjs5DrQ5Lyxxdz8GOabHfwtu+5 0kshlc4+Dmg6Cki1YGDYRHPTrtk0LCjky1KtuCbTOsuBRnxBxTAQpAIJpScfNLF30zaq swxw== X-Gm-Message-State: AOPr4FVQgISAspwbusvxIvwnmglbPbflRxds3qhPxCdcQxmL+xZbisqUlD4pYyj9AgXGTJCSCCscunXiCatVdrRp X-Received: by 10.107.53.204 with SMTP id k73mr9271769ioo.174.1463091272006; Thu, 12 May 2016 15:14:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.105.129 with HTTP; Thu, 12 May 2016 15:14:02 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 12 May 2016 16:14:02 -0600 Message-ID: To: isciurus Content-Type: multipart/alternative; boundary=001a114497ac8aeacc0532ac7b8c Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Comments about PKCE / RFC7636 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 22:14:35 -0000 --001a114497ac8aeacc0532ac7b8c Content-Type: text/plain; charset=UTF-8 I believe that you're correct that the two cases you mention are not directly covered by PKCE. Some kind of user interaction should be required at the AS for public clients to prevent undetectable authz requests (I think maybe Android even enforces it). https://tools.ietf.org/html/draft-ietf-oauth-native-apps-01 is a work in progress document that has effectually overtaken the native apps sso work that you'd linked to and describes some best practices for OAuth and native apps. That includes the use of PKCE in section 5.2 and section 5.4 is about needing user interaction when handling authz requests from non-verifiable clients. I realize I probably didn't exactly answer your questions but I hope that helps. On Tue, May 10, 2016 at 3:58 PM, isciurus wrote: > Hi, > > I have a few comments regarding the Proof Key for Code Exchange spec: > > 1. I wonder how exactly PKCE guarantees the protection for native apps in > the context of generic OAuth 2 flow with an external browser, considering > that a malicious app can initiate an authz request itself? More precisely, > I believe there are two cases PKCE doesn't cover: > - Malicious app generates its own code_verifier and opens an authz request > in an external browser, which allows it to follow "1.1. Protocol Flow", > eavesdrop the code at the callback uri it hijacked, and exchange it for > token > - Malicious app abuses the "5. Compatibility" section by initiating authz > request without code_verifier for clients not supporting this extension, > which allows it to just eavesdrop the code at the callback uri it hijacked, > and exchange it for token > By using parameter such as "immediate=true" / "display=none" app can even > make authz request undetectable as it would silently succeed for previously > TOSed apps and considering an existing browser session on provider. > > 2. Is it actually meant to be a sufficient protection to just follow PKCE > in the generic OAuth 2 flow case for public clients (vs. using PKCE > together with other improvements, such as with native apps sso flow > http://www.thread-safe.com/2015/01/napps-high-level-flow-for-ios.html)? > > 3. What is meant by a "secure API" in the following claim from the "1. > Introduction": > "Step (1) happens through a secure API that cannot be > intercepted, though it may potentially be observed in advanced attack > scenarios."? > > Thanks, > Andrey > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a114497ac8aeacc0532ac7b8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    I believe that you're correct that the = two cases you mention are not directly covered by PKCE.

    Some kind of user interaction should be required at the AS for public clie= nts to prevent undetectable authz requests (I think maybe Android even enfo= rces it). https://tools.ietf.org/html/draft-ietf-oauth-native-apps-01 is a= work in progress document that has effectually overtaken the native apps s= so work that you'd linked to and describes some best practices for OAut= h and native apps. That includes the use of PKCE in section 5.2 and section= 5.4 is about needing user interaction when handling authz requests from no= n-verifiable clients.

    I realize I p= robably didn't exactly answer your questions but I hope that helps.

    On Tue, May 10, 2016 at 3:58 PM, isciurus <isciurus@gmail.com= > wrote:
    = Hi,

    I have a few comments regarding the=C2=A0Proof= Key for Code Exchange spec:

    1. I wonder how exact= ly PKCE guarantees the protection for native apps in the context of generic= OAuth 2 flow with an external browser, considering that a malicious app ca= n initiate an authz request itself? More precisely, I believe there are two= cases PKCE doesn't cover:
    - Malicious app generates its own = code_verifier and opens an authz request in an external browser, which allo= ws it to follow "1.1. Protocol Flow", eavesdrop the code at the c= allback uri it hijacked, and exchange it for token
    - Malicious ap= p abuses the "5. Compatibility" section by initiating authz reque= st without code_verifier for clients not supporting this extension, which a= llows it to just eavesdrop the code at the callback uri it hijacked, and ex= change it for token
    By using parameter such as "immediate=3D= true" / "display=3Dnone" app can even make authz request und= etectable as it would silently succeed for previously TOSed apps and consid= ering an existing browser session on provider.

    2. = Is it actually meant to be a sufficient protection to just follow PKCE in t= he generic OAuth 2 flow case for public clients (vs. using PKCE together wi= th other improvements, such as with native apps sso flow http://www.thread-safe.com/2015/01/napps-high-level-flow-for-ios.htm= l)?

    3. What is meant by a "secure API&quo= t; in the following claim from the "1. Introduction":
    &= quot;Step (1) happens through a secure API that cannot be
    interce= pted, though it may potentially be observed in advanced attack
    sc= enarios."?

    Thanks,
    Andrey

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


    --001a114497ac8aeacc0532ac7b8c-- From nobody Thu May 12 19:04:47 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F2012B049 for ; Thu, 12 May 2016 19:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 Xi_18okaSrp7 for ; Thu, 12 May 2016 19:04:42 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id E88FD12B038 for ; Thu, 12 May 2016 19:04:40 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,611,1454936400"; d="scan'208,217"; a="77164142" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 13 May 2016 12:04:38 +1000 X-IronPort-AV: E=McAfee;i="5700,7163,8163"; a="114570310" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcani.tcif.telstra.com.au with ESMTP; 13 May 2016 12:04:38 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3703.srv.dir.telstra.com ([fe80::9c60:bf5:3f86:2ec%11]) with mapi; Fri, 13 May 2016 12:04:37 +1000 From: "Manger, James" To: Hannes Tschofenig , "oauth@ietf.org" , "barroco@ebu.ch" Date: Fri, 13 May 2016 12:04:35 +1000 Thread-Topic: [OAUTH-WG] Cross Platform Authentication - OAuth 2.0 Device Flow - WWW-Authenticate to advertise OAuth 2.0 support Thread-Index: AdGsupjwfcrwpXIcTEuuyXNQqzqKzw== Message-ID: <255B9BB34FB7D647A506DC292726F6E13BD166320F@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BD166320FWSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Cross Platform Authentication - OAuth 2.0 Device Flow - WWW-Authenticate to advertise OAuth 2.0 support X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 02:04:46 -0000 --_000_255B9BB34FB7D647A506DC292726F6E13BD166320FWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWljaGFlbCAmIE9BdXRoLWVycywNCg0KDQoNClRoZSBFQlUgQ3Jvc3MgUGxhdGZvcm0gQXV0 aCBzcGVjIGhhcyBkZWZpbmVkIHRoZWlyIG93biAiQ1BBIiBzY2hlbWUgZm9yIHRoZSBXV1ctQXV0 aGVudGljYXRlIEhUVFAgcmVzcG9uc2UgaGVhZGVyIHRvIGFkdmVydGlzZSBPQXV0aCAyLjAgY2Fw YWJpbGl0eSBbc2VjdGlvbiA3LjcuMSAiQXV0aGVudGljYXRpb24gY2hhbGxlbmdlIiBpbiBodHRw czovL3RlY2guZWJ1LmNoL2RvY3MvdGVjaC90ZWNoMzM2Ni5wZGZdLg0KDQoNCg0KV1dXLUF1dGhl bnRpY2F0ZTogQ1BBIHZlcnNpb249IjEuMCINCg0KIG5hbWU9IkV4YW1wbGUgQXV0aG9yaXphdGlv biBQcm92aWRlciINCg0KIHVyaT0iaHR0cHM6Ly9hcC5leGFtcGxlLmNvbS9jcGEiDQoNCiBtb2Rl cz0iY2xpZW50LHVzZXIiDQoNCg0KDQpJdCBpcyBhIHNoYW1lIHRoYXQgdGhlcmUgaXNu4oCZdCBh IHN0YW5kYXJkIE9BdXRoIHdheSB0byBkbyB0aGlzIHdpdGhvdXQgbmVlZGluZyBhIENQQS1zcGVj aWZpYyBzY2hlbWUuDQoNCg0KDQpQLlMuIFRoaXMgQ1BBIGV4YW1wbGUgaXMgaW52YWxpZC4gSXQg bmVlZHMgY29tbWFzIGJldHdlZW4gYXR0cmlidXRlcyBbaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzcyMzUjYXBwZW5kaXgtQ10uDQoNCg0KDQotLQ0KDQpKYW1lcyBNYW5nZXINCg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KU2VudDogV2Vk bmVzZGF5LCAxMSBNYXkgMjAxNiA4OjQ4IFBNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6 IFtPQVVUSC1XR10gT0F1dGggMi4wIGZvciBicm9hZGNhc3RlcnMNCg0KDQoNCkhpIGFsbCwNCg0K DQoNCkVuZCBvZiBBcHJpbCBJIGhhZCB0aGUgY2hhbmNlIHRvIHRhbGsgdG8gTWljaGFlbCBCYXJy b2NvIChmcm9tIHRoZSBFdXJvcGVhbiBCcm9hZGNhc3RpbmcgVW5pb24pIGFuZCB0byBDaHJpcyBO ZWVkaGFtIChmcm9tIHRoZSBCQkMpIHJlZ2FyZGluZyB0aGVpciB1c2Ugb2YgT0F1dGggMi4wIGZv ciBicm9hZGNhc3RlcnMuDQoNCg0KDQpJbiBNYXJjaCBNaWNoYWVsIGRyb3BwZWQgYSBtYWlsIHRv IHRoZSBPQXV0aCBtYWlsaW5nIGxpc3QgdG8gbWFrZSB1cyBhd2FyZSBvZiB0aGVpciB3b3JrLCBz ZWUgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21z ZzE1OTY5Lmh0bWwNCg0KDQoNClRoZSBzcGVjaWZpY2F0aW9uIHRoZXkgYXJlIHdvcmtpbmcgb24g aXMgYmFzZWQgb24gdGhlIE9BdXRoIERldmljZSBmbG93Lg0KDQoNCg0KTWljaGFlbCBhbmQgQ2hy aXMgd2Fsa2VkIG1lIHRocm91Z2ggYSBzbGlkZSBkZWNrIG9mZmVyaW5nIG1lIG1vcmUgYmFja2dy b3VuZCByZWdhcmRpbmcgdGhlaXIgd29yay4gKEkgd2lsbCB1cGxvYWQgdGhlIHNsaWRlIGRlY2sg dG8gb3VyIFdpa2kgYnV0IHRoZSBJRVRGIG1lZXRpbmcgc2l0ZSBzZWVtcyB0byBiZSBkb3duIGF0 IHRoZSBtb21lbnQuKQ0KDQoNCg0KSW4gYWRkaXRpb24gdG8gdGhlIHNwZWNpZmljYXRpb24gY29k ZSBhbmQgdHV0b3JpYWxzIGhhdmUgYmVlbiBkZXZlbG9wZWQgYW5kIHlvdSBjYW4gZmluZCB0aGVt IGhlcmU6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9lYnUvY3BhLXR1dG9yaWFsDQoNCmh0dHBzOi8v dGVjaC5lYnUuY2gvY29kZQ0KDQoNCg0KSSBnYXZlIENocmlzICYgTWljaGFlbCBhbiB1cGRhdGUg b2Ygd2hhdCB3ZSBhcmUgZG9pbmcgaW4gdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgc2luY2UgSSBi ZWxpZXZlIHNvbWUgb2Ygb3VyIGN1cnJlbnRseSBjaGFydGVyZWQgaXRlbXMgY291bGQgYmUgcmVs ZXZhbnQgZm9yIHRoZW0sIHN1Y2ggYXMgdGhlIG5hdGl2ZSBhcHBzIEJDUCBvciB0aGUgUG9QL1Rv a2VuIEJpbmRpbmcgd29yay4gSSBhbHNvIG1lbnRpb25lZCB0aGF0IHdlIGFyZSBsb29raW5nIGZv ciBmZWVkYmFjayBmcm9tIHRoZWlyIGdyb3VwIG9uIHRoZSBEZXZpY2UgRmxvdyBzcGVjaWZpY2F0 aW9uLg0KDQoNCg0KQ2lhbw0KDQpIYW5uZXMNCg0KDQoNCg0KDQpGcm9tOiAiQmFycm9jbywgTWlj aGFlbCIgPGJhcnJvY28gYXQgZWJ1LmNoPg0KDQpUbzogIm9hdXRoIGF0IGlldGYub3JnIiA8b2F1 dGggYXQgaWV0Zi5vcmc+DQoNCkNjOiAidHZwLWNwYSBhdCBsaXN0LmVidS5jaCIgPHR2cC1jcGEg YXQgbGlzdC5lYnUuY2g+DQoNCkRhdGU6IE1vbiwgNyBNYXIgMjAxNiAwODo0Mzo1NiArMDAwMA0K DQpEZWFyIGFsbCwNCg0KDQoNCg0KDQpXZSBhcmUgY29udGFjdGluZyB5b3UgYmVjYXVzZSB3ZSBu b3RpY2VkIHRoYXQgeW91IHJlY2VudGx5IHJlc3RhcnRlZCB0aGUgd29yayBvbiBPQXV0aCAyLjAg RGV2aWNlIEZsb3cuIFdlIGFyZSBpbiB0aGUgcHJvY2VzcyBvZiBwdWJsaXNoaW5nIGFuIEVUU0kg c3RhbmRhcmQgWzFdIHNwZWNpZnlpbmcgYSBwcm90b2NvbCB3aXRoIHZlcnkgc2ltaWxhciBnb2Fs cy4gVGhpcyBoYXMgYmVlbiBkZXZlbG9wZWQgYnkgYW4gRUJVIChFdXJvcGVhbiBCcm9hZGNhc3Rp bmcgVW5pb24pIHdvcmtpbmcgZ3JvdXAgaW52b2x2aW5nIGJyb2FkY2FzdGVycywgc3VjaCBhcyBC QkMsIFNSRy1SVFMsIFZSVCwgUlRWRSwgVFZQLCBHbG9iYWwgUmFkaW8gVUssIGFuZCBkZXZpY2Ug bWFudWZhY3R1cmVycy4NCg0KDQoNCg0KDQpPdXIgd29yayBvbiB0aGUg4oCcQ3Jvc3MgUGxhdGZv cm0gQXV0aGVudGljYXRpb27igJ0gcHJvdG9jb2wgdGFyZ2V0cyBtZWRpYSBkZXZpY2VzLCBzdWNo IGFzIGNvbm5lY3RlZCBUVnMgYW5kIHJhZGlvIHJlY2VpdmVycy4gSXQgaXMgYmFzZWQgb24gdGhl IGVhcmx5IE9BdXRoIDIuMCBEZXZpY2UgRmxvdyBkcmFmdCwgYnV0IGluY2x1ZGVzIGFkZGl0aW9u YWwgZmVhdHVyZXMgZHJpdmVuIGJ5IGJyb2FkY2FzdCBpbmR1c3RyeSByZXF1aXJlbWVudHMuIFRo ZXNlIGluY2x1ZGU6IGR5bmFtaWMgcmVnaXN0cmF0aW9uIG9mIGNsaWVudHMsIGR5bmFtaWMgZGlz Y292ZXJ5IG9mIHRoZSBhdXRob3JpemF0aW9uIHByb3ZpZGVyLCBhbmQgaXNzdWluZyBvZiBhY2Nl c3MgdG9rZW5zIHdpdGhvdXQgcmVxdWlyaW5nIGFzc29jaWF0aW9uIHdpdGggYSB1c2VyIGFjY291 bnQgaW4gb3JkZXIgdG8gcHJvdmlkZSBkZXZpY2UtYmFzZWQgYXV0aGVudGljYXRpb24gdGhhdCBk b2VzIG5vdCByZXF1aXJlIHVzZXIgc2lnbi1pbiBvciBwYWlyaW5nLiBPdXIgZHJhZnQgcHJvdG9j b2wgc3BlY2lmaWNhdGlvbiBpcyBhdmFpbGFibGUgaGVyZSBbMl0uDQoNCg0KDQoNCg0KQ3Jvc3Mg UGxhdGZvcm0gQXV0aGVudGljYXRpb24gYWxzbyBzcGVjaWZpZXMgc2V2ZXJhbCBhc3BlY3RzIGxl ZnQgb3BlbiB0byBpbXBsZW1lbnRlcnMgaW4gT0F1dGggMi4wLCBzdWNoIGFzIGVuZHBvaW50IFVS TCBwYXRocywgdG8gZmFjaWxpdGF0ZSBpbnRlcm9wZXJhYmlsaXR5LiBBbHNvIG5vdGUgdGhhdCBy ZWZlcmVuY2UgaW1wbGVtZW50YXRpb25zIGFyZSBhdmFpbGFibGUgWzNdLg0KDQoNCg0KDQoNCldl IHdvdWxkIGJlIHZlcnkgaW50ZXJlc3RlZCBpbiB3b3JraW5nIHRvZ2V0aGVyIHdpdGggeW91IHRv IGV4cGxhaW4gb3VyIGRlc2lnbiByZXF1aXJlbWVudHMgYW5kIHRyeSB0byBhbGlnbiBvdXIgcHJv dG9jb2wgZGVzaWducy4NCg0KDQoNCg0KDQpXaXRoIGJlc3QgcmVnYXJkcywNCg0KDQoNCg0KDQpU aGUgRUJVIENyb3NzIFBsYXRmb3JtIEF1dGhlbnRpY2F0aW9uIGdyb3VwDQoNCg0KDQpodHRwczov L3RlY2guZWJ1LmNoL2NwYQ0KDQoNCg0KDQoNCg0KDQpbMV0gaHR0cHM6Ly9wb3J0YWwuZXRzaS5v cmcvd2ViYXBwL1dvcmtQcm9ncmFtL1JlcG9ydF9Xb3JrSXRlbS5hc3A/V0tJX0lEPTQ3OTcwDQoN Cg0KDQoNCg0KWzJdIGh0dHBzOi8vdGVjaC5lYnUuY2gvZG9jcy90ZWNoL3RlY2gzMzY2LnBkZg0K DQoNCg0KWzNdIGh0dHBzOi8vdGVjaC5lYnUuY2gvY29kZS9jcGENCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo= --_000_255B9BB34FB7D647A506DC292726F6E13BD166320FWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxh aW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4g VGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46 NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLUFVIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29QbGFpblRl eHQ+SGkgTWljaGFlbCAmYW1wOyBPQXV0aC1lcnMsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv UGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5UaGUg RUJVIENyb3NzIFBsYXRmb3JtIEF1dGggc3BlYyBoYXMgZGVmaW5lZCB0aGVpciBvd24gJnF1b3Q7 Q1BBJnF1b3Q7IHNjaGVtZSBmb3IgdGhlIFdXVy1BdXRoZW50aWNhdGUgSFRUUCByZXNwb25zZSBo ZWFkZXIgdG8gYWR2ZXJ0aXNlIE9BdXRoIDIuMCBjYXBhYmlsaXR5IFtzZWN0aW9uIDcuNy4xICZx dW90O0F1dGhlbnRpY2F0aW9uIGNoYWxsZW5nZSZxdW90OyBpbiA8YSBocmVmPSJodHRwczovL3Rl Y2guZWJ1LmNoL2RvY3MvdGVjaC90ZWNoMzM2Ni5wZGYiPmh0dHBzOi8vdGVjaC5lYnUuY2gvZG9j cy90ZWNoL3RlY2gzMzY2LnBkZjwvYT5dLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OkNvbnNvbGFzJz5XV1ctQXV0aGVudGljYXRlOiBDUEEgdmVyc2lvbj0m cXVvdDsxLjAmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpDb25zb2xhcyc+IMKgbmFtZT0mcXVvdDtFeGFtcGxl IEF1dGhvcml6YXRpb24gUHJvdmlkZXImcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpDb25zb2xhcyc+IMKgdXJp PSZxdW90O2h0dHBzOi8vYXAuZXhhbXBsZS5jb20vY3BhJnF1b3Q7PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q29uc29s YXMnPiDCoG1vZGVzPSZxdW90O2NsaWVudCx1c2VyJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+SXQgaXMgYSBzaGFtZSB0aGF0IHRoZXJlIGlzbuKAmXQgYSBzdGFuZGFyZCBPQXV0 aCB3YXkgdG8gZG8gdGhpcyB3aXRob3V0IG5lZWRpbmcgYSBDUEEtc3BlY2lmaWMgc2NoZW1lLjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+UC5TLiBUaGlzIENQQSBleGFtcGxlIGlzIGludmFsaWQuIEl0 IG5lZWRzIGNvbW1hcyBiZXR3ZWVuIGF0dHJpYnV0ZXMgWzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3MjM1I2FwcGVuZGl4LUMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM3MjM1I2FwcGVuZGl4LUM8L2E+XS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pi0tPG86 cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1N c29QbGFpblRleHQ+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tQVUnPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPkZyb206IE9BdXRoIFttYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnPGJy PlNlbnQ6IFdlZG5lc2RheSwgMTEgTWF5IDIwMTYgODo0OCBQTTxicj5Ubzogb2F1dGhAaWV0Zi5v cmc8YnI+U3ViamVjdDogW09BVVRILVdHXSBPQXV0aCAyLjAgZm9yIGJyb2FkY2FzdGVyczwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD5IaSBhbGwsPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5FbmQgb2YgQXByaWwg SSBoYWQgdGhlIGNoYW5jZSB0byB0YWxrIHRvIE1pY2hhZWwgQmFycm9jbyAoZnJvbSB0aGUgRXVy b3BlYW4gQnJvYWRjYXN0aW5nIFVuaW9uKSBhbmQgdG8gQ2hyaXMgTmVlZGhhbSAoZnJvbSB0aGUg QkJDKSByZWdhcmRpbmcgdGhlaXIgdXNlIG9mIE9BdXRoIDIuMCBmb3IgYnJvYWRjYXN0ZXJzLjxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+SW4gTWFyY2ggTWljaGFlbCBkcm9wcGVkIGEgbWFpbCB0byB0 aGUgT0F1dGggbWFpbGluZyBsaXN0IHRvIG1ha2UgdXMgYXdhcmUgb2YgdGhlaXIgd29yaywgc2Vl IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3Vy cmVudC9tc2cxNTk2OS5odG1sIj48c3BhbiBzdHlsZT0nY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0 aC9jdXJyZW50L21zZzE1OTY5Lmh0bWw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+ VGhlIHNwZWNpZmljYXRpb24gdGhleSBhcmUgd29ya2luZyBvbiBpcyBiYXNlZCBvbiB0aGUgT0F1 dGggRGV2aWNlIGZsb3cuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5NaWNoYWVsIGFuZCBDaHJpcyB3 YWxrZWQgbWUgdGhyb3VnaCBhIHNsaWRlIGRlY2sgb2ZmZXJpbmcgbWUgbW9yZSBiYWNrZ3JvdW5k IHJlZ2FyZGluZyB0aGVpciB3b3JrLiAoSSB3aWxsIHVwbG9hZCB0aGUgc2xpZGUgZGVjayB0byBv dXIgV2lraSBidXQgdGhlIElFVEYgbWVldGluZyBzaXRlIHNlZW1zIHRvIGJlIGRvd24gYXQgdGhl IG1vbWVudC4pPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5JbiBhZGRpdGlvbiB0byB0aGUgc3BlY2lm aWNhdGlvbiBjb2RlIGFuZCB0dXRvcmlhbHMgaGF2ZSBiZWVuIGRldmVsb3BlZCBhbmQgeW91IGNh biBmaW5kIHRoZW0gaGVyZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PGEg aHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2VidS9jcGEtdHV0b3JpYWwiPjxzcGFuIHN0eWxlPSdj b2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lJz5odHRwczovL2dpdGh1Yi5jb20v ZWJ1L2NwYS10dXRvcmlhbDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxh aW5UZXh0PjxhIGhyZWY9Imh0dHBzOi8vdGVjaC5lYnUuY2gvY29kZSI+PHNwYW4gc3R5bGU9J2Nv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUnPmh0dHBzOi8vdGVjaC5lYnUuY2gv Y29kZTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5JIGdhdmUgQ2hyaXMgJmFtcDsg TWljaGFlbCBhbiB1cGRhdGUgb2Ygd2hhdCB3ZSBhcmUgZG9pbmcgaW4gdGhlIE9BdXRoIHdvcmtp bmcgZ3JvdXAgc2luY2UgSSBiZWxpZXZlIHNvbWUgb2Ygb3VyIGN1cnJlbnRseSBjaGFydGVyZWQg aXRlbXMgY291bGQgYmUgcmVsZXZhbnQgZm9yIHRoZW0sIHN1Y2ggYXMgdGhlIG5hdGl2ZSBhcHBz IEJDUCBvciB0aGUgUG9QL1Rva2VuIEJpbmRpbmcgd29yay4gSSBhbHNvIG1lbnRpb25lZCB0aGF0 IHdlIGFyZSBsb29raW5nIGZvciBmZWVkYmFjayBmcm9tIHRoZWlyIGdyb3VwIG9uIHRoZSBEZXZp Y2UgRmxvdyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+Q2lhbzxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD5IYW5uZXM8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29QbGFpblRleHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkZyb206ICZxdW90 O0JhcnJvY28sIE1pY2hhZWwmcXVvdDsgJmx0O2JhcnJvY28gYXQgZWJ1LmNoJmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz5UbzogJnF1b3Q7b2F1dGggYXQgaWV0Zi5vcmcmcXVvdDsgJmx0O29hdXRoIGF0IGlldGYu b3JnJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4g c3R5bGU9J2NvbG9yOmJsYWNrJz5DYzogJnF1b3Q7dHZwLWNwYSBhdCBsaXN0LmVidS5jaCZxdW90 OyAmbHQ7dHZwLWNwYSBhdCBsaXN0LmVidS5jaCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+RGF0ZTogTW9uLCA3 IE1hciAyMDE2IDA4OjQzOjU2ICswMDAwPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkRlYXIgYWxsLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPldlIGFyZSBjb250YWN0aW5n IHlvdSBiZWNhdXNlIHdlIG5vdGljZWQgdGhhdCB5b3UgcmVjZW50bHkgcmVzdGFydGVkIHRoZSB3 b3JrIG9uIE9BdXRoIDIuMCBEZXZpY2UgRmxvdy4gV2UgYXJlIGluIHRoZSBwcm9jZXNzIG9mIHB1 Ymxpc2hpbmcgYW4gRVRTSSBzdGFuZGFyZCBbMV0gc3BlY2lmeWluZyBhIHByb3RvY29sIHdpdGgg dmVyeSBzaW1pbGFyIGdvYWxzLiBUaGlzIGhhcyBiZWVuIGRldmVsb3BlZCBieSBhbiBFQlUgKEV1 cm9wZWFuIEJyb2FkY2FzdGluZyBVbmlvbikgd29ya2luZyBncm91cCBpbnZvbHZpbmcgYnJvYWRj YXN0ZXJzLCBzdWNoIGFzIEJCQywgU1JHLVJUUywgVlJULCBSVFZFLCBUVlAsIEdsb2JhbCBSYWRp byBVSywgYW5kIGRldmljZSBtYW51ZmFjdHVyZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48 c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPk91ciB3b3JrIG9uIHRoZSDigJxDcm9zcyBQbGF0Zm9y bSBBdXRoZW50aWNhdGlvbuKAnSBwcm90b2NvbCB0YXJnZXRzIG1lZGlhIGRldmljZXMsIHN1Y2gg YXMgY29ubmVjdGVkIFRWcyBhbmQgcmFkaW8gcmVjZWl2ZXJzLiBJdCBpcyBiYXNlZCBvbiB0aGUg ZWFybHkgT0F1dGggMi4wIERldmljZSBGbG93IGRyYWZ0LCBidXQgaW5jbHVkZXMgYWRkaXRpb25h bCBmZWF0dXJlcyBkcml2ZW4gYnkgYnJvYWRjYXN0IGluZHVzdHJ5IHJlcXVpcmVtZW50cy4gVGhl c2UgaW5jbHVkZTogZHluYW1pYyByZWdpc3RyYXRpb24gb2YgY2xpZW50cywgZHluYW1pYyBkaXNj b3Zlcnkgb2YgdGhlIGF1dGhvcml6YXRpb24gcHJvdmlkZXIsIGFuZCBpc3N1aW5nIG9mIGFjY2Vz cyB0b2tlbnMgd2l0aG91dCByZXF1aXJpbmcgYXNzb2NpYXRpb24gd2l0aCBhIHVzZXIgYWNjb3Vu dCBpbiBvcmRlciB0byBwcm92aWRlIGRldmljZS1iYXNlZCBhdXRoZW50aWNhdGlvbiB0aGF0IGRv ZXMgbm90IHJlcXVpcmUgdXNlciBzaWduLWluIG9yIHBhaXJpbmcuIE91ciBkcmFmdCBwcm90b2Nv bCBzcGVjaWZpY2F0aW9uIGlzIGF2YWlsYWJsZSBoZXJlIFsyXS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFp blRleHQ+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5Dcm9zcyBQbGF0Zm9ybSBBdXRoZW50aWNh dGlvbiBhbHNvIHNwZWNpZmllcyBzZXZlcmFsIGFzcGVjdHMgbGVmdCBvcGVuIHRvIGltcGxlbWVu dGVycyBpbiBPQXV0aCAyLjAsIHN1Y2ggYXMgZW5kcG9pbnQgVVJMIHBhdGhzLCB0byBmYWNpbGl0 YXRlIGludGVyb3BlcmFiaWxpdHkuIEFsc28gbm90ZSB0aGF0IHJlZmVyZW5jZSBpbXBsZW1lbnRh dGlvbnMgYXJlIGF2YWlsYWJsZSBbM10uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+V2Ugd291bGQgYmUgdmVyeSBpbnRlcmVzdGVkIGluIHdvcmtpbmcg dG9nZXRoZXIgd2l0aCB5b3UgdG8gZXhwbGFpbiBvdXIgZGVzaWduIHJlcXVpcmVtZW50cyBhbmQg dHJ5IHRvIGFsaWduIG91ciBwcm90b2NvbCBkZXNpZ25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4 dD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPldpdGggYmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFu IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlRoZSBFQlUgQ3Jvc3MgUGxh dGZvcm0gQXV0aGVudGljYXRpb24gZ3JvdXA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn Pmh0dHBzOi8vdGVjaC5lYnUuY2gvY3BhPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0 eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b1BsYWluVGV4dD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlsxXSBodHRwczovL3BvcnRhbC5l dHNpLm9yZy93ZWJhcHAvV29ya1Byb2dyYW0vUmVwb3J0X1dvcmtJdGVtLmFzcD9XS0lfSUQ9NDc5 NzA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PjxzcGFuIHN0eWxl PSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb1Bs YWluVGV4dD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5bMl0g aHR0cHM6Ly90ZWNoLmVidS5jaC9kb2NzL3RlY2gvdGVjaDMzNjYucGRmPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz5bM10gaHR0cHM6Ly90ZWNoLmVidS5jaC9jb2RlL2NwYTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PHNwYW4gc3R5bGU9J2NvbG9yOmJs YWNrJz4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9i b2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E13BD166320FWSMSG3153Vsrv_-- From nobody Sat May 14 08:37:56 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0BA12D11A for ; Sat, 14 May 2016 08:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.789 X-Spam-Level: X-Spam-Status: No, score=-0.789 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZZAATtDYr2i for ; Sat, 14 May 2016 08:37:52 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10EA127058 for ; Sat, 14 May 2016 08:37:51 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id n63so75568845qkf.0 for ; Sat, 14 May 2016 08:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=HYBnCBSV3y/eOZN5AbNNhvEH45GfhMGTAuS3mYYOJ7Y=; b=KWx5dEh+uPp7RI0+7WRn+13nxku3J+2aAZRZdUCp+Du/ylLjkY9t+RLMuQHWSTN+0p UEqzgjmZADV1+6Mcr3iR42Lb/d1l1dHBJgSMikUP+3S48pWzpl7SAlCAoxDQiRH++R+s 6LkSdNCGIZ7k/nBQdy5uhfMSGHh3dwbALyDydYf0TBqEMkR6hDA78eSnGCwloR6DHlVK APfOONCu220R7kkhnzC/U+fesLrXJKaZDKmANWPrwPFpqJG4Unn17NYPEqwvKu/+/QX8 Qy1Co7BeuUDOETGwmo/3EEmvJHnrdT9QZmPPeo/kPnMN/qvCradpbE/4wrSuxSEvRMPM KOEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HYBnCBSV3y/eOZN5AbNNhvEH45GfhMGTAuS3mYYOJ7Y=; b=lm1aWeSk4bRp+E0IoJ5gQdxPXm8Zg9LHosZs4U8h9fRmWr0BWfxrDJ/pO/1B+r7RIZ Mmw3TW2BhVQsIPt89YjCEtUs50kwrL/IoTDG8m0bYWIGFHqyZ0/ixtunOlAtRLj2UFOB RH+/NCmXBdA6PNIUYadnwQupUzKI6LnvphaqD3UzD+1rOVYRlMcPTBhN0vOaHsvkNOf2 H0Ou6MWJIVOB5tiCCswO4Pr2uDfgnYSN+t7EKqf3srBruEO1i7KmX0WVPvDeDH2PJZ81 PTTem5kI7awpYndLkjVbZo0q46puu6HOlr5IMharSXHixz91j0sPelKH3WnShunpRYTv tJBw== X-Gm-Message-State: AOPr4FVLtywPz+UpWnN10M7n24KJz2vwLjSHhSst81UbvfmnIv9j+96qit/2gSGchE5zVOyZ5S8K+XRzdvOFpA== X-Received: by 10.55.74.9 with SMTP id x9mr21514557qka.81.1463240270973; Sat, 14 May 2016 08:37:50 -0700 (PDT) MIME-Version: 1.0 References: <255B9BB34FB7D647A506DC292726F6E13BD166320F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BD166320F@WSMSG3153V.srv.dir.telstra.com> From: Nat Sakimura Date: Sat, 14 May 2016 15:37:41 +0000 Message-ID: To: "Manger, James" , Hannes Tschofenig , "oauth@ietf.org" , "barroco@ebu.ch" Content-Type: multipart/alternative; boundary=001a11488a7892b79b0532cf2c55 Archived-At: Subject: Re: [OAUTH-WG] Cross Platform Authentication - OAuth 2.0 Device Flow - WWW-Authenticate to advertise OAuth 2.0 support X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 15:37:54 -0000 --001a11488a7892b79b0532cf2c55 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James, Does not the section 3 of RFC6750 talk about it? If you are talking about uri parameter that represents the AS, then, yes, I think it is a good idea to have one, though IMHO it is better to be returned in a link header. Best, Nat On Fri, May 13, 2016 at 04:04 Manger, James wrote: > Hi Michael & OAuth-ers, > > > > The EBU Cross Platform Auth spec has defined their own "CPA" scheme for > the WWW-Authenticate HTTP response header to advertise OAuth 2.0 capabili= ty > [section 7.7.1 "Authentication challenge" in > https://tech.ebu.ch/docs/tech/tech3366.pdf]. > > > > WWW-Authenticate: CPA version=3D"1.0" > > name=3D"Example Authorization Provider" > > uri=3D"https://ap.example.com/cpa" > > modes=3D"client,user" > > > > It is a shame that there isn=E2=80=99t a standard OAuth way to do this wi= thout > needing a CPA-specific scheme. > > > > P.S. This CPA example is invalid. It needs commas between attributes [ > https://tools.ietf.org/html/rfc7235#appendix-C]. > > > > -- > > James Manger > > > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g > Sent: Wednesday, 11 May 2016 8:48 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] OAuth 2.0 for broadcasters > > > > Hi all, > > > > End of April I had the chance to talk to Michael Barroco (from the > European Broadcasting Union) and to Chris Needham (from the BBC) regardin= g > their use of OAuth 2.0 for broadcasters. > > > > In March Michael dropped a mail to the OAuth mailing list to make us awar= e > of their work, see > https://www.ietf.org/mail-archive/web/oauth/current/msg15969.html > > > > The specification they are working on is based on the OAuth Device flow. > > > > Michael and Chris walked me through a slide deck offering me more > background regarding their work. (I will upload the slide deck to our Wik= i > but the IETF meeting site seems to be down at the moment.) > > > > In addition to the specification code and tutorials have been developed > and you can find them here: > > https://github.com/ebu/cpa-tutorial > > https://tech.ebu.ch/code > > > > I gave Chris & Michael an update of what we are doing in the OAuth workin= g > group since I believe some of our currently chartered items could be > relevant for them, such as the native apps BCP or the PoP/Token Binding > work. I also mentioned that we are looking for feedback from their group = on > the Device Flow specification. > > > > Ciao > > Hannes > > > > > > From: "Barroco, Michael" > > To: "oauth at ietf.org" > > Cc: "tvp-cpa at list.ebu.ch" > > Date: Mon, 7 Mar 2016 08:43:56 +0000 > > Dear all, > > > > > > We are contacting you because we noticed that you recently restarted the > work on OAuth 2.0 Device Flow. We are in the process of publishing an ETS= I > standard [1] specifying a protocol with very similar goals. This has been > developed by an EBU (European Broadcasting Union) working group involving > broadcasters, such as BBC, SRG-RTS, VRT, RTVE, TVP, Global Radio UK, and > device manufacturers. > > > > > > Our work on the =E2=80=9CCross Platform Authentication=E2=80=9D protocol = targets media > devices, such as connected TVs and radio receivers. It is based on the > early OAuth 2.0 Device Flow draft, but includes additional features drive= n > by broadcast industry requirements. These include: dynamic registration o= f > clients, dynamic discovery of the authorization provider, and issuing of > access tokens without requiring association with a user account in order = to > provide device-based authentication that does not require user sign-in or > pairing. Our draft protocol specification is available here [2]. > > > > > > Cross Platform Authentication also specifies several aspects left open to > implementers in OAuth 2.0, such as endpoint URL paths, to facilitate > interoperability. Also note that reference implementations are available > [3]. > > > > > > We would be very interested in working together with you to explain our > design requirements and try to align our protocol designs. > > > > > > With best regards, > > > > > > The EBU Cross Platform Authentication group > > > > https://tech.ebu.ch/cpa > > > > > > > > [1] > https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=3D4= 7970 > > > > > > [2] https://tech.ebu.ch/docs/tech/tech3366.pdf > > > > [3] https://tech.ebu.ch/code/cpa > > > -------------------------------------------------------------------------= ----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura Chairman of the Board, OpenID Foundation Trustee, Kantara Initiative --001a11488a7892b79b0532cf2c55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi James,

    Does not the section 3 of RFC6750 talk about it?

    = If you are talking about uri parameter that represents the AS, then, yes, I= think it is a good idea to have one, though IMHO it is better to be return= ed in a link header.

    Best,

    Nat
    On Fri, May 13, 2016 at 04:04 Manger, James <James.H.Manger@team.telstra.com= > wrote:

    Hi Michael & OAuth-ers,<= /u>

    =C2=A0

    The EBU Cross Platform Auth spe= c has defined their own "CPA" scheme for the WWW-Authenticate HTT= P response header to advertise OAuth 2.0 capability [section 7.7.1 "Au= thentication challenge" in https://tech.ebu.ch/docs/tech/tech3366.pdf].

    =C2=A0

    WWW-Authenticate: CPA version=3D"1.0"<= /span>

    =C2=A0name=3D"Examp= le Authorization Provider"

    =C2=A0uri=3D"https://ap.example.com/cpa"

    =C2=A0modes=3D"client= ,user"

    =C2=A0

    It is a s= hame that there isn=E2=80=99t a standard OAuth way to do this without needi= ng a CPA-specific scheme.

    =C2=A0

    P.= S. This CPA example is invalid. It needs commas between attributes [https= ://tools.ietf.org/html/rfc7235#appendix-C].

    = =C2=A0

    --

    James Manger

    =C2=A0

    -----Original Message-----=
    From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
    Sent= : Wednesday, 11 May 2016 8:48 PM
    To: oauth@ietf.org
    Subject: [OAUTH-WG] OAuth 2.0 for br= oadcasters

    =C2=A0

    Hi all,

    =C2=A0

    End of April I had the chance to talk to Mic= hael Barroco (from the European Broadcasting Union) and to Chris Needham (f= rom the BBC) regarding their use of OAuth 2.0 for broadcasters.

    =C2=A0

    In March Michael dropped a mail to the = OAuth mailing list to make us aware of their work, see https://www.ietf.org= /mail-archive/web/oauth/current/msg15969.html

    <= p>=C2=A0

    The specification they are working on is based= on the OAuth Device flow.

    =C2=A0

    M= ichael and Chris walked me through a slide deck offering me more background= regarding their work. (I will upload the slide deck to our Wiki but the IE= TF meeting site seems to be down at the moment.)

    =C2=A0

    In addition to the specification code and tutorials ha= ve been developed and you can find them here:

    https://github.com/ebu/cpa-tutorial

    https://t= ech.ebu.ch/code

    =C2=A0

    I= gave Chris & Michael an update of what we are doing in the OAuth worki= ng group since I believe some of our currently chartered items could be rel= evant for them, such as the native apps BCP or the PoP/Token Binding work. = I also mentioned that we are looking for feedback from their group on the D= evice Flow specification.

    =C2=A0

    Ci= ao

    Hannes

    =C2=A0

    <= p>=C2=A0

    From: "Barroco, Michael" <barroco at ebu.ch>

    To: "oauth at ietf.org" <oauth at ietf.org>

    Cc: "tvp-cpa at list.ebu.ch" <tvp-cpa at list.ebu.ch>

    = Date: Mon, 7 Mar 2016 08:43:56 +0000<= /u>

    Dear all,=

    =C2=A0

    =C2=A0

    We are contacting you because we noticed that you recently restart= ed the work on OAuth 2.0 Device Flow. We are in the process of publishing a= n ETSI standard [1] specifying a protocol with very similar goals. This has= been developed by an EBU (European Broadcasting Union) working group invol= ving broadcasters, such as BBC, SRG-RTS, VRT, RTVE, TVP, Global Radio UK, a= nd device manufacturers.

    =C2=A0

    = =C2=A0

    Our work on the =E2= =80=9CCross Platform Authentication=E2=80=9D protocol targets media devices= , such as connected TVs and radio receivers. It is based on the early OAuth= 2.0 Device Flow draft, but includes additional features driven by broadcas= t industry requirements. These include: dynamic registration of clients, dy= namic discovery of the authorization provider, and issuing of access tokens= without requiring association with a user account in order to provide devi= ce-based authentication that does not require user sign-in or pairing. Our = draft protocol specification is available here [2].

    =C2=A0

    =C2=A0

    Cross Platform Authentication also specifies several aspects left ope= n to implementers in OAuth 2.0, such as endpoint URL paths, to facilitate i= nteroperability. Also note that reference implementations are available [3]= .

    =C2=A0

    =C2=A0

    =

    We would be very interested in working toget= her with you to explain our design requirements and try to align our protoc= ol designs.

    = =C2=A0

    =C2=A0=

    With best regards,<= /span>

    =C2=A0

    = =C2=A0

    The EBU Cross Platform Authentication group<= /span>

    =C2=A0

    = https://tech.ebu.ch/cpa

    =C2=A0

    =C2=A0

    = =C2=A0

    [1] https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem= .asp?WKI_ID=3D47970

    =C2=A0

    = =C2=A0

    [2] https://tech.ebu.c= h/docs/tech/tech3366.pdf

    =C2=A0

    [3] = https://tech.ebu= .ch/code/cpa

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

    ______________________________________= _________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --
    Nat Sakimura
    Chairma= n of the Board, OpenID Foundation
    Trustee, Kantara Initiative
    --001a11488a7892b79b0532cf2c55-- From nobody Sun May 15 18:06:37 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1A412B026 for ; Sun, 15 May 2016 18:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 7eTBYZMT0260 for ; Sun, 15 May 2016 18:06:32 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD8112B01F for ; Sun, 15 May 2016 18:06:31 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.24,625,1454936400"; d="scan'208,217"; a="78751045" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 16 May 2016 11:05:59 +1000 X-IronPort-AV: E=McAfee;i="5700,7163,8166"; a="148187809" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcbvi.tcif.telstra.com.au with ESMTP; 16 May 2016 11:05:59 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3707.srv.dir.telstra.com ([fe80::ccc:aa8f:d2a6:740%28]) with mapi; Mon, 16 May 2016 11:05:58 +1000 From: "Manger, James" To: Nat Sakimura , Hannes Tschofenig , "oauth@ietf.org" , "barroco@ebu.ch" Date: Mon, 16 May 2016 11:05:18 +1000 Thread-Topic: [OAUTH-WG] Cross Platform Authentication - OAuth 2.0 Device Flow - WWW-Authenticate to advertise OAuth 2.0 support Thread-Index: AdGt9pX5Sla7uEe6TK6QOtWWgclRWQBFLJEQ Message-ID: <255B9BB34FB7D647A506DC292726F6E13BD1663C5F@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E13BD166320F@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BD1663C5FWSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Cross Platform Authentication - OAuth 2.0 Device Flow - WWW-Authenticate to advertise OAuth 2.0 support X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 01:06:35 -0000 --_000_255B9BB34FB7D647A506DC292726F6E13BD1663C5FWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmF0LA0KDQpSRkM2NzUwIOKAnE9BdXRoIDIuMCBCZWFyZXIgVG9rZW4gVXNhZ2XigJ0gc2Vj dGlvbiAzIOKAnFRoZSBXV1ctQXV0aGVudGljYXRlIFJlc3BvbnNlIEhlYWRlciBGaWVsZOKAnSBp cyBhIHN0YXJ0LCBidXQgaXQgaXNu4oCZdCByZWFsbHkgc3VpdGFibGUuIEZpcnN0bHksIGl0IGlz IGEgQmVhcmVyLXNwZWNpZmljLCB3aGVyZWFzIHdlIG5lZWQgaXMgYSB3YXkgdG8gc2F5IOKAnE9B dXRoIDIuMCBpcyBhdmFpbGFibGXigJ0gcmVnYXJkbGVzcyBvZiB0aGUgdHlwZSBvZiB0ZW1wb3Jh cnkgY3JlZGVudGlhbHMgdGhhdCBnZXQgaXNzdWVkLiBJdCBkb2VzbuKAmXQgaW5jbHVkZSBwb2lu dGVycyB0byBoZSBBUywgd2hpY2ggQ1BBIHByZXN1bWFibHkgcmVxdWlyZSBhcyB0aGVpciBleGFt cGxlIGluY2x1ZGVzIHRoaXMgKEkgZ3Vlc3MgYSBsaW5rIGhlYWRlciBjYW4gd29yaywgdGhvdWdo IGluY2x1ZGluZyBhdXRoLXNwZWNpZmljIGluZm8gaW4gYSBkZWRpY2F0ZWQgYXV0aC0gaGVhZGVy IHdoZW4gYXV0aCBpcyByZXF1aXJlZCBidXQgbWlzc2luZyBzb3VuZHMgbGlrZSBhIGRlY2VudCBm aXQpLg0KDQpDdXJpb3VzbHksIDEgb2YgdGhlIDIgZXhhbXBsZSBzY29wZSB2YWx1ZXMgbWVudGlv bmVkIGluIFJGQzY3NTAgc2VjdGlvbiAzIGZvciB0aGUgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIg aGFzIOKAnG9wZW5pZOKAnSwgYnV0IHRoaXMgaXMgdGhlIG9uZSB2YWx1ZXMgdGhhdCB3aWxsIG5l dmVyIGJlIHVzZWZ1bCB0aGVyZS4gc2NvcGU9b3BlbmlkIG1lYW5zIHRoZSBjbGllbnQgYXBwIHdh bnRzIGFuIGlkLXRva2VuOyBpdCBpcyBwb2ludGxlc3MgZm9yIGEgcHJvdGVjdGVkIHJlc291cmNl ICh3aGljaCBpcyB0aGUgcGFydHkgcmV0dXJuaW5nIFdXVy1BdXRoZW50aWNhdGUpIHRvIGFzayBm b3IgaXQuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KDQpGcm9tOiBOYXQgU2FraW11cmEgW21haWx0 bzpzYWtpbXVyYUBnbWFpbC5jb21dDQpTZW50OiBTdW5kYXksIDE1IE1heSAyMDE2IDE6MzggQU0N ClRvOiBNYW5nZXIsIEphbWVzIDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPjsgSGFu bmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+OyBvYXV0aEBpZXRmLm9y ZzsgYmFycm9jb0BlYnUuY2gNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENyb3NzIFBsYXRmb3Jt IEF1dGhlbnRpY2F0aW9uIC0gT0F1dGggMi4wIERldmljZSBGbG93IC0gV1dXLUF1dGhlbnRpY2F0 ZSB0byBhZHZlcnRpc2UgT0F1dGggMi4wIHN1cHBvcnQNCg0KSGkgSmFtZXMsDQoNCkRvZXMgbm90 IHRoZSBzZWN0aW9uIDMgb2YgUkZDNjc1MCB0YWxrIGFib3V0IGl0Pw0KDQpJZiB5b3UgYXJlIHRh bGtpbmcgYWJvdXQgdXJpIHBhcmFtZXRlciB0aGF0IHJlcHJlc2VudHMgdGhlIEFTLCB0aGVuLCB5 ZXMsIEkgdGhpbmsgaXQgaXMgYSBnb29kIGlkZWEgdG8gaGF2ZSBvbmUsIHRob3VnaCBJTUhPIGl0 IGlzIGJldHRlciB0byBiZSByZXR1cm5lZCBpbiBhIGxpbmsgaGVhZGVyLg0KDQpCZXN0LA0KDQpO YXQNCk9uIEZyaSwgTWF5IDEzLCAyMDE2IGF0IDA0OjA0IE1hbmdlciwgSmFtZXMgPEphbWVzLkgu TWFuZ2VyQHRlYW0udGVsc3RyYS5jb208bWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3Ry YS5jb20+PiB3cm90ZToNCg0KSGkgTWljaGFlbCAmIE9BdXRoLWVycywNCg0KDQoNClRoZSBFQlUg Q3Jvc3MgUGxhdGZvcm0gQXV0aCBzcGVjIGhhcyBkZWZpbmVkIHRoZWlyIG93biAiQ1BBIiBzY2hl bWUgZm9yIHRoZSBXV1ctQXV0aGVudGljYXRlIEhUVFAgcmVzcG9uc2UgaGVhZGVyIHRvIGFkdmVy dGlzZSBPQXV0aCAyLjAgY2FwYWJpbGl0eSBbc2VjdGlvbiA3LjcuMSAiQXV0aGVudGljYXRpb24g Y2hhbGxlbmdlIiBpbiBodHRwczovL3RlY2guZWJ1LmNoL2RvY3MvdGVjaC90ZWNoMzM2Ni5wZGZd Lg0KDQoNCg0KV1dXLUF1dGhlbnRpY2F0ZTogQ1BBIHZlcnNpb249IjEuMCINCg0KIG5hbWU9IkV4 YW1wbGUgQXV0aG9yaXphdGlvbiBQcm92aWRlciINCg0KIHVyaT0iaHR0cHM6Ly9hcC5leGFtcGxl LmNvbS9jcGEiDQoNCiBtb2Rlcz0iY2xpZW50LHVzZXIiDQoNCg0KDQpJdCBpcyBhIHNoYW1lIHRo YXQgdGhlcmUgaXNu4oCZdCBhIHN0YW5kYXJkIE9BdXRoIHdheSB0byBkbyB0aGlzIHdpdGhvdXQg bmVlZGluZyBhIENQQS1zcGVjaWZpYyBzY2hlbWUuDQoNCg0KDQpQLlMuIFRoaXMgQ1BBIGV4YW1w bGUgaXMgaW52YWxpZC4gSXQgbmVlZHMgY29tbWFzIGJldHdlZW4gYXR0cmlidXRlcyBbaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMzUjYXBwZW5kaXgtQ10uDQoNCg0KDQotLQ0KDQpK YW1lcyBNYW5nZXINCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0 aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWcNClNlbnQ6IFdlZG5lc2RheSwg MTEgTWF5IDIwMTYgODo0OCBQTQ0KVG86IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRm Lm9yZz4NClN1YmplY3Q6IFtPQVVUSC1XR10gT0F1dGggMi4wIGZvciBicm9hZGNhc3RlcnMNCg0K DQoNCkhpIGFsbCwNCg0KDQoNCkVuZCBvZiBBcHJpbCBJIGhhZCB0aGUgY2hhbmNlIHRvIHRhbGsg dG8gTWljaGFlbCBCYXJyb2NvIChmcm9tIHRoZSBFdXJvcGVhbiBCcm9hZGNhc3RpbmcgVW5pb24p IGFuZCB0byBDaHJpcyBOZWVkaGFtIChmcm9tIHRoZSBCQkMpIHJlZ2FyZGluZyB0aGVpciB1c2Ug b2YgT0F1dGggMi4wIGZvciBicm9hZGNhc3RlcnMuDQoNCg0KDQpJbiBNYXJjaCBNaWNoYWVsIGRy b3BwZWQgYSBtYWlsIHRvIHRoZSBPQXV0aCBtYWlsaW5nIGxpc3QgdG8gbWFrZSB1cyBhd2FyZSBv ZiB0aGVpciB3b3JrLCBzZWUgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9v YXV0aC9jdXJyZW50L21zZzE1OTY5Lmh0bWwNCg0KDQoNClRoZSBzcGVjaWZpY2F0aW9uIHRoZXkg YXJlIHdvcmtpbmcgb24gaXMgYmFzZWQgb24gdGhlIE9BdXRoIERldmljZSBmbG93Lg0KDQoNCg0K TWljaGFlbCBhbmQgQ2hyaXMgd2Fsa2VkIG1lIHRocm91Z2ggYSBzbGlkZSBkZWNrIG9mZmVyaW5n IG1lIG1vcmUgYmFja2dyb3VuZCByZWdhcmRpbmcgdGhlaXIgd29yay4gKEkgd2lsbCB1cGxvYWQg dGhlIHNsaWRlIGRlY2sgdG8gb3VyIFdpa2kgYnV0IHRoZSBJRVRGIG1lZXRpbmcgc2l0ZSBzZWVt cyB0byBiZSBkb3duIGF0IHRoZSBtb21lbnQuKQ0KDQoNCg0KSW4gYWRkaXRpb24gdG8gdGhlIHNw ZWNpZmljYXRpb24gY29kZSBhbmQgdHV0b3JpYWxzIGhhdmUgYmVlbiBkZXZlbG9wZWQgYW5kIHlv dSBjYW4gZmluZCB0aGVtIGhlcmU6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9lYnUvY3BhLXR1dG9y aWFsDQoNCmh0dHBzOi8vdGVjaC5lYnUuY2gvY29kZQ0KDQoNCg0KSSBnYXZlIENocmlzICYgTWlj aGFlbCBhbiB1cGRhdGUgb2Ygd2hhdCB3ZSBhcmUgZG9pbmcgaW4gdGhlIE9BdXRoIHdvcmtpbmcg Z3JvdXAgc2luY2UgSSBiZWxpZXZlIHNvbWUgb2Ygb3VyIGN1cnJlbnRseSBjaGFydGVyZWQgaXRl bXMgY291bGQgYmUgcmVsZXZhbnQgZm9yIHRoZW0sIHN1Y2ggYXMgdGhlIG5hdGl2ZSBhcHBzIEJD UCBvciB0aGUgUG9QL1Rva2VuIEJpbmRpbmcgd29yay4gSSBhbHNvIG1lbnRpb25lZCB0aGF0IHdl IGFyZSBsb29raW5nIGZvciBmZWVkYmFjayBmcm9tIHRoZWlyIGdyb3VwIG9uIHRoZSBEZXZpY2Ug RmxvdyBzcGVjaWZpY2F0aW9uLg0KDQoNCg0KQ2lhbw0KDQpIYW5uZXMNCg0KDQoNCg0KDQpGcm9t OiAiQmFycm9jbywgTWljaGFlbCIgPGJhcnJvY28gYXQgZWJ1LmNoPGh0dHA6Ly9lYnUuY2g+Pg0K DQpUbzogIm9hdXRoIGF0IGlldGYub3JnPGh0dHA6Ly9pZXRmLm9yZz4iIDxvYXV0aCBhdCBpZXRm Lm9yZzxodHRwOi8vaWV0Zi5vcmc+Pg0KDQpDYzogInR2cC1jcGEgYXQgbGlzdC5lYnUuY2g8aHR0 cDovL2xpc3QuZWJ1LmNoPiIgPHR2cC1jcGEgYXQgbGlzdC5lYnUuY2g8aHR0cDovL2xpc3QuZWJ1 LmNoPj4NCg0KRGF0ZTogTW9uLCA3IE1hciAyMDE2IDA4OjQzOjU2ICswMDAwDQoNCkRlYXIgYWxs LA0KDQoNCg0KDQoNCldlIGFyZSBjb250YWN0aW5nIHlvdSBiZWNhdXNlIHdlIG5vdGljZWQgdGhh dCB5b3UgcmVjZW50bHkgcmVzdGFydGVkIHRoZSB3b3JrIG9uIE9BdXRoIDIuMCBEZXZpY2UgRmxv dy4gV2UgYXJlIGluIHRoZSBwcm9jZXNzIG9mIHB1Ymxpc2hpbmcgYW4gRVRTSSBzdGFuZGFyZCBb MV0gc3BlY2lmeWluZyBhIHByb3RvY29sIHdpdGggdmVyeSBzaW1pbGFyIGdvYWxzLiBUaGlzIGhh cyBiZWVuIGRldmVsb3BlZCBieSBhbiBFQlUgKEV1cm9wZWFuIEJyb2FkY2FzdGluZyBVbmlvbikg d29ya2luZyBncm91cCBpbnZvbHZpbmcgYnJvYWRjYXN0ZXJzLCBzdWNoIGFzIEJCQywgU1JHLVJU UywgVlJULCBSVFZFLCBUVlAsIEdsb2JhbCBSYWRpbyBVSywgYW5kIGRldmljZSBtYW51ZmFjdHVy ZXJzLg0KDQoNCg0KDQoNCk91ciB3b3JrIG9uIHRoZSDigJxDcm9zcyBQbGF0Zm9ybSBBdXRoZW50 aWNhdGlvbuKAnSBwcm90b2NvbCB0YXJnZXRzIG1lZGlhIGRldmljZXMsIHN1Y2ggYXMgY29ubmVj dGVkIFRWcyBhbmQgcmFkaW8gcmVjZWl2ZXJzLiBJdCBpcyBiYXNlZCBvbiB0aGUgZWFybHkgT0F1 dGggMi4wIERldmljZSBGbG93IGRyYWZ0LCBidXQgaW5jbHVkZXMgYWRkaXRpb25hbCBmZWF0dXJl cyBkcml2ZW4gYnkgYnJvYWRjYXN0IGluZHVzdHJ5IHJlcXVpcmVtZW50cy4gVGhlc2UgaW5jbHVk ZTogZHluYW1pYyByZWdpc3RyYXRpb24gb2YgY2xpZW50cywgZHluYW1pYyBkaXNjb3Zlcnkgb2Yg dGhlIGF1dGhvcml6YXRpb24gcHJvdmlkZXIsIGFuZCBpc3N1aW5nIG9mIGFjY2VzcyB0b2tlbnMg d2l0aG91dCByZXF1aXJpbmcgYXNzb2NpYXRpb24gd2l0aCBhIHVzZXIgYWNjb3VudCBpbiBvcmRl ciB0byBwcm92aWRlIGRldmljZS1iYXNlZCBhdXRoZW50aWNhdGlvbiB0aGF0IGRvZXMgbm90IHJl cXVpcmUgdXNlciBzaWduLWluIG9yIHBhaXJpbmcuIE91ciBkcmFmdCBwcm90b2NvbCBzcGVjaWZp Y2F0aW9uIGlzIGF2YWlsYWJsZSBoZXJlIFsyXS4NCg0KDQoNCg0KDQpDcm9zcyBQbGF0Zm9ybSBB dXRoZW50aWNhdGlvbiBhbHNvIHNwZWNpZmllcyBzZXZlcmFsIGFzcGVjdHMgbGVmdCBvcGVuIHRv IGltcGxlbWVudGVycyBpbiBPQXV0aCAyLjAsIHN1Y2ggYXMgZW5kcG9pbnQgVVJMIHBhdGhzLCB0 byBmYWNpbGl0YXRlIGludGVyb3BlcmFiaWxpdHkuIEFsc28gbm90ZSB0aGF0IHJlZmVyZW5jZSBp bXBsZW1lbnRhdGlvbnMgYXJlIGF2YWlsYWJsZSBbM10uDQoNCg0KDQoNCg0KV2Ugd291bGQgYmUg dmVyeSBpbnRlcmVzdGVkIGluIHdvcmtpbmcgdG9nZXRoZXIgd2l0aCB5b3UgdG8gZXhwbGFpbiBv dXIgZGVzaWduIHJlcXVpcmVtZW50cyBhbmQgdHJ5IHRvIGFsaWduIG91ciBwcm90b2NvbCBkZXNp Z25zLg0KDQoNCg0KDQoNCldpdGggYmVzdCByZWdhcmRzLA0KDQoNCg0KDQoNClRoZSBFQlUgQ3Jv c3MgUGxhdGZvcm0gQXV0aGVudGljYXRpb24gZ3JvdXANCg0KDQoNCmh0dHBzOi8vdGVjaC5lYnUu Y2gvY3BhDQoNCg0KDQoNCg0KDQoNClsxXSBodHRwczovL3BvcnRhbC5ldHNpLm9yZy93ZWJhcHAv V29ya1Byb2dyYW0vUmVwb3J0X1dvcmtJdGVtLmFzcD9XS0lfSUQ9NDc5NzANCg0KDQoNCg0KDQpb Ml0gaHR0cHM6Ly90ZWNoLmVidS5jaC9kb2NzL3RlY2gvdGVjaDMzNjYucGRmDQoNCg0KDQpbM10g aHR0cHM6Ly90ZWNoLmVidS5jaC9jb2RlL2NwYQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCi0tDQpOYXQgU2FraW11cmENCkNo YWlybWFuIG9mIHRoZSBCb2FyZCwgT3BlbklEIEZvdW5kYXRpb24NClRydXN0ZWUsIEthbnRhcmEg SW5pdGlhdGl2ZQ0K --_000_255B9BB34FB7D647A506DC292726F6E13BD1663C5FWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQg NzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xh c3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz5IaSBOYXQsIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz5SRkM2NzUwIOKA nE9BdXRoIDIuMCBCZWFyZXIgVG9rZW4gVXNhZ2XigJ0gc2VjdGlvbiAzIOKAnFRoZSBXV1ctQXV0 aGVudGljYXRlIFJlc3BvbnNlIEhlYWRlciBGaWVsZOKAnSBpcyBhIHN0YXJ0LCBidXQgaXQgaXNu 4oCZdCByZWFsbHkgc3VpdGFibGUuIEZpcnN0bHksIGl0IGlzIGEgQmVhcmVyLXNwZWNpZmljLCB3 aGVyZWFzIHdlIG5lZWQgaXMgYSB3YXkgdG8gc2F5IOKAnE9BdXRoIDIuMCBpcyBhdmFpbGFibGXi gJ0gcmVnYXJkbGVzcyBvZiB0aGUgdHlwZSBvZiB0ZW1wb3JhcnkgY3JlZGVudGlhbHMgdGhhdCBn ZXQgaXNzdWVkLiBJdCBkb2VzbuKAmXQgaW5jbHVkZSBwb2ludGVycyB0byBoZSBBUywgd2hpY2gg Q1BBIHByZXN1bWFibHkgcmVxdWlyZSBhcyB0aGVpciBleGFtcGxlIGluY2x1ZGVzIHRoaXMgKEkg Z3Vlc3MgYSBsaW5rIGhlYWRlciBjYW4gd29yaywgdGhvdWdoIGluY2x1ZGluZyBhdXRoLXNwZWNp ZmljIGluZm8gaW4gYSBkZWRpY2F0ZWQgYXV0aC0gaGVhZGVyIHdoZW4gYXV0aCBpcyByZXF1aXJl ZCBidXQgbWlzc2luZyBzb3VuZHMgbGlrZSBhIGRlY2VudCBmaXQpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz5DdXJp b3VzbHksIDEgb2YgdGhlIDIgZXhhbXBsZSBzY29wZSB2YWx1ZXMgbWVudGlvbmVkIGluIFJGQzY3 NTAgc2VjdGlvbiAzIGZvciB0aGUgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIgaGFzIOKAnG9wZW5p ZOKAnSwgYnV0IHRoaXMgaXMgdGhlIG9uZSB2YWx1ZXMgdGhhdCB3aWxsIG5ldmVyIGJlIHVzZWZ1 bCB0aGVyZS4gc2NvcGU9b3BlbmlkIG1lYW5zIHRoZSBjbGllbnQgYXBwIHdhbnRzIGFuIGlkLXRv a2VuOyBpdCBpcyBwb2ludGxlc3MgZm9yIGEgcHJvdGVjdGVkIHJlc291cmNlICh3aGljaCBpcyB0 aGUgcGFydHkgcmV0dXJuaW5nIFdXVy1BdXRoZW50aWNhdGUpIHRvIGFzayBmb3IgaXQuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTJz5KYW1lcyBNYW5nZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZic+IE5h dCBTYWtpbXVyYSBbbWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBT dW5kYXksIDE1IE1heSAyMDE2IDE6MzggQU08YnI+PGI+VG86PC9iPiBNYW5nZXIsIEphbWVzICZs dDtKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tJmd0OzsgSGFubmVzIFRzY2hvZmVuaWcg Jmx0O2hhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQmZ3Q7OyBvYXV0aEBpZXRmLm9yZzsgYmFycm9j b0BlYnUuY2g8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENyb3NzIFBsYXRmb3Jt IEF1dGhlbnRpY2F0aW9uIC0gT0F1dGggMi4wIERldmljZSBGbG93IC0gV1dXLUF1dGhlbnRpY2F0 ZSB0byBhZHZlcnRpc2UgT0F1dGggMi4wIHN1cHBvcnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5I aSBKYW1lcywgPGJyPjxicj5Eb2VzIG5vdCB0aGUgc2VjdGlvbiAzIG9mIFJGQzY3NTAgdGFsayBh Ym91dCBpdD8gPGJyPjxicj5JZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgdXJpIHBhcmFtZXRlciB0 aGF0IHJlcHJlc2VudHMgdGhlIEFTLCB0aGVuLCB5ZXMsIEkgdGhpbmsgaXQgaXMgYSBnb29kIGlk ZWEgdG8gaGF2ZSBvbmUsIHRob3VnaCBJTUhPIGl0IGlzIGJldHRlciB0byBiZSByZXR1cm5lZCBp biBhIGxpbmsgaGVhZGVyLiA8YnI+PGJyPkJlc3QsIDxicj48YnI+TmF0IDxvOnA+PC9vOnA+PC9w PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gRnJpLCBNYXkgMTMsIDIwMTYgYXQgMDQ6 MDQgTWFuZ2VyLCBKYW1lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0u dGVsc3RyYS5jb20iPkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20nPjxkaXY+PGRpdj48cD5IaSBNaWNoYWVs ICZhbXA7IE9BdXRoLWVycyw8bzpwPjwvbzpwPjwvcD48cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48 cD5UaGUgRUJVIENyb3NzIFBsYXRmb3JtIEF1dGggc3BlYyBoYXMgZGVmaW5lZCB0aGVpciBvd24g JnF1b3Q7Q1BBJnF1b3Q7IHNjaGVtZSBmb3IgdGhlIFdXVy1BdXRoZW50aWNhdGUgSFRUUCByZXNw b25zZSBoZWFkZXIgdG8gYWR2ZXJ0aXNlIE9BdXRoIDIuMCBjYXBhYmlsaXR5IFtzZWN0aW9uIDcu Ny4xICZxdW90O0F1dGhlbnRpY2F0aW9uIGNoYWxsZW5nZSZxdW90OyBpbiA8YSBocmVmPSJodHRw czovL3RlY2guZWJ1LmNoL2RvY3MvdGVjaC90ZWNoMzM2Ni5wZGYiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3RlY2guZWJ1LmNoL2RvY3MvdGVjaC90ZWNoMzM2Ni5wZGY8L2E+XS48bzpwPjwvbzpw PjwvcD48cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 Q29uc29sYXMnPldXVy1BdXRoZW50aWNhdGU6IENQQSB2ZXJzaW9uPSZxdW90OzEuMCZxdW90Ozwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6Q29uc29sYXMn PiZuYnNwO25hbWU9JnF1b3Q7RXhhbXBsZSBBdXRob3JpemF0aW9uIFByb3ZpZGVyJnF1b3Q7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpDb25zb2xhcyc+ Jm5ic3A7dXJpPSZxdW90OzxhIGhyZWY9Imh0dHBzOi8vYXAuZXhhbXBsZS5jb20vY3BhIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9hcC5leGFtcGxlLmNvbS9jcGE8L2E+JnF1b3Q7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseTpDb25zb2xhcyc+Jm5ic3A7 bW9kZXM9JnF1b3Q7Y2xpZW50LHVzZXImcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+PHA+Jm5i c3A7PG86cD48L286cD48L3A+PHA+SXQgaXMgYSBzaGFtZSB0aGF0IHRoZXJlIGlzbuKAmXQgYSBz dGFuZGFyZCBPQXV0aCB3YXkgdG8gZG8gdGhpcyB3aXRob3V0IG5lZWRpbmcgYSBDUEEtc3BlY2lm aWMgc2NoZW1lLjxvOnA+PC9vOnA+PC9wPjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwPlAuUy4g VGhpcyBDUEEgZXhhbXBsZSBpcyBpbnZhbGlkLiBJdCBuZWVkcyBjb21tYXMgYmV0d2VlbiBhdHRy aWJ1dGVzIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIzNSNhcHBl bmRpeC1DIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcy MzUjYXBwZW5kaXgtQzwvYT5dLjxvOnA+PC9vOnA+PC9wPjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9w PjxwPi0tPG86cD48L286cD48L3A+PHA+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3A+PHA+Jm5i c3A7PG86cD48L286cD48L3A+PHA+PHNwYW4gbGFuZz1FTi1VUz4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj5Gcm9tOiBPQXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5d IE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZzxicj5TZW50OiBXZWRuZXNkYXksIDExIE1h eSAyMDE2IDg6NDggUE08YnI+VG86IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm9hdXRoQGlldGYub3JnPC9hPjxicj5TdWJqZWN0OiBbT0FVVEgtV0ddIE9B dXRoIDIuMCBmb3IgYnJvYWRjYXN0ZXJzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwPiZuYnNwOzxv OnA+PC9vOnA+PC9wPjxwPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD48cD4mbmJzcDs8bzpwPjwvbzpw PjwvcD48cD5FbmQgb2YgQXByaWwgSSBoYWQgdGhlIGNoYW5jZSB0byB0YWxrIHRvIE1pY2hhZWwg QmFycm9jbyAoZnJvbSB0aGUgRXVyb3BlYW4gQnJvYWRjYXN0aW5nIFVuaW9uKSBhbmQgdG8gQ2hy aXMgTmVlZGhhbSAoZnJvbSB0aGUgQkJDKSByZWdhcmRpbmcgdGhlaXIgdXNlIG9mIE9BdXRoIDIu MCBmb3IgYnJvYWRjYXN0ZXJzLjxvOnA+PC9vOnA+PC9wPjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9w PjxwPkluIE1hcmNoIE1pY2hhZWwgZHJvcHBlZCBhIG1haWwgdG8gdGhlIE9BdXRoIG1haWxpbmcg bGlzdCB0byBtYWtlIHVzIGF3YXJlIG9mIHRoZWlyIHdvcmssIHNlZSA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTU5NjkuaHRt bCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSdjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVj b3JhdGlvbjpub25lJz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRo L2N1cnJlbnQvbXNnMTU5NjkuaHRtbDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+PHA+Jm5ic3A7 PG86cD48L286cD48L3A+PHA+VGhlIHNwZWNpZmljYXRpb24gdGhleSBhcmUgd29ya2luZyBvbiBp cyBiYXNlZCBvbiB0aGUgT0F1dGggRGV2aWNlIGZsb3cuPG86cD48L286cD48L3A+PHA+Jm5ic3A7 PG86cD48L286cD48L3A+PHA+TWljaGFlbCBhbmQgQ2hyaXMgd2Fsa2VkIG1lIHRocm91Z2ggYSBz bGlkZSBkZWNrIG9mZmVyaW5nIG1lIG1vcmUgYmFja2dyb3VuZCByZWdhcmRpbmcgdGhlaXIgd29y ay4gKEkgd2lsbCB1cGxvYWQgdGhlIHNsaWRlIGRlY2sgdG8gb3VyIFdpa2kgYnV0IHRoZSBJRVRG IG1lZXRpbmcgc2l0ZSBzZWVtcyB0byBiZSBkb3duIGF0IHRoZSBtb21lbnQuKTxvOnA+PC9vOnA+ PC9wPjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwPkluIGFkZGl0aW9uIHRvIHRoZSBzcGVjaWZp Y2F0aW9uIGNvZGUgYW5kIHR1dG9yaWFscyBoYXZlIGJlZW4gZGV2ZWxvcGVkIGFuZCB5b3UgY2Fu IGZpbmQgdGhlbSBoZXJlOjxvOnA+PC9vOnA+PC9wPjxwPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS9lYnUvY3BhLXR1dG9yaWFsIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2NvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUnPmh0dHBzOi8vZ2l0aHViLmNvbS9lYnUv Y3BhLXR1dG9yaWFsPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD48cD48YSBocmVmPSJodHRwczov L3RlY2guZWJ1LmNoL2NvZGUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29sb3I6d2lu ZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSc+aHR0cHM6Ly90ZWNoLmVidS5jaC9jb2RlPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvcD48cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cD5JIGdhdmUg Q2hyaXMgJmFtcDsgTWljaGFlbCBhbiB1cGRhdGUgb2Ygd2hhdCB3ZSBhcmUgZG9pbmcgaW4gdGhl IE9BdXRoIHdvcmtpbmcgZ3JvdXAgc2luY2UgSSBiZWxpZXZlIHNvbWUgb2Ygb3VyIGN1cnJlbnRs eSBjaGFydGVyZWQgaXRlbXMgY291bGQgYmUgcmVsZXZhbnQgZm9yIHRoZW0sIHN1Y2ggYXMgdGhl IG5hdGl2ZSBhcHBzIEJDUCBvciB0aGUgUG9QL1Rva2VuIEJpbmRpbmcgd29yay4gSSBhbHNvIG1l bnRpb25lZCB0aGF0IHdlIGFyZSBsb29raW5nIGZvciBmZWVkYmFjayBmcm9tIHRoZWlyIGdyb3Vw IG9uIHRoZSBEZXZpY2UgRmxvdyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPjxwPiZuYnNw OzxvOnA+PC9vOnA+PC9wPjxwPkNpYW88bzpwPjwvbzpwPjwvcD48cD5IYW5uZXM8bzpwPjwvbzpw PjwvcD48cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PkZyb206ICZxdW90O0JhcnJvY28sIE1pY2hhZWwmcXVvdDsgJmx0O2JhcnJvY28gYXQgPGEgaHJl Zj0iaHR0cDovL2VidS5jaCIgdGFyZ2V0PSJfYmxhbmsiPmVidS5jaDwvYT4mZ3Q7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VG86ICZxdW90O29hdXRo IGF0IDxhIGhyZWY9Imh0dHA6Ly9pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlldGYub3JnPC9h PiZxdW90OyAmbHQ7b2F1dGggYXQgPGEgaHJlZj0iaHR0cDovL2lldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+aWV0Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHls ZT0nY29sb3I6YmxhY2snPkNjOiAmcXVvdDt0dnAtY3BhIGF0IDxhIGhyZWY9Imh0dHA6Ly9saXN0 LmVidS5jaCIgdGFyZ2V0PSJfYmxhbmsiPmxpc3QuZWJ1LmNoPC9hPiZxdW90OyAmbHQ7dHZwLWNw YSBhdCA8YSBocmVmPSJodHRwOi8vbGlzdC5lYnUuY2giIHRhcmdldD0iX2JsYW5rIj5saXN0LmVi dS5jaDwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpi bGFjayc+RGF0ZTogTW9uLCA3IE1hciAyMDE2IDA4OjQzOjU2ICswMDAwPC9zcGFuPjxvOnA+PC9v OnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+RGVhciBhbGwsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+V2UgYXJlIGNvbnRhY3Rpbmcg eW91IGJlY2F1c2Ugd2Ugbm90aWNlZCB0aGF0IHlvdSByZWNlbnRseSByZXN0YXJ0ZWQgdGhlIHdv cmsgb24gT0F1dGggMi4wIERldmljZSBGbG93LiBXZSBhcmUgaW4gdGhlIHByb2Nlc3Mgb2YgcHVi bGlzaGluZyBhbiBFVFNJIHN0YW5kYXJkIFsxXSBzcGVjaWZ5aW5nIGEgcHJvdG9jb2wgd2l0aCB2 ZXJ5IHNpbWlsYXIgZ29hbHMuIFRoaXMgaGFzIGJlZW4gZGV2ZWxvcGVkIGJ5IGFuIEVCVSAoRXVy b3BlYW4gQnJvYWRjYXN0aW5nIFVuaW9uKSB3b3JraW5nIGdyb3VwIGludm9sdmluZyBicm9hZGNh c3RlcnMsIHN1Y2ggYXMgQkJDLCBTUkctUlRTLCBWUlQsIFJUVkUsIFRWUCwgR2xvYmFsIFJhZGlv IFVLLCBhbmQgZGV2aWNlIG1hbnVmYWN0dXJlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxz cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+T3VyIHdvcmsgb24gdGhlIOKAnENyb3NzIFBsYXRmb3Jt IEF1dGhlbnRpY2F0aW9u4oCdIHByb3RvY29sIHRhcmdldHMgbWVkaWEgZGV2aWNlcywgc3VjaCBh cyBjb25uZWN0ZWQgVFZzIGFuZCByYWRpbyByZWNlaXZlcnMuIEl0IGlzIGJhc2VkIG9uIHRoZSBl YXJseSBPQXV0aCAyLjAgRGV2aWNlIEZsb3cgZHJhZnQsIGJ1dCBpbmNsdWRlcyBhZGRpdGlvbmFs IGZlYXR1cmVzIGRyaXZlbiBieSBicm9hZGNhc3QgaW5kdXN0cnkgcmVxdWlyZW1lbnRzLiBUaGVz ZSBpbmNsdWRlOiBkeW5hbWljIHJlZ2lzdHJhdGlvbiBvZiBjbGllbnRzLCBkeW5hbWljIGRpc2Nv dmVyeSBvZiB0aGUgYXV0aG9yaXphdGlvbiBwcm92aWRlciwgYW5kIGlzc3Vpbmcgb2YgYWNjZXNz IHRva2VucyB3aXRob3V0IHJlcXVpcmluZyBhc3NvY2lhdGlvbiB3aXRoIGEgdXNlciBhY2NvdW50 IGluIG9yZGVyIHRvIHByb3ZpZGUgZGV2aWNlLWJhc2VkIGF1dGhlbnRpY2F0aW9uIHRoYXQgZG9l cyBub3QgcmVxdWlyZSB1c2VyIHNpZ24taW4gb3IgcGFpcmluZy4gT3VyIGRyYWZ0IHByb3RvY29s IHNwZWNpZmljYXRpb24gaXMgYXZhaWxhYmxlIGhlcmUgWzJdLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD48cD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD48cD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD48cD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkNyb3NzIFBsYXRmb3JtIEF1dGhlbnRpY2F0 aW9uIGFsc28gc3BlY2lmaWVzIHNldmVyYWwgYXNwZWN0cyBsZWZ0IG9wZW4gdG8gaW1wbGVtZW50 ZXJzIGluIE9BdXRoIDIuMCwgc3VjaCBhcyBlbmRwb2ludCBVUkwgcGF0aHMsIHRvIGZhY2lsaXRh dGUgaW50ZXJvcGVyYWJpbGl0eS4gQWxzbyBub3RlIHRoYXQgcmVmZXJlbmNlIGltcGxlbWVudGF0 aW9ucyBhcmUgYXZhaWxhYmxlIFszXS48L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNwYW4gc3R5 bGU9J2NvbG9yOmJsYWNrJz5XZSB3b3VsZCBiZSB2ZXJ5IGludGVyZXN0ZWQgaW4gd29ya2luZyB0 b2dldGhlciB3aXRoIHlvdSB0byBleHBsYWluIG91ciBkZXNpZ24gcmVxdWlyZW1lbnRzIGFuZCB0 cnkgdG8gYWxpZ24gb3VyIHByb3RvY29sIGRlc2lnbnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+V2l0aCBiZXN0IHJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VGhlIEVCVSBDcm9zcyBQbGF0 Zm9ybSBBdXRoZW50aWNhdGlvbiBncm91cDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPjxhIGhyZWY9Imh0dHBzOi8vdGVjaC5lYnUuY2gvY3BhIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly90ZWNoLmVidS5jaC9jcGE8L2E+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+WzFdIDxhIGhyZWY9Imh0dHBzOi8vcG9y dGFsLmV0c2kub3JnL3dlYmFwcC9Xb3JrUHJvZ3JhbS9SZXBvcnRfV29ya0l0ZW0uYXNwP1dLSV9J RD00Nzk3MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vcG9ydGFsLmV0c2kub3JnL3dlYmFwcC9X b3JrUHJvZ3JhbS9SZXBvcnRfV29ya0l0ZW0uYXNwP1dLSV9JRD00Nzk3MDwvYT48L3NwYW4+PG86 cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5bMl0gPGEgaHJlZj0iaHR0 cHM6Ly90ZWNoLmVidS5jaC9kb2NzL3RlY2gvdGVjaDMzNjYucGRmIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly90ZWNoLmVidS5jaC9kb2NzL3RlY2gvdGVjaDMzNjYucGRmPC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPlszXSA8YSBocmVmPSJodHRw czovL3RlY2guZWJ1LmNoL2NvZGUvY3BhIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90ZWNoLmVi dS5jaC9jb2RlL2NwYTwvYT48L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PG86cD48L286cD48L3A+PC9k aXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPk9BdXRoIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PG86cD48L286cD48L3A+PC9ibG9ja3F1b3RlPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPi0tIDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2xpbmUtaGVpZ2h0OjE0LjY1cHQnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+TmF0 IFNha2ltdXJhPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdsaW5lLWhlaWdodDoxNC42NXB0Jz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PkNoYWlybWFuIG9mIHRoZSBCb2FyZCwgT3BlbklEIEZvdW5kYXRpb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2xpbmUtaGVpZ2h0OjE0 LjY1cHQnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+VHJ1c3RlZSwgS2FudGFyYSBJbml0aWF0 aXZlPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E13BD1663C5FWSMSG3153Vsrv_-- From nobody Mon May 16 03:30:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5666812D144 for ; Mon, 16 May 2016 03:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.027 X-Spam-Level: X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 n-L75k6yCjsg for ; Mon, 16 May 2016 03:30:31 -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 2ABC312D14A for ; Mon, 16 May 2016 03:30:29 -0700 (PDT) Received: from [192.168.10.132] ([194.96.17.130]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MUDXS-1bBdi43HTm-00R0gN for ; Mon, 16 May 2016 12:30:27 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5739A146.2070505@gmx.net> Date: Mon, 16 May 2016 12:30:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UUfMJuVo36tCrmjJPG6q6DTwGd6bnbvsQ" X-Provags-ID: V03:K0:WTN1xgtHgvzm3oU9AL1pYztBmOKEEIbi5LBwTCeUl87ObnJRohi G0Hp4zmX9bYI4Z5oAt0x/+DcpFEUFBQvFtrBn3JDaHZMrGeyuLIxiWKscUeXH3LvqKwtnJZ fe+ERRu15oe7th/I0aH5L1D+BEbJhgjwdIYS87WVfGW+FsSjUpeG72b0GVF2koCoTBEp3ti UTH2o7qO+YVs8mRGGKUrw== X-UI-Out-Filterresults: notjunk:1;V01:K0:q083TEd5zP8=:hDHQVZpWFnQwASeoT0PzMm vRMI8fukUkxMyNPuP119YEl5aA7vJ/MW8qZgG3cwEatqdj8G9wBk8AzZC1lTxSGOWvXk7SDzB 0NLsknt6nmcj3vA5J6dC07aIuYxTbkdIMsUGII8DSy92IsBillCmsFsU4S4HHbGEhfmsEePaW 3ZAgV0hjHE4eYaxH0/16e1IdJpUZ22cvytmu0oL0KeXMZx0jgB8g/FyML7RIpzL+rj06iPkbP 6K8gcxHj6FUoND2E60rx1TQmBB/MPEdTpTJbcEMNx5cVsPcexcHEiKZ5pjYTFDvgW2usYLhvw w95BOZ0vWi+z8BKKt8y4bC8chaHNvG0eSsvVup9xAHst0+PMmFsLjqZO39VvnrPpfsvDo07F1 BLWectIQdCNdQqk5y576/fuLnhKVC9w11a+irC5JllwBfuAWhJt9Jn8k3pNZ7CJJDUp9Igds0 vzdxzX+Ir3Zbzy0GHkJp4pU9Gr6Lq8/UpAzFX+6VMDJoKykEARPrJEUk6reagHQQ+XPr78n5X KW5ekTHftXSf3Qo1sIl55zS6uRmNDuSXn2a6IdN+MXIlaJxU/BliK1gTw/Zb93vIOPN1WPbyD 9V0UR1e1z2iGyjPyxrYA7phIeF+cQX+mmEu/bt6VH3rE/dRoA6UsPguHXSwDs/1VE3LAoMnj5 I/xd0JcbJQ4DEq3MlwVdx2jjhwL8AgX1+NjpHixK0+/KyB7WdBuCOn+KIWlHLSXHh7xZTiGc3 QlKmZThU2sWmwqcT7y3a3z/6Xv/PUa/c7/f+lGT+huUxbp0bKJSMTaa94bc= Archived-At: Subject: [OAUTH-WG] Reminder: OAuth Security Workshop X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 10:30:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UUfMJuVo36tCrmjJPG6q6DTwGd6bnbvsQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, this is a reminder that the call for position paper deadline for the OAuth Security Workshop is getting closer. Here is the link to the info: https://infsec.uni-trier.de/events/osw2016 Ciao Hannes --UUfMJuVo36tCrmjJPG6q6DTwGd6bnbvsQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXOaFGAAoJEGhJURNOOiAtnRsH/RZjwz1mSMHpUmlR/oh2l9fe 2McOUXAHLYZNinXgnxy4SgUk52ECBlHCSlvGtQFjwTA6G8MTyvh1DN/6KSmDZb/w V0JWazJb4UxjAi/D3uT5LZ1IXy2Wtet0gFrJ8l9bpvI6xkVBVPpU/0VjY024k5Q/ yDxXyq8pvHq0EDmvTmpYQ0xb7ldXsGBNCbSlFDxG+nDtJeXquxhSCfJBGif45XUE yvxBy1VqQm0OVGlKJna7vMVB+M95MLWcf4DBEPd4l7+/I8f2dDdQOVSJ1Jt23Jk0 TZOe7/JA8SAlMtbtlRFieyCX6tmnkx0FXdPcrdYpN+gGIOug39LV6AoCyiya+cE= =Quva -----END PGP SIGNATURE----- --UUfMJuVo36tCrmjJPG6q6DTwGd6bnbvsQ-- From nobody Mon May 16 04:25:37 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815C312D168 for ; Mon, 16 May 2016 04:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Px0UNV3MN2t for ; Mon, 16 May 2016 04:25:33 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDAE4127058 for ; Mon, 16 May 2016 04:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3F/DJbx4cXNTr2Yjda4phufWrvXnZ+s3/zMfGC7RNPw=; b=RvYMK0+thui2pTPpjtP1R/YU4OY5VI0EpDnpjNoIH2B8eh+57WmA7q1uysBshX540M+rjeaYyUfZayheRvhHhrGtI6cV7JA5RmfO+Faw/91NssZSqocQOBwzo9Mli0Kk6subZON5iy9tzWGJr//3zwR9tfuRSz9Kt+OrVEAjOIo= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1646.namprd03.prod.outlook.com (10.162.130.140) with Microsoft SMTP Server (TLS) id 15.1.497.12; Mon, 16 May 2016 11:25:12 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0497.017; Mon, 16 May 2016 11:25:13 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" , Daniel Fett Thread-Topic: [OAUTH-WG] Reminder: OAuth Security Workshop Thread-Index: AQHRr14B+gAMWUiT20WKCNYPTnp8CZ+7acxA Date: Mon, 16 May 2016 11:25:12 +0000 Message-ID: References: <5739A146.2070505@gmx.net> In-Reply-To: <5739A146.2070505@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [64.134.96.176] x-ms-office365-filtering-correlation-id: da4f8a22-a2ce-4b3a-b9b2-08d37d7cbf69 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1646; 5:JJQW/GHPY4xOW1rmkC79Juuxr+GydhhE+S/AnM2anZ+4mX907LvzHZ7PIFxjWpx4O3AdAe0mgyARXeWW02CCQkNkCrKco7YVmy+4mpqTGg9W5p/p1kCSPt0JQt4O7rpbaqfo5uW0fBql8jnw/50DFg==; 24:N2XBIf8FUCHMVCdkOiUaQo17JKi/hsJsleqc+YsG0M5UUKbvdftncksCV5sDEOG4Kd3f5eIg3TwDhQm9oIHKajsl31yOZt0fK46TSe3IhUQ=; 7:tpfV/PbJ5xmdnMaxY+U07LE2qWXS1k6oCISYbn55mume5NZWchJBDFUxqngRAMPOCDlMaY5ZrIg4dZWdjbHIv+bXvXZjhROfk6J20fbMOzAphycsMFs2Vlbug3SuVo5Lh/jEtr2DfU+88VO5v3lYJqLv89FZNKTOtiA8Fk/J3fOGehGQRnZcL3pzVU3RY/H6cIpw+SKopppAm0zSpu53kw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1646; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1646; x-forefront-prvs: 09443CAA7E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(53754006)(122556002)(10290500002)(586003)(102836003)(3846002)(6116002)(99286002)(19580405001)(10400500002)(19580395003)(1220700001)(87936001)(5005710100001)(81166006)(66066001)(15975445007)(8936002)(8676002)(2950100001)(86612001)(33656002)(2900100001)(77096005)(86362001)(5008740100001)(74316001)(3660700001)(5001770100001)(3280700002)(50986999)(54356999)(76176999)(107886002)(2906002)(76576001)(9686002)(15650500001)(10090500001)(5004730100002)(189998001)(92566002)(106116001)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1646; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2016 11:25:12.7978 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1646 Archived-At: Subject: Re: [OAUTH-WG] Reminder: OAuth Security Workshop X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 11:25:35 -0000 SSdtIHBsYW5uaW5nIHRvIHN1Ym1pdCBhIHBvc2l0aW9uIHBhcGVyIHRvIHRoZSBPQXV0aCBzZWN1 cml0eSB3b3Jrc2hvcC4gIEkgY291bGRuJ3QgZmluZCBhbnkgZ3VpZGFuY2Ugb24gd2hhdCB0aGUg cHJvZ3JhbSBjb21taXR0ZWUgaXMgbG9va2luZyBmb3IgaW4gdGhlIHBhcGVycy4gIEkgY291bGQg aW1hZ2luZSBhbnl0aGluZyBmcm9tIHN1Ym1pdHRpbmcgYSBwYXJhZ3JhcGggb3IgdHdvIGRlc2Ny aWJpbmcgdGhlIGNvbnZlcnNhdGlvbnMgSSdkIGxpa2UgdG8gbGVhZCB0byBhIDEwLXBhZ2UgcGFw ZXIgc3VpdGFibGUgZm9yIHBlZXItcmV2aWV3ZWQgcHVibGljYXRpb24sIG9yIGFueXRoaW5nIGlu IGJldHdlZW4uICBXaGF0IHdlcmUgeW91IGxvb2tpbmcgZm9yPw0KDQpBbHNvLCB3aWxsIHRoZSBw b3NpdGlvbiBwYXBlcnMgYmUgcHVibGlzaGVkIGluIGEgd29ya3Nob3AgcHJvY2VlZGluZ3Mgb3Ig d2lsbCB0aGV5IGJlIHVzZWQgb25seSBmb3IgZGV0ZXJtaW5pbmcgd2hvIHdpbGwgYmUgaW52aXRl ZCB0byBwYXJ0aWNpcGF0ZT8NCg0KCQkJCVRoYW5rcywNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KU2VudDogTW9uZGF5LCBNYXkg MTYsIDIwMTYgMzozMSBBTQ0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBbT0FVVEgtV0dd IFJlbWluZGVyOiBPQXV0aCBTZWN1cml0eSBXb3Jrc2hvcA0KDQpIaSBhbGwsDQoNCnRoaXMgaXMg YSByZW1pbmRlciB0aGF0IHRoZSBjYWxsIGZvciBwb3NpdGlvbiBwYXBlciBkZWFkbGluZSBmb3Ig dGhlIE9BdXRoIFNlY3VyaXR5IFdvcmtzaG9wIGlzIGdldHRpbmcgY2xvc2VyLg0KDQpIZXJlIGlz IHRoZSBsaW5rIHRvIHRoZSBpbmZvOg0KaHR0cHM6Ly9pbmZzZWMudW5pLXRyaWVyLmRlL2V2ZW50 cy9vc3cyMDE2DQoNCkNpYW8NCkhhbm5lcw0KDQo= From nobody Mon May 16 07:28:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1724E12D187 for ; Mon, 16 May 2016 07:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoCvLgVptyZq for ; Mon, 16 May 2016 07:28:27 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E14E512D0C6 for ; Mon, 16 May 2016 07:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9PASKZcc9hx6Wut5VZfHbvzBIOnFuR6caiqEseA6QbA=; b=BoA4XqPe708r+kbXiX4IaIxUID6DKQ/20YbCHqgS9uIsf/78kf85sl24qr4VRm+5PmhVDoIWt6eeDtWRLl/HNsldM7Y8+04+JGphJ0vBkcwRmfLz3nuYbYNXCmWD8Elu1k4zn5o76W8eKyVnbtK+u0xU65bLkcr4ZplUP26jYbQ= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.492.11; Mon, 16 May 2016 14:28:24 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0492.020; Mon, 16 May 2016 14:28:21 +0000 From: Anthony Nadalin To: Mike Jones , Hannes Tschofenig , "oauth@ietf.org" , Daniel Fett Thread-Topic: [OAUTH-WG] Reminder: OAuth Security Workshop Thread-Index: AQHRr14BjIq/t6c3mEuNMauXBbQByJ+7bHwAgAAy3GA= Date: Mon, 16 May 2016 14:28:21 +0000 Message-ID: References: <5739A146.2070505@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.46.126.7] x-ms-office365-filtering-correlation-id: 331537dd-a25a-49c5-ddb5-08d37d96555a x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:3SV3MCBofJc5Y54Et9nXMEE5bMwRx7Q4H45GohpcnSrlX8P7WIsOJgV+8Nl5LxvRboGe/n/LGguem95rnvpCylyqSLjtPOeaFJnVvnZ2j5UDb0clgTOVkPGJE/JsEEoQgD6wL0wXf1qDQNcyB/IX8Q==; 24:XDLiLow/iNOhY4yvmAnNYKW1e5g9YIQtUIFMm/Qil6Q/RvhQMabn1TAs9MZsWZZbAi8eqgP4oMkz9NEDgHX2Fzri7HfU/70jDLfvcOjHpBg=; 7:YOikQqA4oFXdqM7kYcgtXcNwC1v2rjQdrOkpFEnwHUDp5ksYp6SG/Jm6xobbHxb1PXiUJ5PTZqvJnF4C0S0w2YuA704gHYo3GkhFXs2AQ7jyoKYyrGFYr2TPjg22m/X2cHXLPrT7FmRVSut0dFgLtvUJHGrGkapEMRxcZBtIaTQN3KXoJlc5gg7/iPiDTHHAMtKTNZsI0lUfdsTm75WnHA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1234; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; x-forefront-prvs: 09443CAA7E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(53754006)(13464003)(377454003)(5002640100001)(9686002)(6116002)(86612001)(102836003)(3846002)(586003)(1220700001)(92566002)(77096005)(2906002)(19580405001)(19580395003)(99286002)(106116001)(81166006)(5008740100001)(8676002)(2900100001)(3280700002)(5001770100001)(76576001)(189998001)(10090500001)(2950100001)(33656002)(8936002)(10290500002)(5004730100002)(5005710100001)(10400500002)(3660700001)(54356999)(50986999)(76176999)(87936001)(2561002)(1511001)(15975445007)(66066001)(15650500001)(107886002)(74316001)(122556002)(86362001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2016 14:28:21.6831 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234 Archived-At: Subject: Re: [OAUTH-WG] Reminder: OAuth Security Workshop X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 14:28:29 -0000 Can I also suggest that a PayPal or Credit Card payment be added as a means= as bank transfer for corporate folks is like impossible=20 -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones Sent: Monday, May 16, 2016 4:25 AM To: Hannes Tschofenig ; oauth@ietf.org; Daniel F= ett Subject: Re: [OAUTH-WG] Reminder: OAuth Security Workshop I'm planning to submit a position paper to the OAuth security workshop. I = couldn't find any guidance on what the program committee is looking for in = the papers. I could imagine anything from submitting a paragraph or two de= scribing the conversations I'd like to lead to a 10-page paper suitable for= peer-reviewed publication, or anything in between. What were you looking = for? Also, will the position papers be published in a workshop proceedings or wi= ll they be used only for determining who will be invited to participate? Thanks, -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Monday, May 16, 2016 3:31 AM To: oauth@ietf.org Subject: [OAUTH-WG] Reminder: OAuth Security Workshop Hi all, this is a reminder that the call for position paper deadline for the OAuth = Security Workshop is getting closer. Here is the link to the info: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2finfsec.u= ni-trier.de%2fevents%2fosw2016&data=3D01%7c01%7ctonynad%40microsoft.com%7c1= 7bb7f6c7065422371df08d37d7cd18b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdat= a=3DNOKnwv9A439uCCz89MtiIDSjQZGNlUNo4zXibDGwotI%3d Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2foauth&data=3D01%7c01%7ctonynad%40microsoft.com%= 7c17bb7f6c7065422371df08d37d7cd18b%7c72f988bf86f141af91ab2d7cd011db47%7c1&s= data=3D2ARrqLXQ5QQ7d8gvrm%2bqaXmyXrhl3Q10kOc7X5usag4%3d From nobody Mon May 16 21:51:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3317E12D0B9 for ; Mon, 16 May 2016 21:51:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgQ-iTDRNwMi for ; Mon, 16 May 2016 21:51:29 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73BF12D126 for ; Mon, 16 May 2016 21:51:28 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id e201so123721200wme.0 for ; Mon, 16 May 2016 21:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=3aUzJiLFMkVoEkp6zVX9prthAi0wCkdl2zbothPh7rc=; b=1uDJXabhzg4Da8TSmlTE+qKR9bgf0bjTvFwDeQf8joWcMEsnIYpgkNv4trPGoX1I+F BN5UB2amHv40oRMJ7Yfwz4yNorxvSfECI3Ap13n0oNMqDjJzO5lPgWYCnvbyeOviw8ME oBG3Esra9JOZ1MESGWPpbk7x1JGN0kA9xfo/PjczXniAFr8ZbJJIFFgPgKKlDWxJHOjD ulDiaKh85uA+2F8zHzpW6d8NvqqMt0EEfxIqs1ZcPPSSl6vBP41npD4uxGIHSDEx4vt9 H/GulkyLPnsP4baVMLNuEebmMKeLNQTZGeCYAABzbM7+0/+J2CKRGCT0z9JDbPiV+rTV VoiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=3aUzJiLFMkVoEkp6zVX9prthAi0wCkdl2zbothPh7rc=; b=eNw7vEqzgrawY52/c3rHPHj/m6Gxy3oF2Mk06HGTsoO1NlhBFj23480w0UQRGc2+qH qZkJAWvFzPcYQcE+tTgo228E5/mI2hxZg6xBY6liyv0253yTPej8REmN+9xNhEiRi/Co zqD62wKIq9ZwIo1yrN5hWcpxuJ7XxBxkHwov2tBJb/8C8km2LBMo0NtEmNJ5WSRZWwpt 688DTD+YdqEwi6wxNN9N5/xYfJfSr7eMrDkp56Q9W3M13X+NOcAk3QAXvl9rVXUNlN5N TD1IC3N7wDud6lCC0trE4rfJWDnpmZWh1eqskAJ2ugh4v5UjurtrSiKftcQ71f9TrTEu 604g== X-Gm-Message-State: AOPr4FWvnVHOZUym/9DIY2jgensSRUjbpfyanks6POIZsw8je/EJ/XrFT4VFtTStJ8drLuXlD7a0qL9U/2hO5A== MIME-Version: 1.0 X-Received: by 10.194.114.228 with SMTP id jj4mr33338066wjb.121.1463460686889; Mon, 16 May 2016 21:51:26 -0700 (PDT) Received: by 10.194.119.163 with HTTP; Mon, 16 May 2016 21:51:26 -0700 (PDT) Date: Mon, 16 May 2016 21:51:26 -0700 Message-ID: From: Samuel Erdtman To: "" , wdenniss@google.com Content-Type: multipart/alternative; boundary=001a1130caae62a0030533027e4e Archived-At: Subject: [OAUTH-WG] poll url in draft-ietf-oauth-device-flow-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 04:51:31 -0000 --001a1130caae62a0030533027e4e Content-Type: text/plain; charset=UTF-8 Hi, I just manage to take the time to read this document and in general I like it a lot I think it fills a gap and with mapping to CBOR, and CoAP it will work well for more constrained deceive too. There are several details that would be great to address such as IANA section more thorough descriptions of device_code and user_code and It would also be good with more examples e.g. a poll example. The above things one can figure out relatively easy but how and where are poll requests sent. Is it new post requests to the token endpoint with the device_code included; or is it get requests to the token endpoint with the device_code; or is it a completely different endpoint? A solution that I would like is to have a poll url instead of the device_code then the client does not need to know how to construct the poll url form the device_code. Is there a github repo or something similar that I could send pull requests to? Best regards //Samuel --001a1130caae62a0030533027e4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi,

    I just mana= ge to take the time to read this document and in general I like it a lot I = think it fills a gap and with mapping to CBOR, and CoAP it will work well f= or more constrained deceive too.

    There are several details tha= t would be great to address such as IANA section more thorough descriptions= of device_code and user_code and It would also be good with more examples = e.g. a poll example.

    The above things one can figure out relat= ively easy but how and where are poll requests sent. Is it new post request= s to the token endpoint with the device_code included; or is it get request= s to the token endpoint with the device_code; or is it a completely differe= nt endpoint?
    A solution that I would like is to have a poll = url instead of the device_code then the client does not need to know how to= construct the poll url form the device_code.

    Is there = a github repo or something similar that I could send pull requests to?
    <= br>
    Best regards
    //Samuel
    --001a1130caae62a0030533027e4e-- From nobody Mon May 16 23:34:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24DC12D59B for ; Mon, 16 May 2016 23:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9W-V57jKXOL for ; Mon, 16 May 2016 23:34:25 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0054.outbound.protection.outlook.com [65.55.169.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EABB212D597 for ; Mon, 16 May 2016 23:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6P8jGHdMGHOTOMPnl1cefd9pkSteLR0GjnUijJQj0x8=; b=Q1H9uqjjmwi4RLE55AzQhvUd5ka/AH1mY92OU+R0l99DmKAVVwQumINGopt4iZOyclWTJgtPhFPCp5wn2yBSB+65a36SUDeUABEpi877Z2aiuGr/IvkeGf6WN+5WwIwuDngVEzE0rybiS5DVQHHkRJcLAGa9FaQdkQtAS6LUyIA= Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1031.namprd02.prod.outlook.com (10.161.203.149) with Microsoft SMTP Server (TLS) id 15.1.492.11; Tue, 17 May 2016 06:34:20 +0000 Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) with mapi id 15.01.0492.020; Tue, 17 May 2016 06:34:20 +0000 From: Antonio Sanso To: Daniel Fett Thread-Topic: [OAUTH-WG] Mix-Up and CnP/ Code injection Thread-Index: AQHRnVXh+NWK213hKUa/D+/PVehh55+qd/GAgAWXtgCAAeAwAIAK4dqA Date: Tue, 17 May 2016 06:34:20 +0000 Message-ID: References: <571B60BA.8090301@lodderstedt.net> <572B56BB.9080903@uni-trier.de> <57319A8C.3070408@uni-trier.de> In-Reply-To: <57319A8C.3070408@uni-trier.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: uni-trier.de; dkim=none (message not signed) header.d=none;uni-trier.de; dmarc=none action=none header.from=adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [77.73.244.218] x-ms-office365-filtering-correlation-id: e7cd0ceb-5456-47e2-6464-08d37e1d4785 x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1031; 5:pLyC0E98qN/D4jWX7LQ2cC6f1iTh0EAm9u2FTJlyKa6qx7YljqrTa6Zc0Dl/ow1sKsvOZkhsQYC+b7wLj2scFXXcEk4OL7eLcy4UuDN0kj7IqkeIVw2TESPnDtaXyCjYtFmrknJEluEkNUxVIGs1aQ==; 24:StEtpfSbr+cm1i5/Z0u57M6cz9I9P9PhdZGRF0U0jyobvp6mpmr15lwN1Cje6sG1Mm1xQBnGc8p/cGo1qUD/cX4NrWYbV7Pc3h5y9VwgsEA=; 7:wDHKEmJ0w7PzRzs9s5soJ8Z3X4Hb3MU+z/MOKRlzn7evRDQ2AvodA+0ioiKt/5750v8Ogo0PGQB/6frxKT82wT/b7zxK+Vb0mCSl5SRSBi/o2ILqb7DKxMFn+LIXgP0m/ADcRpw0OlwA3gjjallRveNEztBg7x4fBxxYgENdKIU3Hf1cJAPFGKW0BLDuJggI x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1031; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BY1PR0201MB1031; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1031; x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(24454002)(2906002)(81166006)(5004730100002)(93886004)(82746002)(4326007)(54356999)(77096005)(66066001)(5002640100001)(16236675004)(99286002)(122556002)(87936001)(83716003)(11100500001)(10400500002)(8936002)(106116001)(10090500001)(5008740100001)(8676002)(92566002)(19617315012)(2950100001)(189998001)(6116002)(102836003)(1220700001)(2900100001)(3846002)(15975445007)(586003)(76176999)(36756003)(86362001)(19580395003)(19580405001)(50986999)(33656002)(110136002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1031; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CAE14AB37A684F2AB73DFC98DBBBEE96adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 06:34:20.7353 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1031 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 06:34:28 -0000 --_000_CAE14AB37A684F2AB73DFC98DBBBEE96adobecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aGksDQoNCkZXSVcgRmFjZWJvb2sgaXMgbm90IHRoZSBvbmx5IG9uZSBoZXJlLg0KTWFueSBPQXV0 aCBwcm92aWRlciBkbyBub3QgZG8gZXhhY3QgbWF0Y2hpbmcgcmVkaXJlY3QgdXJpIHZhbGlkYXRp b24uIEdpdGh1YiBmb3IgZXhhbXBsZSBpcyBhbm90aGVy4oCmLg0KDQpyZWdhcmRzDQoNCmFudG9u aW8NCg0KT24gTWF5IDEwLCAyMDE2LCBhdCAxMDoyMyBBTSwgRGFuaWVsIEZldHQgPGZldHRAdW5p LXRyaWVyLmRlPG1haWx0bzpmZXR0QHVuaS10cmllci5kZT4+IHdyb3RlOg0KDQpJdCBkb2VzIG5v dCB3b3JrIGlmIHRoZSBBUyBkb2VzIG5vdCBjaGVjayB0aGUgcmVkaXJlY3QgVVJJIGNvbXBsZXRl bHkuDQpGYWNlYm9vayBiZWluZyB0aGUgbWFpbiBleGFtcGxlIGhlcmUsIGFuZCBJIGd1ZXNzIHRo ZXkgd29uJ3QgY2hhbmdlIHRoaXMNCnNvb24gKGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSku IEFkZGluZyB0aGUgaXNzIHBhcmFtZXRlciB3b24ndCBicmVhaw0KdGhpbmdzLg0KDQotRGFuaWVs DQoNCkFtIDA5LjA1LjIwMTYgdW0gMDU6NDUgc2NocmllYiBOYXQgU2FraW11cmE6DQpIaSBEYW5p ZWwsDQoNCk1heSBJIGFzayBhZ2FpbiB3aHkgc2VwYXJhdGUgcmVkaXJlY3QgdXJpIHdvdWxkIG5v dCB3b3JrIGZvciBtaXgtdXA/DQooSSBrbm93LCBpdCBkb2VzIG5vdCB3b3JrIGZvciBjdXQtbi1w YXN0ZS4pDQoNClRoYW5rcywNCg0KTmF0DQoNCjIwMTblubQ15pyINeaXpSjmnKgpIDIzOjI4IERh bmllbCBGZXR0IDxmZXR0QHVuaS10cmllci5kZTxtYWlsdG86ZmV0dEB1bmktdHJpZXIuZGU+DQo8 bWFpbHRvOmZldHRAdW5pLXRyaWVyLmRlPj46DQoNCiAgIEFtIDIzLjA0LjIwMTYgdW0gMTM6NDcg c2NocmllYiBUb3JzdGVuIExvZGRlcnN0ZWR0Og0KSSdtIHZlcnkgbXVjaCBpbnRlcmVzdGVkIHRv IGZpbmQgYSBzb2x1dGlvbiB3aXRoaW4gdGhlIE9BdXRoIHJlYWxtIGFzDQpJJ20gbm90IGludGVy ZXN0ZWQgdG8gZWl0aGVyIGltcGxlbWVudCB0d28gc29sdXRpb25zIChmb3IgT3BlbklkDQogICBD b25uZWN0DQphbmQgT0F1dGgpIG9yIGFkb3B0IGEgT3BlbklkLXNwZWNpZmljIHNvbHV0aW9uIHRv IE9BdXRoICh1c2UgaWQhDQogICB0b2tlbnMNCmluIHRoZSBmcm9udCBjaGFubmVsKS4gSSB0aGVy ZWZvcmUgd291bGQgbGlrZSB0byBzZWUgcHJvZ3Jlc3MgYW5kDQpwcm9wb3NlIHRvIGNvbnRpbnVl IHRoZSBkaXNjdXNzaW9uIHJlZ2FyZGluZyBtaXRpZ2F0aW9ucyBmb3IgYm90aA0KICAgdGhyZWF0 cy4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtbWl4LXVw LW1pdGlnYXRpb24tMDANCnByb3Bvc2VzIHJlYXNvbmFibGUgbWl0aWdhdGlvbnMgZm9yIGJvdGgg YXR0YWNrcy4gVGhlcmUgYXJlDQogICBhbHRlcm5hdGl2ZXMNCmFzIHdlbGw6DQotIG1peCB1cDoN Ci0tIEFTIHNwZWNpZmljIHJlZGlyZWN0IHVyaXMNCi0tIE1ldGEgZGF0YS90dXJpDQooaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDcjc2VjdGlv bi01KQ0KLSBDblA6DQotLSB1c2Ugb2YgdGhlIG5vbmNlIHBhcmFtZXRlciAoYXMgYSBkaXN0aW5j dCBtaXRpZ2F0aW9uIGJlc2lkZQ0KICAgc3RhdGUgZm9yDQpjb3VudGVyIFhTUkYpDQoNCkZyb20g b3VyIGZvcm1hbCBhbmFseXNpcyBvZiBPQXV0aCB3ZSBhcmUgcHJldHR5IGNvbmZpZGVudCB0aGF0 IHRoZQ0KICAgbWl0aWdhdGlvbiBwcm9wb3NlZCBpbiBkcmFmdC1pZXRmLW9hdXRoLW1peC11cC1t aXRpZ2F0aW9uLTAwIHNob3VsZCBiZQ0KICAgc3VmZmljaWVudCBhZ2FpbnN0IHRoZSBNaXgtVXAg YXR0YWNrLg0KDQogICBDaGVlcnMsDQogICBEYW5pZWwNCg0KDQogICAtLQ0KICAgSW5mb3JtYXRp b25zc2ljaGVyaGVpdCB1bmQgS3J5cHRvZ3JhZmllDQogICBVbml2ZXJzaXTDpHQgVHJpZXIgLSBU ZWwuIDA2NTEgMjAxIDI4NDcgLSBINDM2DQoNCiAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogICBPQXV0aCBtYWlsaW5nIGxpc3QNCiAgIE9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4gPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCiAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KLS0NCk5hdCBT YWtpbXVyYQ0KQ2hhaXJtYW4gb2YgdGhlIEJvYXJkLCBPcGVuSUQgRm91bmRhdGlvbg0KVHJ1c3Rl ZSwgS2FudGFyYSBJbml0aWF0aXZlDQoNCg0KLS0NCkluZm9ybWF0aW9uc3NpY2hlcmhlaXQgdW5k IEtyeXB0b2dyYWZpZQ0KVW5pdmVyc2l0w6R0IFRyaWVyIC0gVGVsLiAwNjUxIDIwMSAyODQ3IC0g SDQzNg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_CAE14AB37A684F2AB73DFC98DBBBEE96adobecom_ Content-Type: text/html; charset="utf-8" Content-ID: <7A6B5F0FEDBDDD47924813334C3C966F@namprd02.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdj5oaSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQpGV0lXIEZhY2Vib29rIGlzIG5vdCB0aGUgb25seSBvbmUgaGVyZS4NCjxkaXY+TWFueSBP QXV0aCBwcm92aWRlciBkbyBub3QgZG8gZXhhY3QgbWF0Y2hpbmcgcmVkaXJlY3QgdXJpIHZhbGlk YXRpb24uIEdpdGh1YiBmb3IgZXhhbXBsZSBpcyBhbm90aGVy4oCmLjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+cmVnYXJkczwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+YW50 b25pbzwvZGl2Pg0KPGRpdj48YnI+DQo8ZGl2Pg0KPGRpdj5PbiBNYXkgMTAsIDIwMTYsIGF0IDEw OjIzIEFNLCBEYW5pZWwgRmV0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZldHRAdW5pLXRyaWVyLmRl Ij5mZXR0QHVuaS10cmllci5kZTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBs ZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBz dHlsZT0iZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5l LWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsiPg0KSXQgZG9lcyBub3Qgd29yayBpZiB0aGUgQVMgZG9lcyBub3QgY2hlY2sgdGhlIHJl ZGlyZWN0IFVSSSBjb21wbGV0ZWx5Ljxicj4NCkZhY2Vib29rIGJlaW5nIHRoZSBtYWluIGV4YW1w bGUgaGVyZSwgYW5kIEkgZ3Vlc3MgdGhleSB3b24ndCBjaGFuZ2UgdGhpczxicj4NCnNvb24gKGZv ciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSkuIEFkZGluZyB0aGUgaXNzIHBhcmFtZXRlciB3b24n dCBicmVhazxicj4NCnRoaW5ncy48YnI+DQo8YnI+DQotRGFuaWVsPGJyPg0KPGJyPg0KQW0gMDku MDUuMjAxNiB1bSAwNTo0NSBzY2hyaWViIE5hdCBTYWtpbXVyYTo8YnI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj5IaSBEYW5pZWwsPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4NCk1heSBJIGFzayBhZ2FpbiB3aHkgc2VwYXJhdGUgcmVk aXJlY3QgdXJpIHdvdWxkIG5vdCB3b3JrIGZvciBtaXgtdXA/PHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCihJIGtub3csIGl0IGRvZXMgbm90IHdv cmsgZm9yIGN1dC1uLXBhc3RlLik8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KPGJyPg0KVGhhbmtzLDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpOYXQ8YnI+DQo8YnI+DQoyMDE25bm0 NeaciDXml6Uo5pyoKSAyMzoyOCBEYW5pZWwgRmV0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZldHRA dW5pLXRyaWVyLmRlIj5mZXR0QHVuaS10cmllci5kZTwvYT48YnI+DQombHQ7PGEgaHJlZj0ibWFp bHRvOmZldHRAdW5pLXRyaWVyLmRlIj5tYWlsdG86ZmV0dEB1bmktdHJpZXIuZGU8L2E+Jmd0OyZn dDs6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7QW0gMjMuMDQuMjAxNiB1bSAxMzo0NyBz Y2hyaWViIFRvcnN0ZW4gTG9kZGVyc3RlZHQ6PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ SSdtIHZlcnkgbXVjaCBpbnRlcmVzdGVkIHRvIGZpbmQgYSBzb2x1dGlvbiB3aXRoaW4gdGhlIE9B dXRoIHJlYWxtIGFzPGJyPg0KSSdtIG5vdCBpbnRlcmVzdGVkIHRvIGVpdGhlciBpbXBsZW1lbnQg dHdvIHNvbHV0aW9ucyAoZm9yIE9wZW5JZDxicj4NCjwvYmxvY2txdW90ZT4NCiZuYnNwOyZuYnNw OyZuYnNwO0Nvbm5lY3Q8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5hbmQgT0F1dGgpIG9y IGFkb3B0IGEgT3BlbklkLXNwZWNpZmljIHNvbHV0aW9uIHRvIE9BdXRoICh1c2UgaWQhPGJyPg0K PC9ibG9ja3F1b3RlPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7dG9rZW5zPGJyPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+aW4gdGhlIGZyb250IGNoYW5uZWwpLiBJIHRoZXJlZm9yZSB3b3VsZCBsaWtl IHRvIHNlZSBwcm9ncmVzcyBhbmQ8YnI+DQpwcm9wb3NlIHRvIGNvbnRpbnVlIHRoZSBkaXNjdXNz aW9uIHJlZ2FyZGluZyBtaXRpZ2F0aW9ucyBmb3IgYm90aDxicj4NCjwvYmxvY2txdW90ZT4NCiZu YnNwOyZuYnNwOyZuYnNwO3RocmVhdHMuPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt bWl4LXVwLW1pdGlnYXRpb24tMDAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW9hdXRoLW1peC11cC1taXRpZ2F0aW9uLTAwPC9hPjxicj4NCnByb3Bvc2VzIHJlYXNvbmFi bGUgbWl0aWdhdGlvbnMgZm9yIGJvdGggYXR0YWNrcy4gVGhlcmUgYXJlPGJyPg0KPC9ibG9ja3F1 b3RlPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7YWx0ZXJuYXRpdmVzPGJyPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+YXMgd2VsbDo8YnI+DQotIG1peCB1cDo8YnI+DQotLSBBUyBzcGVjaWZpYyByZWRp cmVjdCB1cmlzPGJyPg0KLS0gTWV0YSBkYXRhL3R1cmk8YnI+DQooPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDcjc2VjdGlvbi01 Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0w NyNzZWN0aW9uLTU8L2E+KTxicj4NCi0gQ25QOjxicj4NCi0tIHVzZSBvZiB0aGUgbm9uY2UgcGFy YW1ldGVyIChhcyBhIGRpc3RpbmN0IG1pdGlnYXRpb24gYmVzaWRlPGJyPg0KPC9ibG9ja3F1b3Rl Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7c3RhdGUgZm9yPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+Y291bnRlciBYU1JGKTxicj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPkZyb20gb3VyIGZvcm1hbCBhbmFseXNpcyBvZiBPQXV0aCB3ZSBhcmUgcHJldHR5 IGNvbmZpZGVudCB0aGF0IHRoZTxicj4NCjwvYmxvY2txdW90ZT4NCiZuYnNwOyZuYnNwOyZuYnNw O21pdGlnYXRpb24gcHJvcG9zZWQgaW4gZHJhZnQtaWV0Zi1vYXV0aC1taXgtdXAtbWl0aWdhdGlv bi0wMCBzaG91bGQgYmU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtzdWZmaWNpZW50IGFnYWluc3Qg dGhlIE1peC1VcCBhdHRhY2suPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Q2hlZXJzLDxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwO0RhbmllbDxicj4NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOy0tPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7SW5mb3JtYXRpb25zc2ljaGVyaGVpdCB1 bmQgS3J5cHRvZ3JhZmllPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VW5pdmVyc2l0w6R0IFRyaWVy IC0gVGVsLiAwNjUxIDIwMSAyODQ3IC0gSDQzNjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNw O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0OzxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyI+bWFpbHRvOk9BdXRoQGlldGYub3JnPC9hPiZndDs8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PC9hPjxicj4NCjxicj4NCi0tPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxicj4NCk5hdCBTYWtpbXVyYTxicj4NCkNoYWlybWFuIG9mIHRoZSBCb2FyZCwg T3BlbklEIEZvdW5kYXRpb248YnI+DQpUcnVzdGVlLCBLYW50YXJhIEluaXRpYXRpdmU8YnI+DQo8 L2Jsb2NrcXVvdGU+DQo8YnI+DQo8YnI+DQotLTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpJbmZvcm1hdGlvbnNzaWNoZXJoZWl0IHVuZCBLcnlw dG9ncmFmaWU8YnI+DQpVbml2ZXJzaXTDpHQgVHJpZXIgLSBUZWwuIDA2NTEgMjAxIDI4NDcgLSBI NDM2PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGg8L2E+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CAE14AB37A684F2AB73DFC98DBBBEE96adobecom_-- From nobody Mon May 16 23:37:58 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC5A12D596 for ; Mon, 16 May 2016 23:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wD9SDcDy05hp for ; Mon, 16 May 2016 23:37:54 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5211112D0CD for ; Mon, 16 May 2016 23:37:54 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id n63so3439931qkf.0 for ; Mon, 16 May 2016 23:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=exlSHmfhZoxEqOce24RoHrrl0rLRhp4vr9PLiqFNaIs=; b=JjfKb5ohT7AW0eGg1BXN5v1a1Vr7VjluYfMZ5a3HdH1UrwcXFsocUZYIn4+7OMaEbE tB1S/xQqQZsvkatb7HeQKdkQDp3tycq/9ZsMPYltkVDvhtcm2wueKvTz6ukx/PwNaxx+ fu3zjXcIBVUf/kmPUpFNO/NGBEvR4gleGLvlR+oyinxG6x6UceJKbaaChd59C9Nz5WlY TN6gV0af2sbLZIT4Cbqx4WNsvcw3hqnEvpXw4w9W+BXBXMde8+aFh86HFK4AdTu+ZOMy bs2DhedhIV4FF7BCjdwS2tIXuSUV5KD30SgsPD9lVdcJZtceEBr+PQjPXSKxzF8z2g1b HCLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=exlSHmfhZoxEqOce24RoHrrl0rLRhp4vr9PLiqFNaIs=; b=K6ZbtuR+EjsYG+9yH0CbgOlD69LIQxOd9vZIR4ep2Kf5jxjwNOpwiC1SZttg0LcN4A 26QxWGDD0F68OZIFuDWpT0qeeqvuvgCo7BEF+SRGsknc0c0dcALmoEAakNK0Hm6HJSa5 i5b8I0rYng0x+gOl5nsiQqZlF8PB2iT9ziKs8EcWcAqd3PT3Bq+lLdTrsNT1/P600IyX X6ziHcMdyw3qBiwhr1V/gHxX5Q3wLrw0M7mv7tlDSOlJbYbDRH3yvA1oNDB8a8rtY3Jm hlaZTLPas1taGiObhDF6fBat52Mi2fV8VLs+tSpUZ0BTpg4Ww+ShIi/oa8/utEz60uAD wNHA== X-Gm-Message-State: AOPr4FVWXa15bfDgVDJ0f+SKpSxAd6T0+DZ0BsUH3AZxJE5zblfhqZ7eTEdc+DofGfI5/27y31vglYf6srm4qg== X-Received: by 10.55.75.144 with SMTP id y138mr34723511qka.96.1463467073430; Mon, 16 May 2016 23:37:53 -0700 (PDT) MIME-Version: 1.0 References: <571B60BA.8090301@lodderstedt.net> <572B56BB.9080903@uni-trier.de> <57319A8C.3070408@uni-trier.de> In-Reply-To: From: Nat Sakimura Date: Tue, 17 May 2016 06:37:43 +0000 Message-ID: To: Antonio Sanso , Daniel Fett Content-Type: multipart/alternative; boundary=001a114a80780d6bc9053303fb7a Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mix-Up and CnP/ Code injection X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 06:37:56 -0000 --001a114a80780d6bc9053303fb7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We knew that's a bad practice and causes woes that OIDC mandated exact match before the completion of OAuth. I wish we have insisted more on it. Oh, well. On Tue, May 17, 2016 at 15:34 Antonio Sanso wrote: > hi, > > FWIW Facebook is not the only one here. > Many OAuth provider do not do exact matching redirect uri validation. > Github for example is another=E2=80=A6. > > regards > > antonio > > On May 10, 2016, at 10:23 AM, Daniel Fett wrote: > > It does not work if the AS does not check the redirect URI completely. > Facebook being the main example here, and I guess they won't change this > soon (for backwards compatibility). Adding the iss parameter won't break > things. > > -Daniel > > Am 09.05.2016 um 05:45 schrieb Nat Sakimura: > > Hi Daniel, > > May I ask again why separate redirect uri would not work for mix-up? > (I know, it does not work for cut-n-paste.) > > Thanks, > > Nat > > 2016=E5=B9=B45=E6=9C=885=E6=97=A5(=E6=9C=A8) 23:28 Daniel Fett >>: > > Am 23.04.2016 um 13:47 schrieb Torsten Lodderstedt: > > I'm very much interested to find a solution within the OAuth realm as > I'm not interested to either implement two solutions (for OpenId > > Connect > > and OAuth) or adopt a OpenId-specific solution to OAuth (use id! > > tokens > > in the front channel). I therefore would like to see progress and > propose to continue the discussion regarding mitigations for both > > threats. > > > https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00 > proposes reasonable mitigations for both attacks. There are > > alternatives > > as well: > - mix up: > -- AS specific redirect uris > -- Meta data/turi > (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5) > - CnP: > -- use of the nonce parameter (as a distinct mitigation beside > > state for > > counter XSRF) > > > From our formal analysis of OAuth we are pretty confident that the > > mitigation proposed in draft-ietf-oauth-mix-up-mitigation-00 should be > sufficient against the Mix-Up attack. > > Cheers, > Daniel > > > -- > Informationssicherheit und Kryptografie > Universit=C3=A4t Trier - Tel. 0651 201 2847 - H436 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > -- > Nat Sakimura > Chairman of the Board, OpenID Foundation > Trustee, Kantara Initiative > > > > -- > Informationssicherheit und Kryptografie > Universit=C3=A4t Trier - Tel. 0651 201 2847 - H436 > > _______________________________________________ > OAuth mailing 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 Chairman of the Board, OpenID Foundation Trustee, Kantara Initiative --001a114a80780d6bc9053303fb7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We knew that's a bad practice and causes woes that OIDC mandated exact = match before the completion of OAuth. I wish we have insisted more on it. O= h, well.
    On Tue, May 17, 20= 16 at 15:34 Antonio Sanso <asanso@ad= obe.com> wrote:
    hi,

    FWIW Facebook is not the only one here.
    Many OAuth provider do not do exact matching redirect uri validation. = Github for example is another=E2=80=A6.

    regards

    antonio

    On May 10, 2016, at 10:23 AM, Daniel Fett <fett@uni-trier.de> wrote:

    It does not work if the AS does not check the redirect URI completely.
    Facebook being the main example here, and I guess they won't change thi= s
    soon (for backwards compatibility). Adding the iss parameter won't brea= k
    things.

    -Daniel

    Am 09.05.2016 um 05:45 schrieb Nat Sakimura:
    Hi Daniel,=C2=A0

    May I ask again why separate redirect uri would not work for mix-up?= =C2=A0
    (I know, it does not work for cut-n-paste.)=C2=A0

    Thanks,=C2=A0

    Nat

    2016=E5=B9=B45=E6=9C=885=E6=97=A5(=E6=9C=A8) 23:28 Daniel Fett <fett@uni-trier.de
    <mailto:fett@uni-= trier.de>>:

    =C2=A0=C2=A0=C2=A0Am 23.04.2016 um 13:47 schrieb Torsten Lodderstedt:
    I'm very much interested to find a solution w= ithin the OAuth realm as
    I'm not interested to either implement two solutions (for OpenId
    =C2=A0=C2=A0=C2=A0Connect
    and OAuth) or adopt a OpenId-specific solution to= OAuth (use id!
    =C2=A0=C2=A0=C2=A0tokens
    in the front channel). I therefore would like to = see progress and
    propose to continue the discussion regarding mitigations for both
    =C2=A0=C2=A0=C2=A0threats.

    https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mi= tigation-00
    proposes reasonable mitigations for both attacks. There are
    =C2=A0=C2=A0=C2=A0alternatives
    as well:
    - mix up:
    -- AS specific redirect uris
    -- Meta data/turi
    (https://tools.ietf.org/html/draft-sakimura-oauth-met= a-07#section-5)
    - CnP:
    -- use of the nonce parameter (as a distinct mitigation beside
    =C2=A0=C2=A0=C2=A0state for
    counter XSRF)

    From our formal analysis of OAuth we are pretty c= onfident that the
    =C2=A0=C2=A0=C2=A0mitigation proposed in draft-ietf-oauth-mix-up-mitigation= -00 should be
    =C2=A0=C2=A0=C2=A0sufficient against the Mix-Up attack.

    =C2=A0=C2=A0=C2=A0Cheers,
    =C2=A0=C2=A0=C2=A0Daniel


    =C2=A0=C2=A0=C2=A0--
    =C2=A0=C2=A0=C2=A0Informationssicherheit und Kryptografie
    =C2=A0=C2=A0=C2=A0Universit=C3=A4t Trier - Tel. 0651 201 2847 - H436

    =C2=A0=C2=A0=C2=A0_______________________________________________
    =C2=A0=C2=A0=C2=A0OAuth mailing list
    =C2=A0=C2=A0=C2=A0OAuth= @ietf.org=C2=A0<mailto:OAuth@ietf.org>
    =C2=A0=C2=A0=C2=A0https://www.ietf.org/mailman/listinfo/oauth

    --=C2=A0
    Nat Sakimura
    Chairman of the Board, OpenID Foundation
    Trustee, Kantara Initiative


    --=C2=A0
    Informationssicherheit und Kryptografie
    Universit=C3=A4t Trier - Tel. 0651 201 2847 - H436

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --
    Nat Sakimura
    Chairma= n of the Board, OpenID Foundation
    Trustee, Kantara Initiative
    --001a114a80780d6bc9053303fb7a-- From nobody Tue May 17 00:56:37 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA1012D73F for ; Tue, 17 May 2016 00:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 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_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=alexbilbie-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwG7J0JJihgB for ; Tue, 17 May 2016 00:56:27 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8453312D71E for ; Tue, 17 May 2016 00:56:27 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id y84so3302273lfc.0 for ; Tue, 17 May 2016 00:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alexbilbie-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=GXqYyA7f5+QIC889M+FzLc8bX2xHTECsbfwLA2uRPfA=; b=t5i34t4RFGIV+NcE6Nfv4Nde70XlNrnIGbFG9i60q4KsnY1E6dtuDnDcgCJS3V/W8b 4ep8fa8YqIHHr3noo+6cl0s325SGL4MSAehRGUaMeCnDSsjaZwEQWSVh8RlkJj6K+lkr vnc6CGPuAtzU++6vSNyz1BQppC0qBJWeFjOf4QuVWFMy+aOTUCbEvKy2od+wHFg4FCpv lYo3E5ftyXdzFbyfJDHw7V/wzTuThrolUU6/oXVED42wMP521+XYPK5jiYQQ3A4VWsC4 TQM52DqHz6RF15kyPfMcjJsIF9iqZxSMkADiJ8BXD+eoHA8WGu9aRvfeab7RXfKAADKD P04g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=GXqYyA7f5+QIC889M+FzLc8bX2xHTECsbfwLA2uRPfA=; b=kZuaR9q7XWT82KzNn5SGDJZoO4iX2lUenaD9t/NpZ81d4O57bYRFetWLWSck5WlRql tfAJlIN6Jqvu6mgp70WrJsBlcrrKpKhAp8ZSuFYyg+sLpHprXtTYqvBKf+EvxVJzUriK j7BkuftsPeGQnDCVPe3frYA7dmdV2LYPwduUKwOr2SDaEk1LoSQHEzVH9BPdx4EB3038 0GpfAiH9Y/16LfmXk9mxtbGVHSsFeOV5Em6aN02MFuGck7fDmmAVpPiknxSUPZuO4lCw iLO2H6b6vNEjVOq3sN6+g0AtcR1hP4leoaE/tvd2fbvO41EecJuYHJ4DxGY+VGWPY/sA NPxw== X-Gm-Message-State: AOPr4FUIHixJcNpFKQZWJqZY1/6XEkAV6DEMmvng1p0ED7fLSwuirjUdPyOqIl8SNkg8x75LoEloevFUvMCt7g== X-Received: by 10.25.18.215 with SMTP id 84mr13447423lfs.154.1463471785696; Tue, 17 May 2016 00:56:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Alex Bilbie Date: Tue, 17 May 2016 07:56:15 +0000 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a11408212ecf5070533051321 Archived-At: Subject: Re: [OAUTH-WG] poll url in draft-ietf-oauth-device-flow-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 07:56:34 -0000 --001a11408212ecf5070533051321 Content-Type: text/plain; charset=UTF-8 > Is there a github repo or something similar that I could send pull requests to? I too have been wondering how to contribute proposed changes to specifications? Thanks, Alex On Tue, 17 May 2016 at 05:51 Samuel Erdtman wrote: > Hi, > > I just manage to take the time to read this document and in general I like > it a lot I think it fills a gap and with mapping to CBOR, and CoAP it will > work well for more constrained deceive too. > > There are several details that would be great to address such as IANA > section more thorough descriptions of device_code and user_code and It > would also be good with more examples e.g. a poll example. > > The above things one can figure out relatively easy but how and where are > poll requests sent. Is it new post requests to the token endpoint with the > device_code included; or is it get requests to the token endpoint with the > device_code; or is it a completely different endpoint? > A solution that I would like is to have a poll url instead of the > device_code then the client does not need to know how to construct the poll > url form the device_code. > > Is there a github repo or something similar that I could send pull > requests to? > > Best regards > //Samuel > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11408212ecf5070533051321 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    >=C2=A0Is there a github repo or something similar that= I could send pull requests to?

    I too have been wond= ering how to contribute proposed changes to specifications?

    <= /div>
    Thanks,

    Alex

    On Tue, 17 May 2016 at 05:51 Samuel Erdtman <<= a href=3D"mailto:samuel@erdtman.se">samuel@erdtman.se> wrote:
    Hi,

    I just manage to take the time to read this document= and in general I like it a lot I think it fills a gap and with mapping to = CBOR, and CoAP it will work well for more constrained deceive too.

    <= /div>There are several details that would be great to address such as IANA = section more thorough descriptions of device_code and user_code and It woul= d also be good with more examples e.g. a poll example.

    The abo= ve things one can figure out relatively easy but how and where are poll req= uests sent. Is it new post requests to the token endpoint with the device_c= ode included; or is it get requests to the token endpoint with the device_c= ode; or is it a completely different endpoint?
    A solution th= at I would like is to have a poll url instead of the device_code then the c= lient does not need to know how to construct the poll url form the device_c= ode.

    Is there a github repo or something similar that I= could send pull requests to?

    Best regards
    //Samuel
    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --001a11408212ecf5070533051321-- From nobody Tue May 17 06:22:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C2D12B024 for ; Tue, 17 May 2016 06:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8b5kj5BxWoE for ; Tue, 17 May 2016 06:22:17 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F60C12D5AE for ; Tue, 17 May 2016 06:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SP4wtyv36B3BksavG37RIW7d6HFiPzipc65VQUNS3iY=; b=Cbq88+MbhMZwoeWXk8dA4tKFzGzPjd42Yc0eAsczVSOhtbmN1/u1vRkSXweM60aFiuueAftg9VOfCl6vDdEzfxk9iSguJmRSp/EetM+yASvMLmKrge/yR6bcydv+XI4AlA8zUsdYtGJt5iXZ7v18MdGTGhETliYFMHQZUxTNRA8= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1647.namprd03.prod.outlook.com (10.162.130.141) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 17 May 2016 13:22:15 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0497.019; Tue, 17 May 2016 13:22:15 +0000 From: Mike Jones To: Alex Bilbie , Samuel Erdtman , "" Thread-Topic: [OAUTH-WG] poll url in draft-ietf-oauth-device-flow-01 Thread-Index: AQHRr/fMFruk9SH6mEejZWgidZAsKZ+8wzyAgABaN8A= Date: Tue, 17 May 2016 13:22:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alexbilbie.com; dkim=none (message not signed) header.d=none;alexbilbie.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [71.60.14.143] x-ms-office365-filtering-correlation-id: 1724c972-32ed-43eb-e641-08d37e56437b x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1647; 5:Z6Gymfkfmw6SGkBju5AXflvyCOYDDqkxBRR9BlC7KW6kUUi859b5dELlr7PoOVVPcsAvKQsotEbfyTjrjAEdHbxM5dFEvv5rq1FfiHNTySCQp+8x+5ij46QF3JimcRicGAf+yIhLsbIvbSpObFUFPg==; 24:O0/SPkSn81eV/9CeuEC1Aej+gAuBTv+0NFpObrwrFFOqkvWeFHcyk5WA3+BxR4H/fiK+eII5ekpb0FMUvo2fnYyeWzV012WROgGr2AyFhWI=; 7:SAFkX5BMRasdSn7TgWgJnZ9x/9igLU2fuIf/o8TAEhTuSGUoeMVXObmBA17GUF3gXX120KYSN6IUbYOwBUVw44zqkDMR5QUeo/lFx/3b/YsFBtaxYCve+f0uySphj/WT+9CQJ2ItGv3MGcNcVLwuGGJ6JcmVaz7zIBvNBX7vJ3tUkuE88YVN9V9/xbAMuvfqLBwQMMK+eycLt3A6q8JdDg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1647; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1647; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1647; x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(51414003)(19609705001)(3280700002)(6116002)(107886002)(102836003)(790700001)(16236675004)(3846002)(76576001)(5002640100001)(99286002)(19580395003)(19580405001)(8990500004)(230783001)(92566002)(3660700001)(5003600100002)(11100500001)(5001770100001)(10400500002)(5005710100001)(10290500002)(5008740100001)(2906002)(106116001)(15975445007)(87936001)(77096005)(586003)(81166006)(33656002)(74316001)(2950100001)(5004730100002)(1220700001)(19625215002)(122556002)(54356999)(76176999)(50986999)(9686002)(561944003)(86362001)(66066001)(189998001)(8676002)(19300405004)(19617315012)(8936002)(2900100001)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1647; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16458BE54F29C53FE3BAB01FF5480SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 13:22:15.0414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1647 Archived-At: Subject: Re: [OAUTH-WG] poll url in draft-ietf-oauth-device-flow-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 13:22:19 -0000 --_000_SN1PR0301MB16458BE54F29C53FE3BAB01FF5480SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIG5vdywgSeKAmWQgc3VnZ2VzdCBjb250cmlidXRpbmcgdGhlIHVzdWFsIHdheSDigJMgd3Jp dGluZyB1cCBhIHByb3Bvc2FsIHRvIHRoZSB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBmb3Ig ZGlzY3Vzc2lvbiBieSB0aGUgd29ya2luZyBncm91cC4gIFRoZSBlZGl0b3JzIGNhbiB0aGVuIHJl dmlzZSB0aGUgZHJhZnQgYWZ0ZXIgdGhlcmXigJlzIGFwcGFyZW50IGNvbnNlbnN1cyB0byBkbyBz byBpbiBhIHBhcnRpY3VsYXIgd2F5Lg0KDQpUaGFua3MgZm9yIHRha2luZyB0aGUgdGltZSB0byBk byB5b3VyIHJldmlld3MsIFNhbXVlbCBhbmQgQWxleC4gIEkgbG9vayBmb3J3YXJkIHRvIHJldmll d2luZyB5b3VyIHByb3Bvc2Fscy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEJlc3Qgd2lzaGVzLA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTog T0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleCBC aWxiaWUNClNlbnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxNiAxMjo1NiBBTQ0KVG86IDxvYXV0aEBp ZXRmLm9yZz4gPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gcG9sbCB1 cmwgaW4gZHJhZnQtaWV0Zi1vYXV0aC1kZXZpY2UtZmxvdy0wMQ0KDQo+IElzIHRoZXJlIGEgZ2l0 aHViIHJlcG8gb3Igc29tZXRoaW5nIHNpbWlsYXIgdGhhdCBJIGNvdWxkIHNlbmQgcHVsbCByZXF1 ZXN0cyB0bz8NCg0KSSB0b28gaGF2ZSBiZWVuIHdvbmRlcmluZyBob3cgdG8gY29udHJpYnV0ZSBw cm9wb3NlZCBjaGFuZ2VzIHRvIHNwZWNpZmljYXRpb25zPw0KDQpUaGFua3MsDQoNCkFsZXgNCg0K T24gVHVlLCAxNyBNYXkgMjAxNiBhdCAwNTo1MSBTYW11ZWwgRXJkdG1hbiA8c2FtdWVsQGVyZHRt YW4uc2U8bWFpbHRvOnNhbXVlbEBlcmR0bWFuLnNlPj4gd3JvdGU6DQpIaSwNCkkganVzdCBtYW5h Z2UgdG8gdGFrZSB0aGUgdGltZSB0byByZWFkIHRoaXMgZG9jdW1lbnQgYW5kIGluIGdlbmVyYWwg SSBsaWtlIGl0IGEgbG90IEkgdGhpbmsgaXQgZmlsbHMgYSBnYXAgYW5kIHdpdGggbWFwcGluZyB0 byBDQk9SLCBhbmQgQ29BUCBpdCB3aWxsIHdvcmsgd2VsbCBmb3IgbW9yZSBjb25zdHJhaW5lZCBk ZWNlaXZlIHRvby4NClRoZXJlIGFyZSBzZXZlcmFsIGRldGFpbHMgdGhhdCB3b3VsZCBiZSBncmVh dCB0byBhZGRyZXNzIHN1Y2ggYXMgSUFOQSBzZWN0aW9uIG1vcmUgdGhvcm91Z2ggZGVzY3JpcHRp b25zIG9mIGRldmljZV9jb2RlIGFuZCB1c2VyX2NvZGUgYW5kIEl0IHdvdWxkIGFsc28gYmUgZ29v ZCB3aXRoIG1vcmUgZXhhbXBsZXMgZS5nLiBhIHBvbGwgZXhhbXBsZS4NClRoZSBhYm92ZSB0aGlu Z3Mgb25lIGNhbiBmaWd1cmUgb3V0IHJlbGF0aXZlbHkgZWFzeSBidXQgaG93IGFuZCB3aGVyZSBh cmUgcG9sbCByZXF1ZXN0cyBzZW50LiBJcyBpdCBuZXcgcG9zdCByZXF1ZXN0cyB0byB0aGUgdG9r ZW4gZW5kcG9pbnQgd2l0aCB0aGUgZGV2aWNlX2NvZGUgaW5jbHVkZWQ7IG9yIGlzIGl0IGdldCBy ZXF1ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCB0aGUgZGV2aWNlX2NvZGU7IG9yIGlz IGl0IGEgY29tcGxldGVseSBkaWZmZXJlbnQgZW5kcG9pbnQ/DQpBIHNvbHV0aW9uIHRoYXQgSSB3 b3VsZCBsaWtlIGlzIHRvIGhhdmUgYSBwb2xsIHVybCBpbnN0ZWFkIG9mIHRoZSBkZXZpY2VfY29k ZSB0aGVuIHRoZSBjbGllbnQgZG9lcyBub3QgbmVlZCB0byBrbm93IGhvdyB0byBjb25zdHJ1Y3Qg dGhlIHBvbGwgdXJsIGZvcm0gdGhlIGRldmljZV9jb2RlLg0KDQpJcyB0aGVyZSBhIGdpdGh1YiBy ZXBvIG9yIHNvbWV0aGluZyBzaW1pbGFyIHRoYXQgSSBjb3VsZCBzZW5kIHB1bGwgcmVxdWVzdHMg dG8/DQpCZXN0IHJlZ2FyZHMNCi8vU2FtdWVsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQo= --_000_SN1PR0301MB16458BE54F29C53FE3BAB01FF5480SN1PR0301MB1645_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Rm9yIG5vdywgSeKAmWQgc3VnZ2VzdCBj b250cmlidXRpbmcgdGhlIHVzdWFsIHdheSDigJMgd3JpdGluZyB1cCBhIHByb3Bvc2FsIHRvIHRo ZSB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBmb3IgZGlzY3Vzc2lvbiBieSB0aGUgd29ya2lu ZyBncm91cC4mbmJzcDsgVGhlIGVkaXRvcnMgY2FuDQogdGhlbiByZXZpc2UgdGhlIGRyYWZ0IGFm dGVyIHRoZXJl4oCZcyBhcHBhcmVudCBjb25zZW5zdXMgdG8gZG8gc28gaW4gYSBwYXJ0aWN1bGFy IHdheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoYW5rcyBm b3IgdGFraW5nIHRoZSB0aW1lIHRvIGRvIHlvdXIgcmV2aWV3cywgU2FtdWVsIGFuZCBBbGV4LiZu YnNwOyBJIGxvb2sgZm9yd2FyZCB0byByZXZpZXdpbmcgeW91ciBwcm9wb3NhbHMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQmVzdCB3aXNoZXMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0 aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFs ZXggQmlsYmllPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSAxNywgMjAxNiAxMjo1NiBB TTxicj4NCjxiPlRvOjwvYj4gJmx0O29hdXRoQGlldGYub3JnJmd0OyAmbHQ7b2F1dGhAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIHBvbGwgdXJsIGluIGRy YWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ctMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7SXMgdGhlcmUgYSBnaXRodWIgcmVwbyBvciBzb21ldGhpbmcg c2ltaWxhciB0aGF0IEkgY291bGQgc2VuZCBwdWxsIHJlcXVlc3RzIHRvPzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0b28gaGF2ZSBiZWVuIHdvbmRlcmlu ZyBob3cgdG8gY29udHJpYnV0ZSBwcm9wb3NlZCBjaGFuZ2VzIHRvIHNwZWNpZmljYXRpb25zPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu a3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFsZXg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1 ZSwgMTcgTWF5IDIwMTYgYXQgMDU6NTEgU2FtdWVsIEVyZHRtYW4gJmx0OzxhIGhyZWY9Im1haWx0 bzpzYW11ZWxAZXJkdG1hbi5zZSI+c2FtdWVsQGVyZHRtYW4uc2U8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkganVzdCBtYW5hZ2UgdG8g dGFrZSB0aGUgdGltZSB0byByZWFkIHRoaXMgZG9jdW1lbnQgYW5kIGluIGdlbmVyYWwgSSBsaWtl IGl0IGEgbG90IEkgdGhpbmsgaXQgZmlsbHMgYSBnYXAgYW5kIHdpdGggbWFwcGluZyB0byBDQk9S LCBhbmQgQ29BUCBpdCB3aWxsIHdvcmsgd2VsbCBmb3IgbW9yZSBjb25zdHJhaW5lZCBkZWNlaXZl IHRvby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGVyZSBhcmUgc2V2ZXJhbCBkZXRhaWxzIHRoYXQgd291 bGQgYmUgZ3JlYXQgdG8gYWRkcmVzcyBzdWNoIGFzIElBTkEgc2VjdGlvbiBtb3JlIHRob3JvdWdo IGRlc2NyaXB0aW9ucyBvZiBkZXZpY2VfY29kZSBhbmQgdXNlcl9jb2RlIGFuZCBJdCB3b3VsZCBh bHNvIGJlIGdvb2Qgd2l0aCBtb3JlIGV4YW1wbGVzIGUuZy4gYSBwb2xsIGV4YW1wbGUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhYm92ZSB0aGluZ3Mg b25lIGNhbiBmaWd1cmUgb3V0IHJlbGF0aXZlbHkgZWFzeSBidXQgaG93IGFuZCB3aGVyZSBhcmUg cG9sbCByZXF1ZXN0cyBzZW50LiBJcyBpdCBuZXcgcG9zdCByZXF1ZXN0cyB0byB0aGUgdG9rZW4g ZW5kcG9pbnQgd2l0aCB0aGUgZGV2aWNlX2NvZGUgaW5jbHVkZWQ7IG9yIGlzIGl0IGdldCByZXF1 ZXN0cyB0byB0aGUgdG9rZW4gZW5kcG9pbnQgd2l0aCB0aGUgZGV2aWNlX2NvZGU7DQogb3IgaXMg aXQgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBlbmRwb2ludD8gPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHNvbHV0aW9uIHRoYXQgSSB3b3VsZCBs aWtlIGlzIHRvIGhhdmUgYSBwb2xsIHVybCBpbnN0ZWFkIG9mIHRoZSBkZXZpY2VfY29kZSB0aGVu IHRoZSBjbGllbnQgZG9lcyBub3QgbmVlZCB0byBrbm93IGhvdyB0byBjb25zdHJ1Y3QgdGhlIHBv bGwgdXJsIGZvcm0gdGhlIGRldmljZV9jb2RlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SXMgdGhlcmUg YSBnaXRodWIgcmVwbyBvciBzb21ldGhpbmcgc2ltaWxhciB0aGF0IEkgY291bGQgc2VuZCBwdWxs IHJlcXVlc3RzIHRvPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Ly9TYW11ZWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN1PR0301MB16458BE54F29C53FE3BAB01FF5480SN1PR0301MB1645_-- From nobody Thu May 19 01:26:55 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B3612B05D for ; Thu, 19 May 2016 01:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 9cwZxcE9ynm6 for ; Thu, 19 May 2016 01:26:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E4BA12B03F for ; Thu, 19 May 2016 01:26:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 13661180006; Thu, 19 May 2016 01:26:38 -0700 (PDT) To: dick.hardt@gmail.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160519082638.13661180006@rfc-editor.org> Date: Thu, 19 May 2016 01:26:38 -0700 (PDT) Archived-At: Cc: oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4697) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 08:26:54 -0000 The following errata report has been submitted for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4697 -------------------------------------- Type: Editorial Reported by: Ludwig Seitz Section: 7.1 Original Text ------------- For example, the "bearer" token type defined in [RFC6750] is utilized by simply including the access token string in the request: Corrected Text -------------- For example, the "Bearer" token type defined in [RFC6750] is utilized by simply including the access token string in the request: Notes ----- RFC6750 defines the "Bearer" token type not the "bearer" token type. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Thu May 19 18:22:38 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4015D12B054 for ; Thu, 19 May 2016 18:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 Z9LJX2Bo5gPH for ; Thu, 19 May 2016 18:22:34 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 84DC412B039 for ; Thu, 19 May 2016 18:22:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,336,1459778400"; d="scan'208";a="78674325" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 20 May 2016 11:22:30 +1000 X-IronPort-AV: E=McAfee;i="5700,7163,8170"; a="122140893" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcbni.tcif.telstra.com.au with ESMTP; 20 May 2016 11:22:30 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3704.srv.dir.telstra.com ([fe80::f9cb:6633:4a34:9729%11]) with mapi; Fri, 20 May 2016 11:22:30 +1000 From: "Manger, James" To: RFC Errata System , "ludwig@sics.se" Date: Fri, 20 May 2016 11:22:29 +1000 Thread-Topic: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4697) Thread-Index: AdGxqDfYFB7eDE8YTCC5WRfZfEW1wgAiuqUA Message-ID: <255B9BB34FB7D647A506DC292726F6E13BD1AFA2E8@WSMSG3153V.srv.dir.telstra.com> References: <20160519082638.13661180006@rfc-editor.org> In-Reply-To: <20160519082638.13661180006@rfc-editor.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4697) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 01:22:37 -0000 I suggest this errata be REJECTED as token types are case-insensitive. Each field in RFC6749 that takes a token type explicitly says the value is = case insensitive. 4.2.2. Access Token Response token_type REQUIRED. The type of the token issued as described in Section 7.1. Value is case insensitive. 5.1. Successful Response token_type REQUIRED. The type of the token issued as described in Section 7.1. Value is case insensitive. When used as an HTTP authentication scheme name it is also case insensitive= . From RFC7235 "HTTP/1.1 Authentication": 2.1. Challenge and Response ... It uses a case-insensitive token as a means to identify the authent= ication scheme, -- James Manger -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of RFC Errata System Sent: Thursday, 19 May 2016 6:27 PM To: dick.hardt@gmail.com; stephen.farrell@cs.tcd.ie; Kathleen.Moriarty.ietf= @gmail.com; Hannes.Tschofenig@gmx.net; derek@ihtfp.com Cc: oauth@ietf.org; rfc-editor@rfc-editor.org Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4697) The following errata report has been submitted for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6749&eid=3D4697 -------------------------------------- Type: Editorial Reported by: Ludwig Seitz Section: 7.1 Original Text ------------- For example, the "bearer" token type defined in [RFC6750] is utilized by simply including the access token string in the request: Corrected Text -------------- For example, the "Bearer" token type defined in [RFC6750] is utilized by simply including the access token string in the request: Notes ----- RFC6750 defines the "Bearer" token type not the "bearer" token type. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Fri May 20 08:08:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2B812D0A3 for ; Fri, 20 May 2016 08:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLQHoo8j1zOS for ; Fri, 20 May 2016 08:08:48 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BC812B018 for ; Fri, 20 May 2016 08:08:48 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id x7so68089475qkd.3 for ; Fri, 20 May 2016 08:08:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DWZiUGpMxltGYptDYUUvA67NfvMzyKX91dBnoyXFOPI=; b=qtyphIbLFthKC74rhxU7PTY47u5iAZJvJTCIbAuJAxYMdaEoeAYrBah81D69C8Oz0H 3dFGv1eeLjSSRYv08kHEg662GJQb6fnyd/obj8mqCM1Gokk4uoZfSAlhn+eWxLE5SrbH I18YL7AX4MA0QXyFEEIll9/qvLSD96RZ+au41ZanIPTUKKby6cdMJETjefguPmrxXkxj BP8jTTKL8+qsaGxcG1xRxf3y3a/4j8c1+1/jnHSCz8BwckKtyjNHDkF9UVe46yw8+Wgv 9lJZ7VhPzW1zOLLYuz9WBZ+DxHgUHQlNmew5q01XbAAi1tGbQi7w2YNPuPVceEXJ/X5t kerA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DWZiUGpMxltGYptDYUUvA67NfvMzyKX91dBnoyXFOPI=; b=QU3c2XA10xQBSROxhhDYuiYe6qAMgyw0ihdoqzj7Ex50py2i2KqJ6oxTRpg1jigNci Ygf5jJRuawT+8Wa3SbpNh2mwrzQhaCDO6f5IXhkcq+ov8ko+GO4rQhwoJLhr3+q5xn3C knN6eLupBp0uL43hsozbjxln8KDCI4o1eonhxf18oiFKFia3chUN/A8wA4JY7X1nLw+t aDx5/SQB9TH6InukXzr2118SbuegrBLUGWQbtskbsE4Cj1qIAVpGTS1cUSfrliCYsdwE hgW/vMK4LBFbrKoWlWMe1/lPFjlKm5MqfYPHwtGp/scAYfnFmr1bG6zheyu4msMoYsmK hNCQ== X-Gm-Message-State: AOPr4FXRKg20qm3majRoF9bHHcTtdsatadHkTtbiYRUwwUCd/EEJDWgAeyvDgRJz8S4aog== X-Received: by 10.55.172.15 with SMTP id v15mr4066228qke.45.1463756927428; Fri, 20 May 2016 08:08:47 -0700 (PDT) Received: from [192.168.1.32] ([191.115.18.39]) by smtp.gmail.com with ESMTPSA id q77sm872190qke.15.2016.05.20.08.08.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 May 2016 08:08:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BD1AFA2E8@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 20 May 2016 11:08:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0538DD61-CFAC-4892-9FA6-22A96D51C205@ve7jtb.com> References: <20160519082638.13661180006@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E13BD1AFA2E8@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "oauth@ietf.org" , RFC Errata System Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4697) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 15:08:51 -0000 Agreed this should be REJECTED. > On May 19, 2016, at 9:22 PM, Manger, James = wrote: >=20 > I suggest this errata be REJECTED as token types are case-insensitive. >=20 > Each field in RFC6749 that takes a token type explicitly says the = value is case insensitive. >=20 > 4.2.2. Access Token Response >=20 > token_type > REQUIRED. The type of the token issued as described in > Section 7.1. Value is case insensitive. >=20 > 5.1. Successful Response >=20 > token_type > REQUIRED. The type of the token issued as described in > Section 7.1. Value is case insensitive. >=20 > When used as an HTTP authentication scheme name it is also case = insensitive. =46rom RFC7235 "HTTP/1.1 Authentication": >=20 > 2.1. Challenge and Response >=20 > ... It uses a case-insensitive token as a means to identify the = authentication scheme, >=20 > -- > James Manger >=20 >=20 >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of RFC Errata = System > Sent: Thursday, 19 May 2016 6:27 PM > To: dick.hardt@gmail.com; stephen.farrell@cs.tcd.ie; = Kathleen.Moriarty.ietf@gmail.com; Hannes.Tschofenig@gmx.net; = derek@ihtfp.com > Cc: oauth@ietf.org; rfc-editor@rfc-editor.org > Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4697) >=20 > The following errata report has been submitted for RFC6749, > "The OAuth 2.0 Authorization Framework". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6749&eid=3D4697 >=20 > -------------------------------------- > Type: Editorial > Reported by: Ludwig Seitz >=20 > Section: 7.1 >=20 > Original Text > ------------- > For example, the "bearer" token type defined in [RFC6750] is utilized > by simply including the access token string in the request: >=20 >=20 > Corrected Text > -------------- > For example, the "Bearer" token type defined in [RFC6750] is utilized > by simply including the access token string in the request: >=20 >=20 > Notes > ----- > RFC6750 defines the "Bearer" token type not the "bearer" token type. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6749 (draft-ietf-oauth-v2-31) > -------------------------------------- > Title : The OAuth 2.0 Authorization Framework > Publication Date : October 2012 > Author(s) : D. Hardt, Ed. > Category : PROPOSED STANDARD > Source : Web Authorization Protocol > Area : Security > Stream : IETF > Verifying Party : IESG >=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 Fri May 20 08:17:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE4B12D9CF for ; Fri, 20 May 2016 08:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-wxHF_Yl-Oe for ; Fri, 20 May 2016 08:17:43 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06E212D9D6 for ; Fri, 20 May 2016 08:17:42 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id bi2so139038830igb.0 for ; Fri, 20 May 2016 08:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=uyuFOZghTSIiLUfKyp5xQ6WZXvSJoTeCl15jLGWNYDY=; b=G2KrP9W0Id1eNTEyP2Yau/JfxfJhnb5dl2Nh50QUGl60ZbWBm7Y5zrLfhzltfKBgeR cT2rUoe1kWeNxTP37F6ooqJXN/whigGCOO16SeZc/vCRfeTXplSS0xi/KBbfDb+D+Om5 8Y5KcH7iTFVHHxQB+KrTPIepR468tO/pjKufA= 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:date :message-id:subject:from:to:cc; bh=uyuFOZghTSIiLUfKyp5xQ6WZXvSJoTeCl15jLGWNYDY=; b=JooH8OObtcojpvH0BJubong97BFJcwcX9gqiKuiFPr5Bh2hUzKHAhUQ6J6iOPBviWl JBGs+2eii519WuYgU80i3Yagf3sIOqUGoMh7O28KBfNJJX584Qn30D9XAOJLNJOxtDSu kL2o3lYjh03du+bRtuH8LMZ161UWCEBX9ZLsMxmjXP2tpitie4DBr/O8ISpDSrDfRZSn Zn8B93tl7ZAQKgLqHQRtGw6u0X0i6JTSfgxdYcXukiaKgA8oFbg0PpWmgUmpgmpTA8XA wqT6fu1kenj+wjsXrFWscjJE1opSwAIuGTV7AbXpIRRfGFBQb01m+g7dCY5CVFWFz6GR xjGA== X-Gm-Message-State: AOPr4FVVwDl8TZQF/1opUKBIIlQvpM8y5vmGokptjlWjy/UIrF8glHBgKdcL8P6EMXdBrmA8FSI9Fy8MvUWTQpO9 MIME-Version: 1.0 X-Received: by 10.50.15.131 with SMTP id x3mr3425484igc.18.1463757462080; Fri, 20 May 2016 08:17:42 -0700 (PDT) Received: by 10.79.105.129 with HTTP; Fri, 20 May 2016 08:17:41 -0700 (PDT) Received: by 10.79.105.129 with HTTP; Fri, 20 May 2016 08:17:41 -0700 (PDT) In-Reply-To: <0538DD61-CFAC-4892-9FA6-22A96D51C205@ve7jtb.com> References: <20160519082638.13661180006@rfc-editor.org> <255B9BB34FB7D647A506DC292726F6E13BD1AFA2E8@WSMSG3153V.srv.dir.telstra.com> <0538DD61-CFAC-4892-9FA6-22A96D51C205@ve7jtb.com> Date: Fri, 20 May 2016 09:17:41 -0600 Message-ID: From: Brian Campbell To: John Bradley Content-Type: multipart/alternative; boundary=14dae9340d9790b036053347979c Archived-At: Cc: "oauth@ietf.org" , RFC Editor Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4697) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 15:17:45 -0000 --14dae9340d9790b036053347979c Content-Type: text/plain; charset=UTF-8 Also agree On May 20, 2016 9:08 AM, "John Bradley" wrote: > Agreed this should be REJECTED. > > > On May 19, 2016, at 9:22 PM, Manger, James < > James.H.Manger@team.telstra.com> wrote: > > > > I suggest this errata be REJECTED as token types are case-insensitive. > > > > Each field in RFC6749 that takes a token type explicitly says the value > is case insensitive. > > > > 4.2.2. Access Token Response > > > > token_type > > REQUIRED. The type of the token issued as described in > > Section 7.1. Value is case insensitive. > > > > 5.1. Successful Response > > > > token_type > > REQUIRED. The type of the token issued as described in > > Section 7.1. Value is case insensitive. > > > > When used as an HTTP authentication scheme name it is also case > insensitive. From RFC7235 "HTTP/1.1 Authentication": > > > > 2.1. Challenge and Response > > > > ... It uses a case-insensitive token as a means to identify the > authentication scheme, > > > > -- > > James Manger > > > > > > > > -----Original Message----- > > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of RFC Errata > System > > Sent: Thursday, 19 May 2016 6:27 PM > > To: dick.hardt@gmail.com; stephen.farrell@cs.tcd.ie; > Kathleen.Moriarty.ietf@gmail.com; Hannes.Tschofenig@gmx.net; > derek@ihtfp.com > > Cc: oauth@ietf.org; rfc-editor@rfc-editor.org > > Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4697) > > > > The following errata report has been submitted for RFC6749, > > "The OAuth 2.0 Authorization Framework". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4697 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Ludwig Seitz > > > > Section: 7.1 > > > > Original Text > > ------------- > > For example, the "bearer" token type defined in [RFC6750] is utilized > > by simply including the access token string in the request: > > > > > > Corrected Text > > -------------- > > For example, the "Bearer" token type defined in [RFC6750] is utilized > > by simply including the access token string in the request: > > > > > > Notes > > ----- > > RFC6750 defines the "Bearer" token type not the "bearer" token type. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC6749 (draft-ietf-oauth-v2-31) > > -------------------------------------- > > Title : The OAuth 2.0 Authorization Framework > > Publication Date : October 2012 > > Author(s) : D. Hardt, Ed. > > Category : PROPOSED STANDARD > > Source : Web Authorization Protocol > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > OAuth mailing 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 > --14dae9340d9790b036053347979c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    Also agree

    On May 20, 2016 9:08 AM, "John Bradley"= ; <ve7jtb@ve7jtb.com> wrote:=
    Agreed this should = be REJECTED.

    > On May 19, 2016, at 9:22 PM, Manger, James <James.H.Manger@team.telstra.com> wrote:<= br> >
    > I suggest this errata be REJECTED as token types are case-insensitive.=
    >
    > Each field in RFC6749 that takes a token type explicitly says the valu= e is case insensitive.
    >
    > 4.2.2. Access Token Response
    >
    >=C2=A0 =C2=A0token_type
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0REQUIRED.=C2=A0 The type of the token= issued as described in
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 7.1.=C2=A0 Value is case inse= nsitive.
    >
    > 5.1. Successful Response
    >
    >=C2=A0 =C2=A0token_type
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0REQUIRED.=C2=A0 The type of the token= issued as described in
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 7.1.=C2=A0 Value is case inse= nsitive.
    >
    > When used as an HTTP authentication scheme name it is also case insens= itive. From RFC7235 "HTTP/1.1 Authentication":
    >
    > 2.1. Challenge and Response
    >
    >=C2=A0 =C2=A0...=C2=A0 It uses a case-insensitive token as a means to i= dentify the authentication scheme,
    >
    > --
    > James Manger
    >
    >
    >
    > -----Original Message-----
    > From: OAuth [mailto:oauth-bo= unces@ietf.org] On Behalf Of RFC Errata System
    > Sent: Thursday, 19 May 2016 6:27 PM
    > To: dick.hardt@gmail.com; = stephen.farrell@cs.tcd.ie;= Kathleen.Moriarty.ietf= @gmail.com; Hannes.Tschofe= nig@gmx.net; derek@ihtfp.com
    > Cc: oauth@ietf.org; rfc-editor@rfc-editor.org
    > Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4697)
    >
    > The following errata report has been submitted for RFC6749,
    > "The OAuth 2.0 Authorization Framework".
    >
    > --------------------------------------
    > You may review the report below and at:
    > http://www.rfc-editor.org/= errata_search.php?rfc=3D6749&eid=3D4697
    >
    > --------------------------------------
    > Type: Editorial
    > Reported by: Ludwig Seitz <ludwig= @sics.se>
    >
    > Section: 7.1
    >
    > Original Text
    > -------------
    > For example, the "bearer" token type defined in [RFC6750] is= utilized
    >=C2=A0 =C2=A0by simply including the access token string in the request= :
    >
    >
    > Corrected Text
    > --------------
    > For example, the "Bearer" token type defined in [RFC6750] is= utilized
    >=C2=A0 =C2=A0by simply including the access token string in the request= :
    >
    >
    > Notes
    > -----
    > RFC6750 defines the "Bearer" token type not the "bearer= " token type.
    >
    > Instructions:
    > -------------
    > This erratum is currently posted as "Reported". If necessary= , please
    > use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party (IESG)
    > can log in to change the status and edit the report, if necessary.
    >
    > --------------------------------------
    > RFC6749 (draft-ietf-oauth-v2-31)
    > --------------------------------------
    > Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The OAut= h 2.0 Authorization Framework
    > Publication Date=C2=A0 =C2=A0 : October 2012
    > Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: D. Hardt, Ed.
    > Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Web Authoriza= tion Protocol
    > Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security=
    > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
    > Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
    >
    > _______________________________________________
    > OAuth mailing 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
    --14dae9340d9790b036053347979c-- From nobody Tue May 31 03:45:36 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0C012D1E6; Tue, 31 May 2016 03:45:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160531104534.15200.25373.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2016 03:45:34 -0700 Archived-At: Cc: oauth-chairs@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] oauth - New Meeting Session Request for IETF 96 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 10:45:35 -0000 A new meeting session request has just been submitted by Hannes Tschofenig, a Chair of the oauth working group. --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Hannes Tschofenig Number of Sessions: 2 Length of Session(s): 1.5 Hours, 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: core cose oauth saag lwig tokbind tls Special Requests: Please avoid conflict with sec area BoFs. Due a person from NIST attending the OAuth meeting could you schedule one OAuth session on Monday or Tuesday and none on Friday? ---------------------------------------------------------
    Nat Sakimura
    Chairma= n of the Board, OpenID Foundation
    Trustee, Kantara Initiative
    --001a1135522a8d8b6d0532982859-- From nobody Wed May 11 15:03:18 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F3812D716 for ; Wed, 11 May 2016 15:03:16 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 555u34bNn2xg for ; Wed, 11 May 2016 15:03:14 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B0E12D5AC for ; Wed, 11 May 2016 15:03:14 -0700 (PDT) Received: by mail-pa0-x22c.google.com with SMTP id iv1so21855462pac.2 for ; Wed, 11 May 2016 15:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=UKaL2i/UZiLq0rbMNtsQ8eu031ySRxgogmcu+A8hTmU=; b=x2udk8zPgA9cS3a00ACC4oOdoQjYn0LUOQOAS1V4/v4XZGj4NhDtFC9sfXb8Ihlc3g KGicd8wWw+p36BMwZg5/QUWwRq27mrb1ebL+Xtw3JEsuboZq0P+2CMPT8U6w51AoyHUi GNSsgxvWRP/4PhoWljLYpOmM5fngGCVEsUjjK3hVU+609ORnFw49agfO8INF1GD6NW6W Q1LWw2OpQ6tX1iHh5UnJHxrDbPn4NHLOB64vpvga+Cz7piWQpZFYFFGwvM/dXym49GT0 Rc22BuiQ9/0XFIc2ns8KleNyCcwsydYuUOJJ08AULoUKZBeswsdmZM0pQBDtu5naYVZQ Frxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=UKaL2i/UZiLq0rbMNtsQ8eu031ySRxgogmcu+A8hTmU=; b=foXgOG/o7G/Q99htkR3e/Zjg0UTkdERpQHJb3n811xMxFvDfXHqkrXkWJsCv422oI1 nVhOk27ypPGmgf1M1Dv6NGySVXzGVVRtzCoWhxFs/6o8QN5Z3wbdUYw631gTJmR+VzMX YH6Tz1B8CkyZviif+voiW+8Ob+oglGbOrO1XYFmHl08H1odlL2FYLDYO9IyQaWlxiiQb S8hTLxFOBs+UTNx89dOyM6MB0LZ0KYCLkRENlAPbpqVHyKgYB8sZbpzuPKPjAUHYX/Zt MT9kCvPx/zyeJ6UQn+hypP4FA6dtPQXfzERz0bkb6iYiQwq10mhSsWbwNF5xLzRHH3gZ dzeg== X-Gm-Message-State: AOPr4FVOshAOcTbOF/k3UJPJYnyG5S+VSPxsDSc1lA/VDwIImu/QbBPEsfm8f8nRLkbl3Juh X-Received: by 10.66.76.74 with SMTP id i10mr8509607paw.31.1463004194087; Wed, 11 May 2016 15:03:14 -0700 (PDT) Received: from heembo.local ([2605:e000:112b:c167:cc24:c1ec:4eee:2c55]) by smtp.googlemail.com with ESMTPSA id to9sm14536106pab.27.2016.05.11.15.03.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2016 15:03:12 -0700 (PDT) To: Nat Sakimura , Daniel Fett , oauth@ietf.org References: <571A33E0.6070401@uni-trier.de> <5730D36A.4050601@gtrs.de> <5731ABD3.2070502@uni-trier.de> From: Jim Manico Message-ID: <4c5efb5d-c1fb-9f24-ed12-bf128520eb24@manicode.com> Date: Wed, 11 May 2016 12:03:10 -1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8A61D79B854E214E83ABACC8" Archived-At: Subject: Re: [OAUTH-WG] Multi-AS State Re-Use X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 22:03:17 -0000 This is a multi-part message in MIME format. --------------8A61D79B854E214E83ABACC8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Well hey now. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet is one of the more popular resources on CSRF at OWASP. https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) is also pretty popular and points to a wide variety of resources on the topic. If anyone sees any flaws in these or otherwise would like to help make these better, please drop me a line. I serve on the OWASP board. Aloha, Jim Manico On 5/11/16 11:59 AM, Nat Sakimura wrote: > Agreed. Also, pointing to OWASP guide or something for CSRF token may > be useful. > On Tue, May 10, 2016 at 11:37 Daniel Fett > wrote: > > Regardless of what state actually is, the documentation (also the one > for OIDC) should make clear that the same state should not be sent to > two different AS, and that a state issued for AS #1 should be invalid > for AS #2. > > Am 10.05.2016 um 09:31 schrieb Anthony Nadalin: > > STATE can be anything, it does not have to be a NONCE so > changing this > > would cause issues at this time for existing deployments > > > > > > > > *From:*OAuth [mailto:oauth-bounces@ietf.org > ] *On Behalf Of *Nat Sakimura > > *Sent:* Monday, May 9, 2016 7:34 PM > > *To:* Guido Schmitz >; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] Multi-AS State Re-Use > > > > > > > > As far as I am aware of, state was meant to be nonce. Replay > possibility > > etc. were known. It is probably a bad documentation that every > reviewers > > missed because they were assuming it. > > > -- > Informationssicherheit und Kryptografie > Universität Trier - Tel. 0651 201 2847 - H436 > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > Nat Sakimura > Chairman of the Board, OpenID Foundation > Trustee, Kantara Initiative > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Jim Manico Manicode Security https://www.manicode.com --------------8A61D79B854E214E83ABACC8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

    Well hey now.

    https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet is one of the more popular resources on CSRF at OWASP.

    https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) is also pretty popular and points to a wide variety of resources on the topic.

    If anyone sees any flaws in these or otherwise would like to help make these better, please drop me a line. I serve on the OWASP board.

    Aloha, Jim Manico



    On 5/11/16 11:59 AM, Nat Sakimura wrote:
    Agreed. Also, pointing to OWASP guide or something for CSRF token may be useful.
    On Tue, May 10, 2016 at 11:37 Daniel Fett <fett@uni-trier.de> wrote:
    Regardless of what state actually is, the documentation (also the one
    for OIDC) should make clear that the same state should not be sent to
    two different AS, and that a state issued for AS #1 should be invalid
    for AS #2.

    Am 10.05.2016 um 09:31 schrieb Anthony Nadalin:
    > STATE can be anything, it does not have to be a NONCE so changing this
    > would cause issues at this time for existing deployments
    >
    >
    >
    > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Nat Sakimura
    > *Sent:* Monday, May 9, 2016 7:34 PM
    > *To:* Guido Schmitz <g.schmitz@gtrs.de>; oauth@ietf.org
    > *Subject:* Re: [OAUTH-WG] Multi-AS State Re-Use
    >
    >
    >
    > As far as I am aware of, state was meant to be nonce. Replay possibility
    > etc. were known. It is probably a bad documentation that every reviewers
    > missed because they were assuming it.


    --
    Informationssicherheit und Kryptografie
    Universität Trier - Tel. 0651 201 2847 - H436

    _______________________________________________
    OAuth mailing list
    OAuth@ietf.org
    https://www.ietf.org/mailman/listinfo/oauth
    --
    Nat Sakimura
    Chairman of the Board, OpenID Foundation
    Trustee, Kantara Initiative


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


    -- 
Jim Manico
Manicode Security
https://www.manicode.com
    --------------8A61D79B854E214E83ABACC8-- From nobody Thu May 12 07:11:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC91F12D68C for ; Thu, 12 May 2016 07:11:44 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dgto20wcRlpW for ; Thu, 12 May 2016 07:11:40 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C810B12D642 for ; Thu, 12 May 2016 07:11:39 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id u64so72766767lff.3 for ; Thu, 12 May 2016 07:11: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; bh=LupL4LqOE9C7YEbRs16yOLDs0rqNTlpTaE3+euDCHwU=; b=jonCdPg/mDMUtU6D7eEUjftC2rPOqawsIbQMGPQsh9CzHUgyn6mXlwJgcbI+k0yMne mHmEkNgpvjHdyIX0oDnY1eNwpb4myGdQdVEb7A9p2Rom8HzOJlFSl1BO9P+SaS0Z/D3e lQIDwh+axUnL6CmF6l2vvpW0PpxY7scPKmJntlrFbY96DNHvwmaaVTCxoSvRe9MkFjVB +3GQ1iufUGxsplWhO1FuEKHZe8KS50KacZMDjZjEhMVgmk0bqRAR7WDJUzdyWubW1dLl nX2GKYaj0rlgnsm+qMGbiFAZMqUVfuxLIdTArLrBb0vE0jmhwrpv8PcwXYex+iV/u0jt VPEQ== 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:date :message-id:subject:from:to; bh=LupL4LqOE9C7YEbRs16yOLDs0rqNTlpTaE3+euDCHwU=; b=GhqLCl75S1iLhumw3F3MGrN+WQyN0hHEnMb3u6OsUbJisa6clBa9Q27P3sJWufjZ2R 2LhIE0i36FWF36S01RzfLsIS2X/wF7HF1wYalCrAa201Xu9LFafhIoMICsTVy/m40w6H wlcZIf8oEub7EVauM3Rh5/FfbGQHog63RCEUGy7jt90N+jmBRAPwRymCEjRWm4GO/yyp dq0l87rFQAx7i2F0bFzn+dP1cwTaiix053Vq8y9LUzuKz/B4IHqrobd3foed8xkqcJqn W0C0LzKuuPhyyiSIOqWYr77R926pNa+3ydHx8Bdm1JkGiGNWdCZFauh2n4xiFl8eF36u s+bA== X-Gm-Message-State: AOPr4FWc+RGY0+ZECnjoHYIkzbZ49Lqmt+TfZgIZmzzJ1D90ZXXkILM0HMswvdOlwHX/YYAWyzwwhe+Ko9h3SA== MIME-Version: 1.0 X-Received: by 10.25.196.20 with SMTP id u20mr4446963lff.164.1463062297938; Thu, 12 May 2016 07:11:37 -0700 (PDT) Received: by 10.112.50.71 with HTTP; Thu, 12 May 2016 07:11:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2016 23:11:37 +0900 Message-ID: From: Takahiko Kawasaki To: Oauth Wrap Wg Content-Type: multipart/alternative; boundary=001a114b0d568d93560532a5bcc2 Archived-At: Subject: Re: [OAUTH-WG] TAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 14:11:45 -0000 --001a114b0d568d93560532a5bcc2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable IMHO, The reason an OAuth 2.0 server does not authenticate _public_ clients is because, by definition, a public client cannot keep its client secret confidential and so client authentication is almost meaningless. "Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it" and the famous post "OAuth 2.0 and the Road to Hell" (by Mr. Eran Hammer) blame OAuth 2.0, but they don't recognize that their insistence relies on the assumption that a secret key embedded in a client application can be kept confidential. On the other hand, OAuth 2.0 recognizes that the assumption is naive under some conditions and explicitly distinguishes confidential clients from public clients (RFC 6749, 2.1. Client Types). It sounds unconvincing to me that people who live in the 'confidential client' world blame OAuth 2.0 which covers use cases for both confidential clients and public clients. My opinion with further details is written in my answer to the question "How is OAuth 2 different from OAuth 1?" in StackOverflow. http://stackoverflow.com/a/35775049/1174054 Best Regards, Takahiko Kawasaki 2016-05-11 9:22 GMT+09:00 Dick Hardt : > Let us know what you learn Justin! > > On Tue, May 10, 2016 at 5:05 PM, Justin Richer wrote: > >> I posted about this the other day. What I don't understand is that he's >> saying people disable TLS checks so he's going to solve it with mutual T= LS? >> >> I need to email this guy and learn more about what he's doing. >> >> --Justin >> >> *Sent from my phone* >> >> -------- Original message -------- >> From: Brock Allen >> Date: 5/10/16 6:44 PM (GMT-06:00) >> To: Dick Hardt , Oauth Wrap Wg >> Subject: Re: [OAUTH-WG] TAuth >> >> Doesn=E2=80=99t the recent PoP work address many of these concerns? >> >> Also, as for developers disabling SSL =E2=80=94 does anyone still do thi= s and >> think it=E2=80=99s safe? Or are people just being lazy? Or are there cer= tain >> contexts that I=E2=80=99m unaware of where this is valid? >> >> -Brock >> >> >> From: OAuth on behalf of Dick Hardt < >> dick.hardt@gmail.com> >> Date: Tuesday, May 10, 2016 at 7:24 PM >> To: Oauth Wrap Wg >> Subject: [OAUTH-WG] TAuth >> >> Does anyone think there are useful lessons here? >> >> Does adding TOKBIND resolve the issues? >> >> https://blog.teller.io/2016/04/26/tauth.html >> >> *Teller* >> >> Join waiting list >> >> Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're >> fixing it >> >> This week we released our authorisation flow making it possible for you >> to go from building apps that talk to your bank account, to building app= s >> that can talk to any bank account. This is huge. Check out this SMS bot >> (how on trend) I hacked up yesterday morning. (and don't forget to join >> the beta wait list ). >> >> >> Getting to this point took longer than we expected. This is because ther= e >> wasn't a good story for delegating authorisation for sensitive APIs. The >> most popular choice, OAuth 2.0 - which has been >> chosen by the Open Banking Working Group >> , BBVA >> , >> RBS , and Mondo >> - is also amongst the >> worst from a security perspective. >> >> Teller provides an API for your bank account. The EU is forcing all >> European banks to expose account APIs with PSD II >> by end of >> 2017. These banks are disconcertingly converging around OAuth 2.0* witho= ut >> fully considering the impact on their customers, and something needs to = be >> done before it's too late. >> >> * One notable exception is the Open Bank Project >> . It is sticking with OAuth 1.0a >> precisely because OAuth 1.0a doesn't share >> the same security issues as OAuth 2.0. >> >> Man-in-the-middle >> >> One of the biggest problems with OAuth 2.0 is that it delegates all >> security concerns to TLS but only the client authenticates the server (v= ia >> it's SSL certificate), the server does not authenticate the client. This >> means the server has no way of knowing who is actually sending the reque= st. >> Is it a bona fide user, or is an attacker tampering with the request? Wh= en >> an attacker is able to insinuate themselves between a legitimate user an= d >> the server, it's called a man-in-the-middle (MITM) attack. It looks like >> this: >> >> - client attempts to connect to service >> - attacker successfully reroutes traffic to a host it controls >> - malicious host accepts connection from client >> - malicious host connects to service >> - service accepts connection from malicious host >> - client communicates with service proxied through malicious host, >> which can see and tamper with any data sent or received >> >> You're probably thinking "hang on, isn't this the point of SSL?" Yes it >> is, but there are a number of ways to present a bogus certificate and a >> client accept it. The most realistic threat is the client developer not >> properly verifying the server certificate, i.e. was it ultimately signed= by >> a trusted certificate authority? >> >> *Follow* >> >> >> >> *Tim Pope* =E2=80=8E@tpope >> >> Pull requests to disable SSL certificate verification: more common than >> you would think. >> >> 2:24 PM - 11 Feb 2013 >> >> >> - 5 5 Retweets >> 5 5 >> likes >> >> Unfortunately a large number >> of developers >> think that disabling SSL >> peer verification is the correct fix to a SSL path validation error. The= re >> are many more that will offer the same advice with the caveat that it >> introduces a security issue >> that < 100% of readers will consider. As an API provider with a duty of >> care to our users we can't simply hope developers on our platform don't = do >> this. >> >> Bearer tokens >> >> Once a user authorises a client application to access its account, the >> application obtains a bearer token from the authorisation server. As the >> name suggests if you have possession of the bearer token then you are >> essentially the user. There is no cryptographic proof that the requestin= g >> client is the intended developer and not an attacker. If an attacker is >> able to successfully MITM a client it could have catastrophic implicatio= ns >> for the user, e.g. an empty bank account, loans opened in their name, et= c. >> OAuth 2.0 is simply a security car crash from a bank's perspective. They >> have no way to prove that an API transaction is bona fide, exposing them= to >> unlimited liability. >> >> For more information on OAuth 2.0 shortcomings see OAuth Bearer Tokens >> are a Terrible Idea >> >> and OAuth 2.0 and the Road to Hell >> by E= ran >> Hammer the original primary author of >> OAuth 2.0 who formally removed his name from the standard, calling it "t= he >> biggest professional disappointment of [his] career." >> >> Finding something better >> >> Sitting down to design the solution to this problem I had two high-level >> goals: >> >> - be the most secure solution for the user >> - not unnecessarily impede developer experience. Developers are users >> too and their needs deserve equal consideration. >> >> From a security perspective I wanted: >> >> - cryptographic proof of client identity >> - to stop MITM attacks >> - to unimpeachably attribute a request to a given developer. In >> cryptography this is known as non-repudiation >> . >> >> (N.B. Non-repudiation is a de facto requirement of PSD II. If a bank >> can't prove an account owner authorised a transaction, they're liable fo= r >> any losses incurred by the user.) >> >> There are solutions to the bearer token problem like JWT tokens (RFC7523 >> ) but in most cases these rely on a >> shared secret which is used to computed a HMAC-based signature. Shared >> secrets mean no non-repudiation. Public key cryptography can be used wit= h >> JWT tokens but they don't solve the problem of how the client will gener= ate >> key pairs, demonstrate proof of possession of the private key, and enrol >> the public key with the API. Most importantly using JWT tokens make it >> basically impossible for you to experiment with an API using cURL. A maj= or >> impediment to developer experience. >> >> In an ideal world we'd have cryptographic proof of the client's identity >> without it having to leak through the application level (and stop us >> cURLing the API!). As I thought about it it became the clear the answer = was >> hiding in plain sight: *SSL client certificates.* >> >> Client SSL Authentication >> >> A SSL handshake involving client certificates contains an extra message >> at the end of the handshake, the *CertificateVerify* >> message. >> >> Client Server >> >> >> ClientHello --------> >> >> ServerHello >> >> Certificate* >> >> ServerKeyExchange* >> >> CertificateRequest* >> >> <-------- ServerHelloDone >> >> Certificate* >> >> ClientKeyExchange >> >> CertificateVerify* >> >> [ChangeCipherSpec] >> >> Finished --------> >> >> [ChangeCipherSpec] >> >> <-------- Finished >> >> Application Data <-------> Application Data >> >> >> Fig. 1 - Message flow for a full handshake >> >> The client collects all the handshake messages and signs them with it's >> private key and sends the result to the server. The server then verifies >> the signature using the public key of the client certificate. If the >> signature can be verified with the public key, the server knows the clie= nt >> is in possession of the private key, and is therefore a bona fide user. >> >> Let's look at this in the context of our original attack: >> >> - client attempts to connect to service >> - attacker successfully reroutes traffic to a host it controls >> - malicious host accepts connection from client accepting the >> client's certificate >> - malicious host connects to service >> - the malicious host will fail to SSL handshake because the host >> doesn=E2=80=99t have the private key for the client=E2=80=99s certifi= cate. The attacker >> therefore cannot compute the correct *CertificateVerify* handshake >> message. The *CertificateVerify* message from the first handshake >> cannot be used because the handshake sequences diverge (different ser= ver >> certificates presented by the host). >> >> Introducing TAuth >> >> TAuth is Client SSL Authentication + User Tokens + Great Tooling. >> >> Client SSL authentication is often overlooked because of the poor UX of >> using client certificates in the browser and that generating certificate= s >> is a painful multistep process involving arcane OpenSSL CLI incantations= . >> However as we're talking about API clients the browser UX point is >> irrelevant. As far as certificate generation goes, we can write better >> tools. These days it's possible to generate a key pair, a PKCS#10 >> certificate request, and sign it all in the browser. Thanks to WebCrypto >> the whole process is reduced to one >> click. >> >> This is how Teller does it: >> >> A private key and a SSL certificate signed by Teller generated in one >> click. >> >> And this is what a request looks like with client certificates: >> >> Let's recap what we've achieved here: >> >> - Cryptographic proof of the client identity >> - The cURLability of the API is preserved >> - The client developer has generated a private key known only to them >> and no one else, meaning the bank can actually say "you did that >> transaction" (non-repudiation) >> >> Token security >> >> Notice in the above example. The Teller API accepts connections from >> clients without a client certificate. We do this because we provide >> developers with read-only personal access tokens for their own accounts = if >> they want to quickly hack something up and not bother with provisioning >> certs. Now notice how the API does not accept the token presented, but >> accepts it when used with the client SSL certificate. TAuth bearer token= s >> are bound on the server side to a private key through an application. Th= is >> means they are useless without the private key (which only the developer >> ever has) and therefore not sensitive. As matter of fact, here is one fo= r >> my bank account: >> >> >> You'll need the private key it's bound to for it to be of any use, and >> that has never left my laptop. >> >> TAuth tokens do not expire (but can be revoked). OAuth 2.0 introduced th= e >> concept of time-limited tokens. Large internet companies found it useful >> for scaling purposes to issue self-encoded, encrypted tokens. The drawba= cks >> are developers have to pay the complexity cost of refreshing tokens and >> most importantly tokens cannot be revoked, they're good until they expir= e. >> For bank account APIs this is an undesirable property, a token should be >> void as soon as the account owner wishes. TAuth checks the token revocat= ion >> status at each request. >> >> Given that we have no need for self-encoded tokens and that tokens are >> useless to anyone without the private key, we can consider them public a= nd >> directly return them in the callback further simplifying things for the >> developer compared to OAuth without compromising the user's security. >> >> Bonus: DDOS mitigation >> >> TAuth can help mitigate layer 7 based DDOS attacks >> too. If >> the client does not present a valid client certificate the server can ju= st >> choose to bounce the connection. >> >> Conclusion >> >> OAuth 2.0 is simply not fit for use with sensitive APIs and all the >> pieces needed to build something that is exist today. Aside from unbound >> bearer tokens, OAuth is too open-ended and complicated to get right for >> most developers. It's so bad it even has it's own threat model as a sepa= rate >> RFC to offer mitigations for the >> endless problems that can happen. >> >> *TAuth stands for Trusted Authentication*, and it provides the best >> security for users while maintaining the highest possible quality develo= per >> experience. Less can go wrong when everything is simpler. *If your bank >> has OAuth 2.0 in production you must ask yourself, do they really know w= hat >> they're doing?* >> >> TAuth is available in production today for our existing beta users and >> we've already begun the work to make it an open standard we hope the >> industry adopts. If you're at a bank and want to offer your customers th= e >> security they deserve email me - *sg at teller.io * >> >> Sign up for the beta waiting list at Teller.io . >> _______________________________________________ OAuth mailing list >> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >> > > > > -- > Subscribe to the HARDTWARE mail list to learn > about projects I am working on! > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a114b0d568d93560532a5bcc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    IMHO,

    The reason an OAuth 2.0 server does not authe= nticate _public_ clients is because, by definition, a public client cannot = keep its client secret confidential and so client authentication is almost = meaningless.

    "Introducing TAuth: Why OAuth 2.0 is bad for banki= ng APIs and how we're fixing it" and the famous post "OAuth 2= .0 and the Road to Hell" (by Mr. Eran Hammer) blame OAuth 2.0, but the= y don't recognize that their insistence relies on the assumption that a= secret key embedded in a client application can be kept confidential. On t= he other hand, OAuth 2.0 recognizes that the assumption is naive under some= conditions and explicitly distinguishes confidential clients from public c= lients (RFC 6749, 2.1. Client Types).

    It sounds unconvincing to me t= hat people who live in the 'confidential client' world blame OAuth = 2.0 which covers use cases for both confidential clients and public clients= .

    My opinion with further details is written in my answer to the que= stion "How is OAuth 2 different from OAuth 1?" in StackOverflow.<= br>
    http://stack= overflow.com/a/35775049/1174054


    Best Regards,
    Takahiko Ka= wasaki

    2= 016-05-11 9:22 GMT+09:00 Dick Hardt <dick.hardt@gmail.com>:
    Let us know what you = learn Justin!

    On Tue, May 10, 2016 at 5:05 PM, Justin Richer <jri= cher@mit.edu> wrote:
    <= div>I posted about this the other day. What I don't understand is that = he's saying people disable TLS checks so he's going to solve it wit= h mutual TLS?=C2=A0

    I need to email this guy and l= earn more about what he's doing.=C2=A0

    --Justin

    =C2= =A0Sent from my phone

    -------- Original message --------
    From: Brock Allen <brockallen@gmail.com>
    Date: 5/10/16 6:44 P= M (GMT-06:00)
    To: Dick Hardt <dick.hardt@gmail.com>, Oauth Wrap Wg <= ;OAuth@ietf.org>=
    Subject: Re: [OAUTH-WG] TAuth

    <= div>
    Doesn=E2=80=99t the recent PoP work address many of these concerns= ?

    Also, as for developers disabling SSL =E2=80=94 = does anyone still do this and think it=E2=80=99s safe? Or are people just b= eing lazy? Or are there certain contexts that I=E2=80=99m unaware of where = this is valid?

    -Brock


    <= span style=3D"font-weight:bold">From: OAuth <oauth-bounces@ietf.org> on = behalf of Dick Hardt <dick.hardt@gmail.com>
    Da= te: Tuesday, May 10, 2016 at 7:24 PM
    To: Oauth Wrap Wg <OAuth@ietf.org>
    Sub= ject: [OAUTH-WG] TAuth

    Does anyone think there are useful lessons here?

    Does= adding TOKBIND resolve the issues?


    Teller<= /p>

    Join w= aiting list

    Introducing TAuth: Why OAut= h 2.0 is bad for banking APIs and how we're fixing it

    This week we released our authorisation flow making it possible for you t= o go from building apps that talk to your bank account, to building apps th= at can talk to any bank account. This is huge. Check out this SMS bot (how = on trend) I hacked up yesterday morning. (and don't forget to join the beta wait list).


    Getting to this point to= ok longer than we expected. This is because there wasn't a good story f= or delegating authorisation for sensitive APIs. The most popular choice, OAuth 2.0 -= which has been chosen by the Open Banking Working Group, BBVA, RBS, and Mondo - is also amongst the worst f= rom a security perspective.

    Teller provides an API for y= our bank account. The EU is forcing all European banks to expose account AP= Is with PSD II by end of 2017. These banks = are disconcertingly converging around OAuth 2.0* without fully considering = the impact on their customers, and something needs to be done before it'= ;s too late.

    * One notable exception is the Open Bank Project. It is sticking with OAuth 1.0a precisely because OAuth 1.0a does= n't share the same security issues as OAuth 2.0.

    Man= -in-the-middle

    One of the biggest problems with OAuth 2.= 0 is that it delegates all security concerns to TLS but only the client aut= henticates the server (via it's SSL certificate), the server does not a= uthenticate the client. This means the server has no way of knowing who is = actually sending the request. Is it a bona fide user, or is an attacker tam= pering with the request? When an attacker is able to insinuate themselves b= etween a legitimate user and the server, it's called a man-in-the-middl= e (MITM) attack. It looks like this:

    • c= lient attempts to connect to service
    • attacker successf= ully reroutes traffic to a host it controls
    • malicious = host accepts connection from client
    • malicious host con= nects to service
    • service accepts connection from malic= ious host
    • client communicates with service proxied thr= ough malicious host, which can see and tamper with any data sent or receive= d

    You're probably thinking "hang on, isn&= #39;t this the point of SSL?" Yes it is, but there are a number of way= s to present a bogus certificate and a client accept it. The most realistic= threat is the client developer not properly verifying the server certifica= te, i.e. was it ultimately signed by a trusted certificate authority?

    Fo= llow


    Tim Pope =E2=80=8E@tpope

    Pull requests to disable SS= L certificate verification: more common than you would think.

    = 2:24 PM - 11 Feb 2013

    Unfortunately a large number of develope= rs think that disabling SSL peer verification is the correct fix= to a SSL path validation error. There are many more that will offer the sa= me advice with the caveat that it introduces a security issue that < 100% of readers will consider. As an API provider with a duty o= f care to our users we can't simply hope developers on our platform don= 't do this.

    Bearer tokens

    Once a = user authorises a client application to access its account, the application= obtains a bearer token from the authorisation server. As the name suggests= if you have possession of the bearer token then you are essentially the us= er. There is no cryptographic proof that the requesting client is the inten= ded developer and not an attacker. If an attacker is able to successfully M= ITM a client it could have catastrophic implications for the user, e.g. an = empty bank account, loans opened in their name, etc. OAuth 2.0 is simply a = security car crash from a bank's perspective. They have no way to prove= that an API transaction is bona fide, exposing them to unlimited liability= .

    For more information on OAuth 2.0 shortcomings see OAuth Bearer Tokens are a Terrible Idea and OAuth 2.0 and the Road to Hell by Eran Hammer the original primary author of OAuth 2.0 who forma= lly removed his name from the standard, calling it "the biggest profes= sional disappointment of [his] career."

    Finding som= ething better

    Sitting down to design the solution to thi= s problem I had two high-level goals:

    • = be the most secure solution for the user
    • not unnecessa= rily impede developer experience. Developers are users too and their needs = deserve equal consideration.

    From a security persp= ective I wanted:

    • cryptographic proof o= f client identity
    • to stop MITM attacks
    • = to unimpeachably attribute a request to a given developer. In cryptog= raphy this is known as non-repudiation.
    <= p>(N.B. Non-repudiation is a de facto requirement of PSD II. If a ban= k can't prove an account owner authorised a transaction, they're li= able for any losses incurred by the user.)

    There are sol= utions to the bearer token problem like JWT tokens (RFC7523) but in= most cases these rely on a shared secret which is used to computed a HMAC-= based signature. Shared secrets mean no non-repudiation. Public key cryptog= raphy can be used with JWT tokens but they don't solve the problem of h= ow the client will generate key pairs, demonstrate proof of possession of t= he private key, and enrol the public key with the API. Most importantly usi= ng JWT tokens make it basically impossible for you to experiment with an AP= I using cURL. A major impediment to developer experience.

    In an ideal world we'd have cryptographic proof of the client's i= dentity without it having to leak through the application level (and stop u= s cURLing the API!). As I thought about it it became the clear the answer w= as hiding in plain sight: SSL client certificates.

    Client SSL Authentication

    A SSL handshake= involving client certificates contains an extra message at the end of the = handshake, the CertificateVerify message.

    =C2=A0 Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server

    =C2=A0 ClientHello=C2=A0 =C2=A0 =C2=A0 =C2=A0 -------->

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Serve= rHello

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Certificate*

    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ServerKeyExchange*

    =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CertificateRequest*

    =C2= =A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &l= t;--------=C2=A0 =C2=A0 =C2=A0 ServerHelloDone

    =C2=A0 Ce= rtificate*

    =C2=A0 ClientKeyExchange

    = =C2=A0 CertificateVerify*

    =C2=A0 [ChangeCipherSpec]

    =C2=A0 Finished =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --------&= gt;

    =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ChangeC= ipherSpec]

    =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-------- =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Finished

    =C2=A0 Application Data =C2=A0 &l= t;-------> =C2=A0 =C2=A0 Application Data


    =

    =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 Fig. 1 - Message flow for a = full handshake

    The client collects all the handshake mes= sages and signs them with it's private key and sends the result to the = server. The server then verifies the signature using the public key of the = client certificate. If the signature can be verified with the public key, t= he server knows the client is in possession of the private key, and is ther= efore a bona fide user.

    Let's look at this in the co= ntext of our original attack:

    • client a= ttempts to connect to service
    • attacker successfully re= routes traffic to a host it controls
    • malicious host ac= cepts connection from client accepting the client's certificate<= /li>
    • malicious host connects to service
    • the m= alicious host will fail to SSL handshake because the host doesn=E2=80=99t h= ave the private key for the client=E2=80=99s certificate. The attacker ther= efore cannot compute the correct CertificateVerify handshake message. The CertificateVerify message from the first handshake cannot be used because the handsha= ke sequences diverge (different server certificates presented by the host).=

    Introducing TAuth

    TAuth is Cli= ent SSL Authentication + User Tokens + Great Tooling.

    Cl= ient SSL authentication is often overlooked because of the poor UX of using= client certificates in the browser and that generating certificates is a p= ainful multistep process involving arcane OpenSSL CLI incantations. However= as we're talking about API clients the browser UX point is irrelevant.= As far as certificate generation goes, we can write better tools. These da= ys it's possible to generate a key pair, a PKCS#10 certificate request,= and sign it all in the browser. Thanks to WebCrypto the whole proce= ss is reduced to one click.

    This is how Teller does it:<= /span>

    A private key and a SSL certificate signed by Teller gen= erated in one click.

    And this is what a request looks li= ke with client certificates:

    Let's recap what we'= ;ve achieved here:

    • Cryptographic proof= of the client identity
    • The cURLability of the API is = preserved
    • The client developer has generated a private= key known only to them and no one else, meaning the bank can actually say = "you did that transaction" (non-repudiation)

    <= span>Token security

    Notice in the above example. The Tel= ler API accepts connections from clients without a client certificate. We d= o this because we provide developers with read-only personal access tokens = for their own accounts if they want to quickly hack something up and not bo= ther with provisioning certs. Now notice how the API does not accept the to= ken presented, but accepts it when used with the client SSL certificate. TA= uth bearer tokens are bound on the server side to a private key through an = application. This means they are useless without the private key (which onl= y the developer ever has) and therefore not sensitive. As matter of fact, h= ere is one for my bank account:


    = You'll need the private key it's bound to for it to be of any use, = and that has never left my laptop.

    TAuth tokens do not e= xpire (but can be revoked). OAuth 2.0 introduced the concept of time-limite= d tokens. Large internet companies found it useful for scaling purposes to = issue self-encoded, encrypted tokens. The drawbacks are developers have to = pay the complexity cost of refreshing tokens and most importantly tokens ca= nnot be revoked, they're good until they expire. For bank account APIs = this is an undesirable property, a token should be void as soon as the acco= unt owner wishes. TAuth checks the token revocation status at each request.=

    Given that we have no need for self-encoded tokens and = that tokens are useless to anyone without the private key, we can consider = them public and directly return them in the callback further simplifying th= ings for the developer compared to OAuth without compromising the user'= s security.

    Bonus: DDOS mitigation

    TA= uth can help mitigate layer 7 based DDOS attacks too. If the client does not present a valid client certificate the se= rver can just choose to bounce the connection.

    Conclusio= n

    OAuth 2.0 is simply not fit for use with sensitive API= s and all the pieces needed to build something that is exist today. Aside f= rom unbound bearer tokens, OAuth is too open-ended and complicated to get r= ight for most developers. It's so bad it even has it's own threat m= odel as a separate RFC to offer mitigations for the endless problem= s that can happen.

    TAuth stands for Trusted Authentic= ation, and it provides the best security for users while m= aintaining the highest possible quality developer experience. Less can go w= rong when everything is simpler. If your bank has OAuth 2.0= in production you must ask yourself, do they really know what they're = doing?

    TAuth is available in production today for ou= r existing beta users and we've already begun the work to make it an op= en standard we hope the industry adopts. If you're at a bank and want t= o offer your customers the security they deserve email me - sg at teller.io

    Sign up for the beta waiting list at Teller.io.

    _______________________________________________ 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