From nobody Fri Dec 20 14:34:18 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C561200C1 for ; Fri, 20 Dec 2019 14:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oyFS7y8qOEf2 for ; Fri, 20 Dec 2019 14:34:15 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 072FE12081C for ; Fri, 20 Dec 2019 14:34:14 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBKMY9m4023637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Dec 2019 17:34:11 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_F5152458-01AA-4702-82ED-AE56EB3790BE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Fri, 20 Dec 2019 17:34:09 -0500 Cc: "rdd@cert.org" , Benjamin Kaduk To: txauth@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2019 22:34:18 -0000 --Apple-Mail=_F5152458-01AA-4702-82ED-AE56EB3790BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, As discussed in Singapore, no matter what forum TxAuth takes, its work = will require a new charter. With that in mind, I=E2=80=99ve taken a bit = of time to put together a proposed charter text for the TxAuth work: This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 The group will deliver a protocol specification detailing how a client = can request and obtain delegated access, how an authorization server can = provide delegated access, how an authorized party can authorize = delegated access, and how that authorized access can be communicated to = the resources being protected. These actions will be connected through = an explicit transaction between the client and authorization server, = resulting in an artifact that will allow the client to undertake the = delegated action.=20 Additionally, the delegation process will allow for: - Fine-grained specification of resource access - Delegation between multiple users - Web, mobile, single-page, and other client applications The group will define extension points for this protocol to allow for = flexibility in areas including: - Cryptographic agility for keys, message signatures, and proof of = possession=20 - User interaction mechanisms including web and non-web methods - Token presentation mechanisms and key bindings The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 While this work could be done in within the OAuth working group, I now = believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing = world. I plan to be engaged in both groups, and I know most of you are = as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. I=E2=80=99ve published a blog post detailing more of my rationale: = https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? Please suggest changes to the proposed charter text above. It=E2=80=99s = my hope that we can get the chartering process started. =E2=80=94 Justin= --Apple-Mail=_F5152458-01AA-4702-82ED-AE56EB3790BE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,

As discussed in = Singapore, no matter what forum TxAuth takes, its work will require a = new charter. With that in mind, I=E2=80=99ve taken a bit of time to put = together a proposed charter text for the TxAuth work:

This group is = chartered to develop a next-generation transactional authorization and = delegation protocol for HTTP-based APIs and their clients. These = transactions will allow an authorizing party to delegate a right of = access for an API or set of APIs through an authorization server to a = software client acting on behalf of an authorizing = party. 

The= group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can = provide delegated access, how an authorized party can authorize = delegated access, and how that authorized access can be communicated to = the resources being protected. These actions will be connected through = an explicit transaction between the client and authorization server, = resulting in an artifact that will allow the client to undertake the = delegated action. 

Additionally, the delegation process will allow = for:
- Fine-grained specification of resource = access
- Delegation between multiple = users
- Web, mobile, single-page, and other client = applications

The= group will define extension points for this protocol to allow for = flexibility in areas including:

- Cryptographic agility for keys, = message signatures, and proof of possession 
- = User interaction mechanisms including web and non-web methods
- Token presentation mechanisms and key bindings

The artifacts for this = work are not intended or expected to be backwards-compatible with OAuth = 2.0 and its extensions. 

While this work could be done in within = the OAuth working group, I now believe that it should be done in a new = working group, and that we should try to get that working group up and = running prior to the Vancouver meeting in March. I think this group = should stay here on the TxAuth list, and it=E2=80=99s my suggestion that = the resulting work be called OAuth 3.0. 

Why a new group? I think that the OAuth = working group should remain focused on extending, patching, and adapting = OAuth 2.0 to a changing world. I plan to be engaged in both groups, and = I know most of you are as well, but that=E2=80=99s not universal. Since = OAuth 2.0 is so established already, there are a LOT of people who = aren=E2=80=99t going to be interested in something new any time soon. = But on the other hand, there are a number of people for whom OAuth 2.0 = does not work, or is at the very least a poor fit, and we=E2=80=99ll = want to bring them in at this early stage. So even with significant = overlap, I think there=E2=80=99s enough disconnect in the community from = both sides that warrants a new group. In addition, I think this is a big = enough piece of work that it=E2=80=99s simply too much for the OAuth = working group to be able to focus on. We wouldn=E2=80=99t be able to get = additional meeting time, and OAuth already has trouble fitting into its = two meeting slots as it is.

I=E2=80=99ve published a blog post detailing more of my = rationale:

https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a= -new-working-group-d6229ba8e36?

Please suggest changes to the proposed = charter text above. It=E2=80=99s my hope that we can get the chartering = process started.

 =E2=80=94 Justin
= --Apple-Mail=_F5152458-01AA-4702-82ED-AE56EB3790BE-- From nobody Fri Dec 20 15:27:36 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B30120999 for ; Fri, 20 Dec 2019 15:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=xmlgrrl-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 qRdpVNZILHhO for ; Fri, 20 Dec 2019 15:27:32 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 BF2C71208DC for ; Fri, 20 Dec 2019 15:27:32 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id k16so9282321otb.2 for ; Fri, 20 Dec 2019 15:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xmlgrrl-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=B9wco4786YanDOrVXVWpGgdeUWguDVzVaOhcjwOjdvw=; b=CAJqIgriFtOG06b80UCE708WY25C65wgZyAzUpgesZ0WLMHUYCK3W0hjsNyGGbkg+F E4CBbOWbfBzjyldxtvmVDZDBIpYBUM8NHanZQjwf3Qbbm6QAmxR9goFYxgFccky2MLGn pDOdn7Z2JdgpnDMfgPbfDUNyFn4ehPkte0ntMcCuhqJZB51tLNHWDds+3q1tjfh+p0dv 3VXlyExQONmpQOFr6kHTctfOsbCtMz5RsFA0RSNzLGdJvqwgrld7dCgoce9iv8SruVkQ C+nG8iOm5mFIx3J9XNNBSXbioFOuSzkk24hUFocu9d/fP2qix1Sav1SIVisgTPqSTN0b 7qRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=B9wco4786YanDOrVXVWpGgdeUWguDVzVaOhcjwOjdvw=; b=ITgGvEUmG8GlPkv4bOZVSLQOydUZZ/lLBprJRFPgmCP0axUb5WEJj2XujhAU022qWk rdyAbdl2fDqKizCcqPfZmsY7by9zbkK8RpgyuTDj+sCNaZ2DAfMAgadpOZkW77NeCSKn OhPZlPQmfZUrTW+l4X7xfLbTfz9z7QUnFYRP9Sa8KkPbmoa4lpcPCIGAtrZPIcBcpzRd uCQcE5Oi6E6C3aq4bhErJ3uT38kK+psZpK+vov+GOvV/VOpL3JDQzsDaPtG3Wf5yYjKN 7wH5Ob5GKucQHppXFqfSc3BxFpqJxGhO7B55L7+89y5IYaqLT3rSGc/FKBS7msUwtX/H BVXg== X-Gm-Message-State: APjAAAW1Dy6I0UoVJWPlt4j0yA/Gs/ww4W4RXIZHwfzHdM/dPdrCh4j8 qbbP0cZsUFAPoLNCpXT6Ozt0Sw== X-Google-Smtp-Source: APXvYqzXXKFxNBojyZIhETo7RlZ7SAPBrEKnsBQIIIwgYYTxxchugSw59jrY4eLiqm6PFOqqEeL6yA== X-Received: by 2002:a9d:69ce:: with SMTP id v14mr18233116oto.248.1576884452076; Fri, 20 Dec 2019 15:27:32 -0800 (PST) Received: from [192.168.168.101] ([47.188.76.15]) by smtp.gmail.com with ESMTPSA id r25sm3998334otk.2.2019.12.20.15.27.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Dec 2019 15:27:30 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-A7182FBB-6C5F-49C7-8D7F-F4AE06961599 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Eve Maler In-Reply-To: Date: Fri, 20 Dec 2019 17:27:29 -0600 Cc: txauth@ietf.org, "rdd@cert.org" , Benjamin Kaduk Message-Id: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> References: To: Justin Richer X-Mailer: iPad Mail (17C54) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2019 23:27:35 -0000 --Apple-Mail-A7182FBB-6C5F-49C7-8D7F-F4AE06961599 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Re =E2=80=9Cto a software client _acting on behalf of an authorizing party_=E2= =80=9D: There is a whole lot of philosophy behind whom the delegated access i= s performed on behalf of, unless the scenario is single-user or some "act as= " semantic is spelled out on the wire. Does it need to be stated here? What'= s the consequence if the highlighted phrase were removed?=20 Eve Maler (sent from my iPad) | cell +1 425 345 6756 > On Dec 20, 2019, at 4:34 PM, Justin Richer wrote: >=20 > =EF=BB=BFHi all, >=20 > As discussed in Singapore, no matter what forum TxAuth takes, its work wil= l require a new charter. With that in mind, I=E2=80=99ve taken a bit of time= to put together a proposed charter text for the TxAuth work: >=20 > This group is chartered to develop a next-generation transactional authori= zation and delegation protocol for HTTP-based APIs and their clients. These t= ransactions will allow an authorizing party to delegate a right of access fo= r an API or set of APIs through an authorization server to a software client= acting on behalf of an authorizing party.=20 >=20 > The group will deliver a protocol specification detailing how a client can= request and obtain delegated access, how an authorization server can provid= e delegated access, how an authorized party can authorize delegated access, a= nd how that authorized access can be communicated to the resources being pro= tected. These actions will be connected through an explicit transaction betw= een the client and authorization server, resulting in an artifact that will a= llow the client to undertake the delegated action.=20 >=20 > Additionally, the delegation process will allow for: > - Fine-grained specification of resource access > - Delegation between multiple users > - Web, mobile, single-page, and other client applications >=20 > The group will define extension points for this protocol to allow for flex= ibility in areas including: >=20 > - Cryptographic agility for keys, message signatures, and proof of possess= ion=20 > - User interaction mechanisms including web and non-web methods > - Token presentation mechanisms and key bindings >=20 > The artifacts for this work are not intended or expected to be backwards-c= ompatible with OAuth 2.0 and its extensions.=20 >=20 > While this work could be done in within the OAuth working group, I now bel= ieve that it should be done in a new working group, and that we should try t= o get that working group up and running prior to the Vancouver meeting in Ma= rch. I think this group should stay here on the TxAuth list, and it=E2=80=99= s my suggestion that the resulting work be called OAuth 3.0.=20 >=20 > Why a new group? I think that the OAuth working group should remain focuse= d on extending, patching, and adapting OAuth 2.0 to a changing world. I plan= to be engaged in both groups, and I know most of you are as well, but that=E2= =80=99s not universal. Since OAuth 2.0 is so established already, there are a= LOT of people who aren=E2=80=99t going to be interested in something new an= y time soon. But on the other hand, there are a number of people for whom OA= uth 2.0 does not work, or is at the very least a poor fit, and we=E2=80=99ll= want to bring them in at this early stage. So even with significant overlap= , I think there=E2=80=99s enough disconnect in the community from both sides= that warrants a new group. In addition, I think this is a big enough piece o= f work that it=E2=80=99s simply too much for the OAuth working group to be a= ble to focus on. We wouldn=E2=80=99t be able to get additional meeting time,= and OAuth already has trouble fitting into its two meeting slots as it is. >=20 > I=E2=80=99ve published a blog post detailing more of my rationale: >=20 > https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? >=20 > Please suggest changes to the proposed charter text above. It=E2=80=99s my= hope that we can get the chartering process started. >=20 > =E2=80=94 Justin > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail-A7182FBB-6C5F-49C7-8D7F-F4AE06961599 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Re =E2=80=9Cto a software client _acting on behalf of an auth= orizing party_=E2=80=9D: There is a whole lot of philosophy behind whom the d= elegated access is performed on behalf of, unless the scenario is single-use= r or some "act as" semantic is spelled out on the wire. Does it need to be s= tated here? What's the consequence if the highlighted phrase were removed?&n= bsp;

Ev= e Maler (sent from my iPad) | c= ell +1 425 345 6756

On Dec 20, 2019, at 4:34 PM, Justin Richer <jricher@mit.edu> wr= ote:

=EF= =BB=BFHi all,

As discussed i= n Singapore, no matter what forum TxAuth takes, its work will require a new c= harter. With that in mind, I=E2=80=99ve taken a bit of time to put together a= proposed charter text for the TxAuth work:

This group is chartered to develop a next-gene= ration transactional authorization and delegation protocol for HTTP-based AP= Is and their clients. These transactions will allow an authorizing party to d= elegate a right of access for an API or set of APIs through an authorization= server to a software client acting on behalf of an authorizing party. =

The group will de= liver a protocol specification detailing how a client can request and obtain= delegated access, how an authorization server can provide delegated access,= how an authorized party can authorize delegated access, and how that author= ized access can be communicated to the resources being protected. These acti= ons will be connected through an explicit transaction between the client and= authorization server, resulting in an artifact that will allow the client t= o undertake the delegated action. 

=
Additionally, the delegation process will allow for:
- Fine-grained specification of resource access
- Delegation between multiple users
- Web,= mobile, single-page, and other client applications
The group will define extension points for= this protocol to allow for flexibility in areas including:

- Cryptographic agility for keys, me= ssage signatures, and proof of possession 
- User i= nteraction mechanisms including web and non-web methods
- Token presentation mechanisms and key bindings

The artifacts for this work are not intended= or expected to be backwards-compatible with OAuth 2.0 and its extensions.&n= bsp;

= While this work could be done in within the OAuth working group, I now belie= ve that it should be done in a new working group, and that we should try to g= et that working group up and running prior to the Vancouver meeting in March= . I think this group should stay here on the TxAuth list, and it=E2=80=99s m= y suggestion that the resulting work be called OAuth 3.0. 

Why a new group? I think that t= he OAuth working group should remain focused on extending, patching, and ada= pting OAuth 2.0 to a changing world. I plan to be engaged in both groups, an= d I know most of you are as well, but that=E2=80=99s not universal. Since OA= uth 2.0 is so established already, there are a LOT of people who aren=E2=80=99= t going to be interested in something new any time soon. But on the other ha= nd, there are a number of people for whom OAuth 2.0 does not work, or is at t= he very least a poor fit, and we=E2=80=99ll want to bring them in at this ea= rly stage. So even with significant overlap, I think there=E2=80=99s enough d= isconnect in the community from both sides that warrants a new group. In add= ition, I think this is a big enough piece of work that it=E2=80=99s simply t= oo much for the OAuth working group to be able to focus on. We wouldn=E2=80=99= t be able to get additional meeting time, and OAuth already has trouble fitt= ing into its two meeting slots as it is.

I=E2=80=99ve published a blog post detailing more of m= y rationale:

https://medium.com/@justinsecurity/the-= case-for-oauth-3-0-why-a-new-working-group-d6229ba8e36?

Please suggest changes to the propos= ed charter text above. It=E2=80=99s my hope that we can get the chartering p= rocess started.

&n= bsp;=E2=80=94 Justin
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/lis= tinfo/txauth
= --Apple-Mail-A7182FBB-6C5F-49C7-8D7F-F4AE06961599-- From nobody Fri Dec 20 16:13:21 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B371208DC for ; Fri, 20 Dec 2019 16:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 T_VUNb9MHvyb for ; Fri, 20 Dec 2019 16:13:17 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::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 5FF5E1208C8 for ; Fri, 20 Dec 2019 16:13:17 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id e28so11682000ljo.9 for ; Fri, 20 Dec 2019 16:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CZ5eVfUWXjcAJ84MbRhzwlwtVsfY6q/RCib5qXSehJo=; b=lhwAme7FDgGKJvNqXiT2pFoUgbzLyOwhvXvhSj7TasP7p3Utbc65U2gCU1q+ikieHL LLRzYnxmYauC2coirTcbFXRb/gFj/DHFNO6AuBPYOn5/z93j/fZYNkZZzsg0N1Ru35/h jQ2YJVuT6SEAVGZzVSgOfqMeQFUUaaCJVGDspC2IpJinDfkSSucI6bFN1zdaiUDTuHLz Mm4+Iym9QUBOE9q0H/Zdo0/jVsdo1I9seSGJPlzIHe1vdpg8spgncZeBHrbUPQOK9yRY wBr7cJ3kFffrZ9qTD1coweqwmC16E6tkQNZb/kSw0DlSaVe2GITkIkmoflrmyDNLqnp1 oGuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CZ5eVfUWXjcAJ84MbRhzwlwtVsfY6q/RCib5qXSehJo=; b=Qe3MipCM0o0A++eMq27w5lZ0wY++ivgQftIW9FMfFPfZAiEn+xS2LkyGV+uWOEiey/ Wb21aX4QhaJwjREN0LJnAetINPUG+qAYTgV8FiyToTkmyY66+qb/QvIlhIYnJ7C7BwVS JMc169VW4iMbToemOFn+Fh0RmvmGT8bXyYPyhD/PB8rLBbmE9FIDZA/hFqdvjRCp0hm4 6AKQg58kGUQ6oza6ti63RSHNbjgN8SkIjyMBgu1cnEgdslGF7wouKOw/zyjkDNlQJ5Ex zx7/gGqx3rSf0BV6WX/KfyTWQSl8ctJKCCw/y8jgth1TmPA/AgUQ7JTOj+G2hBtdxmVZ BwtQ== X-Gm-Message-State: APjAAAVxoV5VSFCyVsCIyT8kATe2nD0RRB1FEmwV/F7J/VBmdCGcbXD1 CUrvnLGvun9oi4FHNXl1ZcgAARjIXmCOTZ3ZdWI= X-Google-Smtp-Source: APXvYqzplcNcAthw9sXlnNHmjLVVpEcEcv1fyEC5hiO3uxJ+TDvCmzyNzRmSdgPNTm6su2ECmpM3YT0qytjX6an8lCU= X-Received: by 2002:a2e:b5d5:: with SMTP id g21mr11549017ljn.89.1576887195466; Fri, 20 Dec 2019 16:13:15 -0800 (PST) MIME-Version: 1.0 References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> In-Reply-To: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> From: Dick Hardt Date: Fri, 20 Dec 2019 16:13:04 -0800 Message-ID: To: Eve Maler Cc: Justin Richer , "rdd@cert.org" , txauth@ietf.org, Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000230352059a2ba9e7" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 00:13:20 -0000 --000000000000230352059a2ba9e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Eve: do you not think the software client is acting on behalf of some party? Or do you think that software always is acting on behalf of some party, and the mentioned phrase is redundant? Justin: a couple questions 1. What is meant by "Delegation between multiple users" ? 2. Why do you restrict this to HTTP? 3. Why is authentication not in scope? 4. When you say "not backwards compatible with OAuth 2.0 and its extensions", do you expect to define a new standard to replace RFC 6750? Developers will have to have a new method to call APIs? On Fri, Dec 20, 2019 at 3:27 PM Eve Maler wrote: > Re =E2=80=9Cto a software client _acting on behalf of an authorizing part= y_=E2=80=9D: > There is a whole lot of philosophy behind whom the delegated access is > performed on behalf of, unless the scenario is single-user or some "act a= s" > semantic is spelled out on the wire. Does it need to be stated here? What= 's > the consequence if the highlighted phrase were removed? > > Eve Maler (sent from my iPad) | cell +1 425 345 6756 > > On Dec 20, 2019, at 4:34 PM, Justin Richer wrote: > > =EF=BB=BFHi all, > > As discussed in Singapore, no matter what forum TxAuth takes, its work > will require a new charter. With that in mind, I=E2=80=99ve taken a bit o= f time to > put together a proposed charter text for the TxAuth work: > > This group is chartered to develop a next-generation transactional > authorization and delegation protocol for HTTP-based APIs and their > clients. These transactions will allow an authorizing party to delegate a > right of access for an API or set of APIs through an authorization server > to a software client acting on behalf of an authorizing party. > > The group will deliver a protocol specification detailing how a client ca= n > request and obtain delegated access, how an authorization server can > provide delegated access, how an authorized party can authorize delegated > access, and how that authorized access can be communicated to the resourc= es > being protected. These actions will be connected through an explicit > transaction between the client and authorization server, resulting in an > artifact that will allow the client to undertake the delegated action. > > Additionally, the delegation process will allow for: > - Fine-grained specification of resource access > - Delegation between multiple users > - Web, mobile, single-page, and other client applications > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > - Cryptographic agility for keys, message signatures, and proof of > possession > - User interaction mechanisms including web and non-web methods > - Token presentation mechanisms and key bindings > > The artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 and its extensions. > > > While this work could be done in within the OAuth working group, I now > believe that it should be done in a new working group, and that we should > try to get that working group up and running prior to the Vancouver meeti= ng > in March.. I think this group should stay here on the TxAuth list, and it= =E2=80=99s > my suggestion that the resulting work be called OAuth 3.0. > > Why a new group? I think that the OAuth working group should remain > focused on extending, patching, and adapting OAuth 2.0 to a changing worl= d. > I plan to be engaged in both groups, and I know most of you are as well, > but that=E2=80=99s not universal. Since OAuth 2.0 is so established alrea= dy, there > are a LOT of people who aren=E2=80=99t going to be interested in somethin= g new any > time soon. But on the other hand, there are a number of people for whom > OAuth 2.0 does not work, or is at the very least a poor fit, and we=E2=80= =99ll want > to bring them in at this early stage. So even with significant overlap, I > think there=E2=80=99s enough disconnect in the community from both sides = that > warrants a new group. In addition, I think this is a big enough piece of > work that it=E2=80=99s simply too much for the OAuth working group to be = able to > focus on. We wouldn=E2=80=99t be able to get additional meeting time, and= OAuth > already has trouble fitting into its two meeting slots as it is. > > I=E2=80=99ve published a blog post detailing more of my rationale: > > > https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-worki= ng-group-d6229ba8e36? > > Please suggest changes to the proposed charter text above. It=E2=80=99s m= y hope > that we can get the chartering process started. > > =E2=80=94 Justin > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000230352059a2ba9e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Eve: do you not think the software client= is acting on behalf of some party? Or do you think that software always is= acting on behalf of some party, and the mentioned phrase is redundant?
Justin: a couple questions

1. What= is meant by "Delegation between multiple users" ?

=
2. Why do you restrict this to HTTP?

3.= Why is authentication not in scope?

4. When you s= ay "not backwards compatible with OAuth 2.0 and its extensions", = do you expect to define a new standard to replace RFC 6750? Developers will= have to have a new method to call APIs?


On Fri, Dec 20, 2019 at 3:27 PM Eve Maler <eve@xmlgrrl.com> wrote:
Re =E2=80=9Cto a software client _acting = on behalf of an authorizing party_=E2=80=9D: There is a whole lot of philos= ophy behind whom the delegated access is performed on behalf of, unless the= scenario is single-user or some "act as" semantic is spelled out= on the wire. Does it need to be stated here? What's the consequence if= the highlighted phrase were removed?=C2=A0

=
Eve Maler (sent from my iPad) |=C2=A0cell +1 425 345 6756
=

On Dec 20, 2019, at 4:34 PM,= Justin Richer <jri= cher@mit.edu> wrote:

=EF=BB=BFHi all,

As discussed in S= ingapore, no matter what forum TxAuth takes, its work will require a new ch= arter. With that in mind, I=E2=80=99ve taken a bit of time to put together = a proposed charter text for the TxAuth work:

This group= is chartered to develop a next-generation transactional authorization and = delegation protocol for HTTP-based APIs and their clients. These transactio= ns will allow an authorizing party to delegate a right of access for an API= or set of APIs through an authorization server to a software client acting= on behalf of an authorizing party.=C2=A0

The grou= p will deliver a protocol specification detailing how a client can request = and obtain delegated access, how an authorization server can provide delega= ted access, how an authorized party can authorize delegated access, and how= that authorized access can be communicated to the resources being protecte= d. These actions will be connected through an explicit transaction between = the client and authorization server, resulting in an artifact that will all= ow the client to undertake the delegated action.=C2=A0

=
Additionally, the delegation process will allow for:
- Fine-= grained specification of resource access
- Delegation between mul= tiple users
- Web, mobile, single-page, and other client applicat= ions

The group will define extension points for th= is protocol to allow for flexibility in areas including:

- Cryptographic agility for keys, message signatures, and proof of p= ossession=C2=A0
- User interaction mechanisms including web and n= on-web methods
- Token presentation mechanisms and key bindings

The artifacts for this work are not intended or exp= ected to be backwards-compatible with OAuth 2.0 and its extensions.=C2=A0

While this work could be done in withi= n the OAuth working group, I now believe that it should be done in a new wo= rking group, and that we should try to get that working group up and runnin= g prior to the Vancouver meeting in March.. I think this group should stay = here on the TxAuth list, and it=E2=80=99s my suggestion that the resulting = work be called OAuth 3.0.=C2=A0

Why a new group? I= think that the OAuth working group should remain focused on extending, pat= ching, and adapting OAuth 2.0 to a changing world. I plan to be engaged in = both groups, and I know most of you are as well, but that=E2=80=99s not uni= versal. Since OAuth 2.0 is so established already, there are a LOT of peopl= e who aren=E2=80=99t going to be interested in something new any time soon.= But on the other hand, there are a number of people for whom OAuth 2.0 doe= s not work, or is at the very least a poor fit, and we=E2=80=99ll want to b= ring them in at this early stage. So even with significant overlap, I think= there=E2=80=99s enough disconnect in the community from both sides that wa= rrants a new group. In addition, I think this is a big enough piece of work= that it=E2=80=99s simply too much for the OAuth working group to be able t= o focus on. We wouldn=E2=80=99t be able to get additional meeting time, and= OAuth already has trouble fitting into its two meeting slots as it is.

I=E2=80=99ve published a blog post detailing more of = my rationale:


Please sugge= st changes to the proposed charter text above. It=E2=80=99s my hope that we= can get the chartering process started.

=C2=A0=E2= =80=94 Justin
--
Txauth mailing list
= Txauth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/txauth=
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000230352059a2ba9e7-- From nobody Fri Dec 20 17:08:29 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC4A1209EE for ; Fri, 20 Dec 2019 17:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 uyeVYi0sRO_g for ; Fri, 20 Dec 2019 17:08:25 -0800 (PST) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (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 C86631209EB for ; Fri, 20 Dec 2019 17:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1576890505; x=1608426505; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1Eis77O0sj+oOMiuuUxqGlaOm6I2SBm0UHOwfVcSLxU=; b=F/Fec/cH9rB57kKDSvmZDrFe1RsQ5H1EcxBwVOBp8BK9H534QBUAZYC1 eggKVnqjyMpIMyv/p5AmOJwIxbsWI783vgrnWVruH+c0zEr2uPlpt3RPw fMXvomJ8TpdfecXRu3hCoq8kjhxOsjt6UGaLUp16VJyprZNGEki5/l5BT E=; IronPort-SDR: kSMni1NmbBuaRicrbbfz75Smi71XXYJRA2m6wpIZQ3S1GvtJNme7vvwxmT38l6O+BM3OJ5PGC9 l+9Y/tnfUt2Q== X-IronPort-AV: E=Sophos;i="5.69,337,1571702400"; d="scan'208,217";a="9473314" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1d-f273de60.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 21 Dec 2019 01:08:22 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-f273de60.us-east-1.amazon.com (Postfix) with ESMTPS id 2A8C5A2D8A; Sat, 21 Dec 2019 01:08:19 +0000 (UTC) Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 21 Dec 2019 01:08:19 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 21 Dec 2019 01:08:19 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Sat, 21 Dec 2019 01:08:19 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt , Eve Maler CC: "rdd@cert.org" , "txauth@ietf.org" , Justin Richer , Benjamin Kaduk Thread-Topic: [Txauth] TxAuth Proposed Charter Thread-Index: AQHVt4W+Cd5+sniY+0u9RUqE6+8fD6fDqwuAgAAMvQD//4lSAA== Date: Sat, 21 Dec 2019 01:08:19 +0000 Message-ID: <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.100] Content-Type: multipart/alternative; boundary="_000_5526B52828A64F18BE2D846CCA035D77amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 01:08:28 -0000 --_000_5526B52828A64F18BE2D846CCA035D77amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IHN1cmUgaWYgdGhpcyBpcyB3aGF0IEV2ZSBoYWQgaW4gbWluZCwgYnV0IGNvbnNp ZGVyIGFuIGF1dG9tYXRlZCBzeXN0ZW0gaW4gYW4gZW50ZXJwcmlzZSBjb250ZXh0IHRoYXQgaGFz IGJlZW4gYXV0aG9yaXplZCBieSBhbiBhZG1pbmlzdHJhdG9yLiBUaGUgYXV0b21hdGVkIHN5c3Rl bSBpc27igJl0IGFjdGluZyBhcyBvciBvbiBiZWhhbGYgb2YgdGhlIGFkbWluaXN0cmF0b3IsIGFu ZCB0aGUgYWRtaW5pc3RyYXRvciBoYXNu4oCZdCDigJxkZWxlZ2F0ZWQgYWNjZXNz4oCdOyB0aGV5 4oCZdmUgZ3JhbnRlZCBhY2Nlc3MsIGp1c3QgYXMgdGhleSBkbyB3aGVuIHRoZXkgYXNzaWduIHBl cm1pc3Npb25zIHRvIHVzZXJzL2dyb3Vwcy9yb2xlcy9ldGMuDQpNYXliZSBJ4oCZbSBiZWluZyB0 b28gbGl0ZXJhbCwgYnV0IOKAnHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJ0gaW4g cGFyYWdyYXBoIDEgaW1wbGllcyBhIHNwZWNpZmljIGNvbnRleHQvaW5mb3JtYXRpb24vcmVxdWVz dCBmbG93IHRvIG1lLiBHaXZlbiB0aGF0IG9uZSBvZiBUeEF1dGjigJlzIGZlYXR1cmVzIGlzIGRl Y291cGxpbmcgdGhlIGRpZmZlcmVudCBjb21tdW5pY2F0aW9uIGNoYW5uZWxzLCB3ZSBzaG91bGQg bm90IHN1Z2dlc3QgdGhhdCB0aGUgY2xpZW50IG9yIGF1dGhvcml6aW5nIHBhcnR5IGlzIGRpcmVj dGx5IGludGVyYWN0aW5nIHdpdGggdGhlIEFTLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJh Y2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0 Zi5vcmc+IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbT4NCkRh dGU6IEZyaWRheSwgRGVjZW1iZXIgMjAsIDIwMTkgYXQgNDoxNCBQTQ0KVG86IEV2ZSBNYWxlciA8 ZXZlQHhtbGdycmwuY29tPg0KQ2M6ICJyZGRAY2VydC5vcmciIDxyZGRAY2VydC5vcmc+LCAidHhh dXRoQGlldGYub3JnIiA8dHhhdXRoQGlldGYub3JnPiwgSnVzdGluIFJpY2hlciA8anJpY2hlckBt aXQuZWR1PiwgQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+DQpTdWJqZWN0OiBSZTogW1R4 YXV0aF0gVHhBdXRoIFByb3Bvc2VkIENoYXJ0ZXINCg0KRXZlOiBkbyB5b3Ugbm90IHRoaW5rIHRo ZSBzb2Z0d2FyZSBjbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFsZiBvZiBzb21lIHBhcnR5PyBPciBk byB5b3UgdGhpbmsgdGhhdCBzb2Z0d2FyZSBhbHdheXMgaXMgYWN0aW5nIG9uIGJlaGFsZiBvZiBz b21lIHBhcnR5LCBhbmQgdGhlIG1lbnRpb25lZCBwaHJhc2UgaXMgcmVkdW5kYW50Pw0KDQpKdXN0 aW46IGEgY291cGxlIHF1ZXN0aW9ucw0KDQoxLiBXaGF0IGlzIG1lYW50IGJ5ICJEZWxlZ2F0aW9u IGJldHdlZW4gbXVsdGlwbGUgdXNlcnMiID8NCg0KMi4gV2h5IGRvIHlvdSByZXN0cmljdCB0aGlz IHRvIEhUVFA/DQoNCjMuIFdoeSBpcyBhdXRoZW50aWNhdGlvbiBub3QgaW4gc2NvcGU/DQoNCjQu IFdoZW4geW91IHNheSAibm90IGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggT0F1dGggMi4wIGFu ZCBpdHMgZXh0ZW5zaW9ucyIsIGRvIHlvdSBleHBlY3QgdG8gZGVmaW5lIGEgbmV3IHN0YW5kYXJk IHRvIHJlcGxhY2UgUkZDIDY3NTA/IERldmVsb3BlcnMgd2lsbCBoYXZlIHRvIGhhdmUgYSBuZXcg bWV0aG9kIHRvIGNhbGwgQVBJcz8NCg0KDQpPbiBGcmksIERlYyAyMCwgMjAxOSBhdCAzOjI3IFBN IEV2ZSBNYWxlciA8ZXZlQHhtbGdycmwuY29tPG1haWx0bzpldmVAeG1sZ3JybC5jb20+PiB3cm90 ZToNClJlIOKAnHRvIGEgc29mdHdhcmUgY2xpZW50IF9hY3Rpbmcgb24gYmVoYWxmIG9mIGFuIGF1 dGhvcml6aW5nIHBhcnR5X+KAnTogVGhlcmUgaXMgYSB3aG9sZSBsb3Qgb2YgcGhpbG9zb3BoeSBi ZWhpbmQgd2hvbSB0aGUgZGVsZWdhdGVkIGFjY2VzcyBpcyBwZXJmb3JtZWQgb24gYmVoYWxmIG9m LCB1bmxlc3MgdGhlIHNjZW5hcmlvIGlzIHNpbmdsZS11c2VyIG9yIHNvbWUgImFjdCBhcyIgc2Vt YW50aWMgaXMgc3BlbGxlZCBvdXQgb24gdGhlIHdpcmUuIERvZXMgaXQgbmVlZCB0byBiZSBzdGF0 ZWQgaGVyZT8gV2hhdCdzIHRoZSBjb25zZXF1ZW5jZSBpZiB0aGUgaGlnaGxpZ2h0ZWQgcGhyYXNl IHdlcmUgcmVtb3ZlZD8NCkV2ZSBNYWxlciAoc2VudCBmcm9tIG15IGlQYWQpIHwgY2VsbCArMSA0 MjUgMzQ1IDY3NTYNCg0KDQpPbiBEZWMgMjAsIDIwMTksIGF0IDQ6MzQgUE0sIEp1c3RpbiBSaWNo ZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQpIaSBh bGwsDQoNCkFzIGRpc2N1c3NlZCBpbiBTaW5nYXBvcmUsIG5vIG1hdHRlciB3aGF0IGZvcnVtIFR4 QXV0aCB0YWtlcywgaXRzIHdvcmsgd2lsbCByZXF1aXJlIGEgbmV3IGNoYXJ0ZXIuIFdpdGggdGhh dCBpbiBtaW5kLCBJ4oCZdmUgdGFrZW4gYSBiaXQgb2YgdGltZSB0byBwdXQgdG9nZXRoZXIgYSBw cm9wb3NlZCBjaGFydGVyIHRleHQgZm9yIHRoZSBUeEF1dGggd29yazoNCg0KVGhpcyBncm91cCBp cyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBhIG5leHQtZ2VuZXJhdGlvbiB0cmFuc2FjdGlvbmFsIGF1 dGhvcml6YXRpb24gYW5kIGRlbGVnYXRpb24gcHJvdG9jb2wgZm9yIEhUVFAtYmFzZWQgQVBJcyBh bmQgdGhlaXIgY2xpZW50cy4gVGhlc2UgdHJhbnNhY3Rpb25zIHdpbGwgYWxsb3cgYW4gYXV0aG9y aXppbmcgcGFydHkgdG8gZGVsZWdhdGUgYSByaWdodCBvZiBhY2Nlc3MgZm9yIGFuIEFQSSBvciBz ZXQgb2YgQVBJcyB0aHJvdWdoIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGEgc29mdHdhcmUg Y2xpZW50IGFjdGluZyBvbiBiZWhhbGYgb2YgYW4gYXV0aG9yaXppbmcgcGFydHkuDQoNClRoZSBn cm91cCB3aWxsIGRlbGl2ZXIgYSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGRldGFpbGluZyBob3cg YSBjbGllbnQgY2FuIHJlcXVlc3QgYW5kIG9idGFpbiBkZWxlZ2F0ZWQgYWNjZXNzLCBob3cgYW4g YXV0aG9yaXphdGlvbiBzZXJ2ZXIgY2FuIHByb3ZpZGUgZGVsZWdhdGVkIGFjY2VzcywgaG93IGFu IGF1dGhvcml6ZWQgcGFydHkgY2FuIGF1dGhvcml6ZSBkZWxlZ2F0ZWQgYWNjZXNzLCBhbmQgaG93 IHRoYXQgYXV0aG9yaXplZCBhY2Nlc3MgY2FuIGJlIGNvbW11bmljYXRlZCB0byB0aGUgcmVzb3Vy Y2VzIGJlaW5nIHByb3RlY3RlZC4gVGhlc2UgYWN0aW9ucyB3aWxsIGJlIGNvbm5lY3RlZCB0aHJv dWdoIGFuIGV4cGxpY2l0IHRyYW5zYWN0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgYXV0aG9y aXphdGlvbiBzZXJ2ZXIsIHJlc3VsdGluZyBpbiBhbiBhcnRpZmFjdCB0aGF0IHdpbGwgYWxsb3cg dGhlIGNsaWVudCB0byB1bmRlcnRha2UgdGhlIGRlbGVnYXRlZCBhY3Rpb24uDQoNCkFkZGl0aW9u YWxseSwgdGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGFsbG93IGZvcjoNCi0gRmluZS1ncmFp bmVkIHNwZWNpZmljYXRpb24gb2YgcmVzb3VyY2UgYWNjZXNzDQotIERlbGVnYXRpb24gYmV0d2Vl biBtdWx0aXBsZSB1c2Vycw0KLSBXZWIsIG1vYmlsZSwgc2luZ2xlLXBhZ2UsIGFuZCBvdGhlciBj bGllbnQgYXBwbGljYXRpb25zDQoNClRoZSBncm91cCB3aWxsIGRlZmluZSBleHRlbnNpb24gcG9p bnRzIGZvciB0aGlzIHByb3RvY29sIHRvIGFsbG93IGZvciBmbGV4aWJpbGl0eSBpbiBhcmVhcyBp bmNsdWRpbmc6DQoNCi0gQ3J5cHRvZ3JhcGhpYyBhZ2lsaXR5IGZvciBrZXlzLCBtZXNzYWdlIHNp Z25hdHVyZXMsIGFuZCBwcm9vZiBvZiBwb3NzZXNzaW9uDQotIFVzZXIgaW50ZXJhY3Rpb24gbWVj aGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFuZCBub24td2ViIG1ldGhvZHMNCi0gVG9rZW4gcHJlc2Vu dGF0aW9uIG1lY2hhbmlzbXMgYW5kIGtleSBiaW5kaW5ncw0KDQpUaGUgYXJ0aWZhY3RzIGZvciB0 aGlzIHdvcmsgYXJlIG5vdCBpbnRlbmRlZCBvciBleHBlY3RlZCB0byBiZSBiYWNrd2FyZHMtY29t cGF0aWJsZSB3aXRoIE9BdXRoIDIuMCBhbmQgaXRzIGV4dGVuc2lvbnMuDQoNCldoaWxlIHRoaXMg d29yayBjb3VsZCBiZSBkb25lIGluIHdpdGhpbiB0aGUgT0F1dGggd29ya2luZyBncm91cCwgSSBu b3cgYmVsaWV2ZSB0aGF0IGl0IHNob3VsZCBiZSBkb25lIGluIGEgbmV3IHdvcmtpbmcgZ3JvdXAs IGFuZCB0aGF0IHdlIHNob3VsZCB0cnkgdG8gZ2V0IHRoYXQgd29ya2luZyBncm91cCB1cCBhbmQg cnVubmluZyBwcmlvciB0byB0aGUgVmFuY291dmVyIG1lZXRpbmcgaW4gTWFyY2guLiBJIHRoaW5r IHRoaXMgZ3JvdXAgc2hvdWxkIHN0YXkgaGVyZSBvbiB0aGUgVHhBdXRoIGxpc3QsIGFuZCBpdOKA mXMgbXkgc3VnZ2VzdGlvbiB0aGF0IHRoZSByZXN1bHRpbmcgd29yayBiZSBjYWxsZWQgT0F1dGgg My4wLg0KDQpXaHkgYSBuZXcgZ3JvdXA/IEkgdGhpbmsgdGhhdCB0aGUgT0F1dGggd29ya2luZyBn cm91cCBzaG91bGQgcmVtYWluIGZvY3VzZWQgb24gZXh0ZW5kaW5nLCBwYXRjaGluZywgYW5kIGFk YXB0aW5nIE9BdXRoIDIuMCB0byBhIGNoYW5naW5nIHdvcmxkLiBJIHBsYW4gdG8gYmUgZW5nYWdl ZCBpbiBib3RoIGdyb3VwcywgYW5kIEkga25vdyBtb3N0IG9mIHlvdSBhcmUgYXMgd2VsbCwgYnV0 IHRoYXTigJlzIG5vdCB1bml2ZXJzYWwuIFNpbmNlIE9BdXRoIDIuMCBpcyBzbyBlc3RhYmxpc2hl ZCBhbHJlYWR5LCB0aGVyZSBhcmUgYSBMT1Qgb2YgcGVvcGxlIHdobyBhcmVu4oCZdCBnb2luZyB0 byBiZSBpbnRlcmVzdGVkIGluIHNvbWV0aGluZyBuZXcgYW55IHRpbWUgc29vbi4gQnV0IG9uIHRo ZSBvdGhlciBoYW5kLCB0aGVyZSBhcmUgYSBudW1iZXIgb2YgcGVvcGxlIGZvciB3aG9tIE9BdXRo IDIuMCBkb2VzIG5vdCB3b3JrLCBvciBpcyBhdCB0aGUgdmVyeSBsZWFzdCBhIHBvb3IgZml0LCBh bmQgd2XigJlsbCB3YW50IHRvIGJyaW5nIHRoZW0gaW4gYXQgdGhpcyBlYXJseSBzdGFnZS4gU28g ZXZlbiB3aXRoIHNpZ25pZmljYW50IG92ZXJsYXAsIEkgdGhpbmsgdGhlcmXigJlzIGVub3VnaCBk aXNjb25uZWN0IGluIHRoZSBjb21tdW5pdHkgZnJvbSBib3RoIHNpZGVzIHRoYXQgd2FycmFudHMg YSBuZXcgZ3JvdXAuIEluIGFkZGl0aW9uLCBJIHRoaW5rIHRoaXMgaXMgYSBiaWcgZW5vdWdoIHBp ZWNlIG9mIHdvcmsgdGhhdCBpdOKAmXMgc2ltcGx5IHRvbyBtdWNoIGZvciB0aGUgT0F1dGggd29y a2luZyBncm91cCB0byBiZSBhYmxlIHRvIGZvY3VzIG9uLiBXZSB3b3VsZG7igJl0IGJlIGFibGUg dG8gZ2V0IGFkZGl0aW9uYWwgbWVldGluZyB0aW1lLCBhbmQgT0F1dGggYWxyZWFkeSBoYXMgdHJv dWJsZSBmaXR0aW5nIGludG8gaXRzIHR3byBtZWV0aW5nIHNsb3RzIGFzIGl0IGlzLg0KDQpJ4oCZ dmUgcHVibGlzaGVkIGEgYmxvZyBwb3N0IGRldGFpbGluZyBtb3JlIG9mIG15IHJhdGlvbmFsZToN Cg0KaHR0cHM6Ly9tZWRpdW0uY29tL0BqdXN0aW5zZWN1cml0eS90aGUtY2FzZS1mb3Itb2F1dGgt My0wLXdoeS1hLW5ldy13b3JraW5nLWdyb3VwLWQ2MjI5YmE4ZTM2Pw0KDQpQbGVhc2Ugc3VnZ2Vz dCBjaGFuZ2VzIHRvIHRoZSBwcm9wb3NlZCBjaGFydGVyIHRleHQgYWJvdmUuIEl04oCZcyBteSBo b3BlIHRoYXQgd2UgY2FuIGdldCB0aGUgY2hhcnRlcmluZyBwcm9jZXNzIHN0YXJ0ZWQuDQoNCiDi gJQgSnVzdGluDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlzdA0KVHhhdXRoQGlldGYub3JnPG1haWx0 bzpUeGF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3R4YXV0aA0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4YXV0aEBpZXRmLm9yZzxtYWlsdG86 VHhhdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 eGF1dGgNCg== --_000_5526B52828A64F18BE2D846CCA035D77amazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <8007CCFDF7A43949BA370A1BA9814D53@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBN YXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0 IDIgNSA4IDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MjAyODAxNTY5OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTY1MzEyOTIzNiA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs MDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJltIG5vdCBzdXJl IGlmIHRoaXMgaXMgd2hhdCBFdmUgaGFkIGluIG1pbmQsIGJ1dCBjb25zaWRlciBhbiBhdXRvbWF0 ZWQgc3lzdGVtIGluIGFuIGVudGVycHJpc2UgY29udGV4dCB0aGF0IGhhcyBiZWVuIGF1dGhvcml6 ZWQgYnkgYW4gYWRtaW5pc3RyYXRvci4gVGhlIGF1dG9tYXRlZCBzeXN0ZW0gaXNu4oCZdCBhY3Rp bmcgYXMgb3Igb24gYmVoYWxmIG9mIHRoZSBhZG1pbmlzdHJhdG9yLCBhbmQgdGhlIGFkbWluaXN0 cmF0b3INCiBoYXNu4oCZdCDigJxkZWxlZ2F0ZWQgYWNjZXNz4oCdOyB0aGV54oCZdmUgPGk+Z3Jh bnRlZDwvaT4gYWNjZXNzLCBqdXN0IGFzIHRoZXkgZG8gd2hlbiB0aGV5IGFzc2lnbiBwZXJtaXNz aW9ucyB0byB1c2Vycy9ncm91cHMvcm9sZXMvZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXliZSBJ 4oCZbSBiZWluZyB0b28gbGl0ZXJhbCwgYnV0IOKAnHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBz ZXJ2ZXLigJ0gaW4gcGFyYWdyYXBoIDEgaW1wbGllcyBhIHNwZWNpZmljIGNvbnRleHQvaW5mb3Jt YXRpb24vcmVxdWVzdCBmbG93IHRvIG1lLiBHaXZlbiB0aGF0IG9uZSBvZiBUeEF1dGjigJlzIGZl YXR1cmVzIGlzIGRlY291cGxpbmcgdGhlIGRpZmZlcmVudCBjb21tdW5pY2F0aW9uIGNoYW5uZWxz LCB3ZSBzaG91bGQNCiBub3Qgc3VnZ2VzdCB0aGF0IHRoZSBjbGllbnQgb3IgYXV0aG9yaXppbmcg cGFydHkgaXMgZGlyZWN0bHkgaW50ZXJhY3Rpbmcgd2l0aCB0aGUgQVMuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+4oCTJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPlR4YXV0aCAmbHQ7dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBv ZiBEaWNrIEhhcmR0ICZsdDtkaWNrLmhhcmR0QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+RnJpZGF5LCBEZWNlbWJlciAyMCwgMjAxOSBhdCA0OjE0IFBNPGJyPg0KPGI+VG86IDwvYj5F dmUgTWFsZXIgJmx0O2V2ZUB4bWxncnJsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3Jk ZEBjZXJ0Lm9yZyZxdW90OyAmbHQ7cmRkQGNlcnQub3JnJmd0OywgJnF1b3Q7dHhhdXRoQGlldGYu b3JnJnF1b3Q7ICZsdDt0eGF1dGhAaWV0Zi5vcmcmZ3Q7LCBKdXN0aW4gUmljaGVyICZsdDtqcmlj aGVyQG1pdC5lZHUmZ3Q7LCBCZW5qYW1pbiBLYWR1ayAmbHQ7a2FkdWtAbWl0LmVkdSZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtUeGF1dGhdIFR4QXV0aCBQcm9wb3NlZCBDaGFydGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RXZlOiBkbyB5b3Ugbm90IHRoaW5rIHRoZSBzb2Z0d2FyZSBjbGllbnQgaXMgYWN0 aW5nIG9uIGJlaGFsZiBvZiBzb21lIHBhcnR5PyBPciBkbyB5b3UgdGhpbmsgdGhhdCBzb2Z0d2Fy ZSBhbHdheXMgaXMgYWN0aW5nIG9uIGJlaGFsZiBvZiBzb21lIHBhcnR5LCBhbmQgdGhlIG1lbnRp b25lZCBwaHJhc2UgaXMgcmVkdW5kYW50Pw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5KdXN0aW46IGEgY291cGxlIHF1ZXN0aW9uczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBXaGF0IGlzIG1lYW50 IGJ5ICZxdW90O0RlbGVnYXRpb24gYmV0d2VlbiBtdWx0aXBsZSB1c2VycyZxdW90OyA/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIFdoeSBk byB5b3UgcmVzdHJpY3QgdGhpcyB0byBIVFRQPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBXaHkgaXMgYXV0aGVudGljYXRpb24gbm90IGlu IHNjb3BlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj40LiBXaGVuIHlvdSBzYXkgJnF1b3Q7bm90IGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGgg T0F1dGggMi4wIGFuZCBpdHMgZXh0ZW5zaW9ucyZxdW90OywgZG8geW91IGV4cGVjdCB0byBkZWZp bmUgYSBuZXcgc3RhbmRhcmQgdG8gcmVwbGFjZSBSRkMgNjc1MD8gRGV2ZWxvcGVycyB3aWxsIGhh dmUgdG8gaGF2ZSBhIG5ldyBtZXRob2QgdG8gY2FsbCBBUElzPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gRnJpLCBEZWMgMjAsIDIwMTkgYXQgMzoyNyBQTSBFdmUgTWFsZXIgJmx0OzxhIGhyZWY9 Im1haWx0bzpldmVAeG1sZ3JybC5jb20iPmV2ZUB4bWxncnJsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+UmUg4oCcPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPnRvIGEgc29mdHdhcmUgY2xpZW50IF9hY3Rpbmcg b24gYmVoYWxmIG9mIGFuIGF1dGhvcml6aW5nIHBhcnR5X+KAnTogVGhlcmUgaXMgYSB3aG9sZSBs b3Qgb2YgcGhpbG9zb3BoeSBiZWhpbmQgd2hvbSB0aGUgZGVsZWdhdGVkIGFjY2VzcyBpcyBwZXJm b3JtZWQgb24gYmVoYWxmIG9mLA0KIHVubGVzcyB0aGUgc2NlbmFyaW8gaXMgc2luZ2xlLXVzZXIg b3Igc29tZSAmcXVvdDthY3QgYXMmcXVvdDsgc2VtYW50aWMgaXMgc3BlbGxlZCBvdXQgb24gdGhl IHdpcmUuIERvZXMgaXQgbmVlZCB0byBiZSBzdGF0ZWQgaGVyZT8gV2hhdCdzIHRoZSBjb25zZXF1 ZW5jZSBpZiB0aGUgaGlnaGxpZ2h0ZWQgcGhyYXNlIHdlcmUgcmVtb3ZlZD8mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTMuMHB0Ij5FdmUgTWFsZXIgKHNlbnQgZnJvbSBteSBpUGFkKSB8 Jm5ic3A7Y2VsbCAmIzQzOzEgNDI1IDM0NSA2NzU2PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij5PbiBEZWMgMjAsIDIwMTksIGF0IDQ6MzQgUE0sIEp1c3RpbiBSaWNoZXIgJmx0Ozxh IGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1p dC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgYWxsLCA8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGRpc2N1c3NlZCBpbiBTaW5nYXBvcmUs IG5vIG1hdHRlciB3aGF0IGZvcnVtIFR4QXV0aCB0YWtlcywgaXRzIHdvcmsgd2lsbCByZXF1aXJl IGEgbmV3IGNoYXJ0ZXIuIFdpdGggdGhhdCBpbiBtaW5kLCBJ4oCZdmUgdGFrZW4gYSBiaXQgb2Yg dGltZSB0byBwdXQgdG9nZXRoZXIgYSBwcm9wb3NlZCBjaGFydGVyIHRleHQgZm9yIHRoZSBUeEF1 dGggd29yazo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBuZXh0LWdlbmVyYXRp b24gdHJhbnNhY3Rpb25hbCBhdXRob3JpemF0aW9uIGFuZCBkZWxlZ2F0aW9uIHByb3RvY29sIGZv ciBIVFRQLWJhc2VkIEFQSXMgYW5kIHRoZWlyIGNsaWVudHMuIFRoZXNlIHRyYW5zYWN0aW9ucyB3 aWxsIGFsbG93IGFuIGF1dGhvcml6aW5nIHBhcnR5IHRvIGRlbGVnYXRlIGEgcmlnaHQgb2YgYWNj ZXNzIGZvciBhbiBBUEkNCiBvciBzZXQgb2YgQVBJcyB0aHJvdWdoIGFuIGF1dGhvcml6YXRpb24g c2VydmVyIHRvIGEgc29mdHdhcmUgY2xpZW50IGFjdGluZyBvbiBiZWhhbGYgb2YgYW4gYXV0aG9y aXppbmcgcGFydHkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBncm91cCB3aWxsIGRlbGl2ZXIgYSBwcm90b2NvbCBzcGVjaWZp Y2F0aW9uIGRldGFpbGluZyBob3cgYSBjbGllbnQgY2FuIHJlcXVlc3QgYW5kIG9idGFpbiBkZWxl Z2F0ZWQgYWNjZXNzLCBob3cgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgY2FuIHByb3ZpZGUgZGVs ZWdhdGVkIGFjY2VzcywgaG93IGFuIGF1dGhvcml6ZWQgcGFydHkgY2FuIGF1dGhvcml6ZSBkZWxl Z2F0ZWQgYWNjZXNzLCBhbmQgaG93IHRoYXQNCiBhdXRob3JpemVkIGFjY2VzcyBjYW4gYmUgY29t bXVuaWNhdGVkIHRvIHRoZSByZXNvdXJjZXMgYmVpbmcgcHJvdGVjdGVkLiBUaGVzZSBhY3Rpb25z IHdpbGwgYmUgY29ubmVjdGVkIHRocm91Z2ggYW4gZXhwbGljaXQgdHJhbnNhY3Rpb24gYmV0d2Vl biB0aGUgY2xpZW50IGFuZCBhdXRob3JpemF0aW9uIHNlcnZlciwgcmVzdWx0aW5nIGluIGFuIGFy dGlmYWN0IHRoYXQgd2lsbCBhbGxvdyB0aGUgY2xpZW50IHRvIHVuZGVydGFrZSB0aGUgZGVsZWdh dGVkDQogYWN0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BZGRpdGlvbmFsbHksIHRoZSBkZWxlZ2F0aW9uIHByb2Nlc3Mgd2ls bCBhbGxvdyBmb3I6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tIEZpbmUtZ3JhaW5lZCBzcGVjaWZpY2F0aW9uIG9mIHJlc291cmNlIGFjY2Vzczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBEZWxl Z2F0aW9uIGJldHdlZW4gbXVsdGlwbGUgdXNlcnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gV2ViLCBtb2JpbGUsIHNpbmdsZS1wYWdlLCBhbmQg b3RoZXIgY2xpZW50IGFwcGxpY2F0aW9uczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZ3JvdXAgd2lsbCBkZWZpbmUgZXh0ZW5zaW9uIHBv aW50cyBmb3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3IgZmxleGliaWxpdHkgaW4gYXJlYXMg aW5jbHVkaW5nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tIENyeXB0b2dyYXBoaWMgYWdpbGl0eSBmb3Iga2V5cywgbWVzc2FnZSBzaWduYXR1 cmVzLCBhbmQgcHJvb2Ygb2YgcG9zc2Vzc2lvbiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBVc2VyIGludGVyYWN0aW9uIG1lY2hhbmlz bXMgaW5jbHVkaW5nIHdlYiBhbmQgbm9uLXdlYiBtZXRob2RzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFRva2VuIHByZXNlbnRhdGlvbiBtZWNo YW5pc21zIGFuZCBrZXkgYmluZGluZ3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFydGlmYWN0cyBmb3IgdGhpcyB3b3JrIGFyZSBub3Qg aW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmUgYmFja3dhcmRzLWNvbXBhdGlibGUgd2l0aCBPQXV0 aCAyLjAgYW5kIGl0cyBleHRlbnNpb25zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGlsZSB0aGlzIHdv cmsgY291bGQgYmUgZG9uZSBpbiB3aXRoaW4gdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAsIEkgbm93 IGJlbGlldmUgdGhhdCBpdCBzaG91bGQgYmUgZG9uZSBpbiBhIG5ldyB3b3JraW5nIGdyb3VwLCBh bmQgdGhhdCB3ZSBzaG91bGQgdHJ5IHRvIGdldCB0aGF0IHdvcmtpbmcgZ3JvdXAgdXAgYW5kIHJ1 bm5pbmcgcHJpb3IgdG8gdGhlIFZhbmNvdXZlciBtZWV0aW5nIGluIE1hcmNoLi4gSSB0aGluaw0K IHRoaXMgZ3JvdXAgc2hvdWxkIHN0YXkgaGVyZSBvbiB0aGUgVHhBdXRoIGxpc3QsIGFuZCBpdOKA mXMgbXkgc3VnZ2VzdGlvbiB0aGF0IHRoZSByZXN1bHRpbmcgd29yayBiZSBjYWxsZWQgT0F1dGgg My4wLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XaHkgYSBuZXcgZ3JvdXA/IEkgdGhpbmsgdGhhdCB0aGUgT0F1dGggd29ya2luZyBn cm91cCBzaG91bGQgcmVtYWluIGZvY3VzZWQgb24gZXh0ZW5kaW5nLCBwYXRjaGluZywgYW5kIGFk YXB0aW5nIE9BdXRoIDIuMCB0byBhIGNoYW5naW5nIHdvcmxkLiBJIHBsYW4gdG8gYmUgZW5nYWdl ZCBpbiBib3RoIGdyb3VwcywgYW5kIEkga25vdyBtb3N0IG9mIHlvdSBhcmUgYXMgd2VsbCwgYnV0 IHRoYXTigJlzIG5vdCB1bml2ZXJzYWwuDQogU2luY2UgT0F1dGggMi4wIGlzIHNvIGVzdGFibGlz aGVkIGFscmVhZHksIHRoZXJlIGFyZSBhIExPVCBvZiBwZW9wbGUgd2hvIGFyZW7igJl0IGdvaW5n IHRvIGJlIGludGVyZXN0ZWQgaW4gc29tZXRoaW5nIG5ldyBhbnkgdGltZSBzb29uLiBCdXQgb24g dGhlIG90aGVyIGhhbmQsIHRoZXJlIGFyZSBhIG51bWJlciBvZiBwZW9wbGUgZm9yIHdob20gT0F1 dGggMi4wIGRvZXMgbm90IHdvcmssIG9yIGlzIGF0IHRoZSB2ZXJ5IGxlYXN0IGEgcG9vciBmaXQs DQogYW5kIHdl4oCZbGwgd2FudCB0byBicmluZyB0aGVtIGluIGF0IHRoaXMgZWFybHkgc3RhZ2Uu IFNvIGV2ZW4gd2l0aCBzaWduaWZpY2FudCBvdmVybGFwLCBJIHRoaW5rIHRoZXJl4oCZcyBlbm91 Z2ggZGlzY29ubmVjdCBpbiB0aGUgY29tbXVuaXR5IGZyb20gYm90aCBzaWRlcyB0aGF0IHdhcnJh bnRzIGEgbmV3IGdyb3VwLiBJbiBhZGRpdGlvbiwgSSB0aGluayB0aGlzIGlzIGEgYmlnIGVub3Vn aCBwaWVjZSBvZiB3b3JrIHRoYXQgaXTigJlzIHNpbXBseSB0b28NCiBtdWNoIGZvciB0aGUgT0F1 dGggd29ya2luZyBncm91cCB0byBiZSBhYmxlIHRvIGZvY3VzIG9uLiBXZSB3b3VsZG7igJl0IGJl IGFibGUgdG8gZ2V0IGFkZGl0aW9uYWwgbWVldGluZyB0aW1lLCBhbmQgT0F1dGggYWxyZWFkeSBo YXMgdHJvdWJsZSBmaXR0aW5nIGludG8gaXRzIHR3byBtZWV0aW5nIHNsb3RzIGFzIGl0IGlzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZ dmUgcHVibGlzaGVkIGEgYmxvZyBwb3N0IGRldGFpbGluZyBtb3JlIG9mIG15IHJhdGlvbmFsZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg aHJlZj0iaHR0cHM6Ly9tZWRpdW0uY29tL0BqdXN0aW5zZWN1cml0eS90aGUtY2FzZS1mb3Itb2F1 dGgtMy0wLXdoeS1hLW5ldy13b3JraW5nLWdyb3VwLWQ2MjI5YmE4ZTM2PyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vbWVkaXVtLmNvbS9AanVzdGluc2VjdXJpdHkvdGhlLWNhc2UtZm9yLW9hdXRo LTMtMC13aHktYS1uZXctd29ya2luZy1ncm91cC1kNjIyOWJhOGUzNj88L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBzdWdnZXN0 IGNoYW5nZXMgdG8gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCBhYm92ZS4gSXTigJlzIG15IGhv cGUgdGhhdCB3ZSBjYW4gZ2V0IHRoZSBjaGFydGVyaW5nIHByb2Nlc3Mgc3RhcnRlZC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCU IEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8 YnI+DQpUeGF1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlR4YXV0aEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlR4YXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tIDxicj4NClR4YXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 VHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VHhhdXRoQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1 dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_5526B52828A64F18BE2D846CCA035D77amazoncom_-- From nobody Fri Dec 20 17:35:08 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE041209EB for ; Fri, 20 Dec 2019 17:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 qxW_zZ4dJ-m2 for ; Fri, 20 Dec 2019 17:35:04 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB651207FC for ; Fri, 20 Dec 2019 17:35:03 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id u1so11794413ljk.7 for ; Fri, 20 Dec 2019 17:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ie0ISi88zSqa+hBpQGqL8o2/MhVjlg4JX74BcL7yoNc=; b=eX11iWvuI0qR82OPL25JRr1yEmDYxDGzFs31OkSiy3YPxXKNFmHEeFJBUm6zSDNiDZ /sNb4ARsVB01BLV4RAZNDNKKyTaI7vYIGEFAPHKA1Eo0Ub/tO5JH6yhHBZYWHsTL4gds DSZQ/bU7JaseK4O5IHpsqnEeby+rD6BBooJHFhOSeGaGu2oh3z/Gmx/GWngqBeTfhvuA TX9G/bCDVNtqHJyOXeUAGsrSWernjZEXjDZbC/tV0k9f3KcLXwr0XimYU483UYY25O5/ KdSsmmHG80tVQCcKINxycuRhZTqo39XAzCXMc9yE9EainYB+knCiblHCwWQJyqe99k5f u9aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ie0ISi88zSqa+hBpQGqL8o2/MhVjlg4JX74BcL7yoNc=; b=AkcRugiM0GLftSeBwMuIwwzIx83d1ED0J3sMAVHcH8G5MfK2iX93Vfhv3TcippOMOJ Xvysxi2Z+qQEhwgqKwqaDJ8g1LdrCwi0h9CYio90qZvIlOSHha0FuvA8S7gXkSbI3o+f Gwl/kMfx9uBhd0KG9hKR1nE3F79xtBXJQhlams6kgof8B8VacAPfeYu1TtTujgYY6q/H 8ZP7m8AQ4BGRFI+jwtJ4t83NYUMGKjmILwldTxQ49feCJDz/rfUxaeUj4obS2sxD3l38 hxH4ucSXBUhLgqJBRU2kHaBWv5TuxAcxxn9upRo+UNjzyGrONQjZ270zxaHJIQp3GYDV qvXQ== X-Gm-Message-State: APjAAAXUDsG01s36zrhSWsx1W+E37PWTmto1PQfmJnNkIHDJkclttSpW XDRyYJPcKJ7EfW+RadrfUAL2uqZh8tDxhAUIyFo= X-Google-Smtp-Source: APXvYqx2LfWXkzo2k5orR+Df51jh1BRIsTtk7BfiwosLdb0YNAgWHR/DjCpdrpM5Ab5HuUt2fbBnmevnnUQ9jbeLDA4= X-Received: by 2002:a2e:a48a:: with SMTP id h10mr11603091lji.254.1576892102096; Fri, 20 Dec 2019 17:35:02 -0800 (PST) MIME-Version: 1.0 References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> In-Reply-To: <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> From: Dick Hardt Date: Fri, 20 Dec 2019 17:34:51 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: Eve Maler , "rdd@cert.org" , "txauth@ietf.org" , Justin Richer , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000983d32059a2ccd79" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 01:35:07 -0000 --000000000000983d32059a2ccd79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Would an automated system as you describe not be acting on behalf of the enterprise? A party does not need to be a person. But perhaps I am not understanding your point. Perhaps you mistyped, but I'm confused with we should not suggest that the client or authorizing party is directly interacting with the AS. We are stating the software client IS interacting with the AS. =E1=90=A7 On Fri, Dec 20, 2019 at 5:08 PM Richard Backman, Annabelle < richanna@amazon.com> wrote: > I=E2=80=99m not sure if this is what Eve had in mind, but consider an aut= omated > system in an enterprise context that has been authorized by an > administrator. The automated system isn=E2=80=99t acting as or on behalf = of the > administrator, and the administrator hasn=E2=80=99t =E2=80=9Cdelegated ac= cess=E2=80=9D; they=E2=80=99ve > *granted* access, just as they do when they assign permissions to > users/groups/roles/etc. > > Maybe I=E2=80=99m being too literal, but =E2=80=9Cthrough an authorizatio= n server=E2=80=9D in > paragraph 1 implies a specific context/information/request flow to me. > Given that one of TxAuth=E2=80=99s features is decoupling the different > communication channels, we should not suggest that the client or > authorizing party is directly interacting with the AS. > > > > =E2=80=93 > > Annabelle Richard Backman > > AWS Identity > > > > > > *From: *Txauth on behalf of Dick Hardt < > dick.hardt@gmail.com> > *Date: *Friday, December 20, 2019 at 4:14 PM > *To: *Eve Maler > *Cc: *"rdd@cert.org" , "txauth@ietf.org" , > Justin Richer , Benjamin Kaduk > *Subject: *Re: [Txauth] TxAuth Proposed Charter > > > > Eve: do you not think the software client is acting on behalf of some > party? Or do you think that software always is acting on behalf of some > party, and the mentioned phrase is redundant? > > > > Justin: a couple questions > > > > 1. What is meant by "Delegation between multiple users" ? > > > > 2. Why do you restrict this to HTTP? > > > > 3. Why is authentication not in scope? > > > > 4. When you say "not backwards compatible with OAuth 2.0 and its > extensions", do you expect to define a new standard to replace RFC 6750? > Developers will have to have a new method to call APIs? > > > > > > On Fri, Dec 20, 2019 at 3:27 PM Eve Maler wrote: > > Re =E2=80=9Cto a software client _acting on behalf of an authorizing part= y_=E2=80=9D: > There is a whole lot of philosophy behind whom the delegated access is > performed on behalf of, unless the scenario is single-user or some "act a= s" > semantic is spelled out on the wire. Does it need to be stated here? What= 's > the consequence if the highlighted phrase were removed? > > Eve Maler (sent from my iPad) | cell +1 425 345 6756 > > > > On Dec 20, 2019, at 4:34 PM, Justin Richer wrote: > > Hi all, > > > > As discussed in Singapore, no matter what forum TxAuth takes, its work > will require a new charter. With that in mind, I=E2=80=99ve taken a bit o= f time to > put together a proposed charter text for the TxAuth work: > > > > This group is chartered to develop a next-generation transactional > authorization and delegation protocol for HTTP-based APIs and their > clients. These transactions will allow an authorizing party to delegate a > right of access for an API or set of APIs through an authorization server > to a software client acting on behalf of an authorizing party. > > > > The group will deliver a protocol specification detailing how a client ca= n > request and obtain delegated access, how an authorization server can > provide delegated access, how an authorized party can authorize delegated > access, and how that authorized access can be communicated to the resourc= es > being protected. These actions will be connected through an explicit > transaction between the client and authorization server, resulting in an > artifact that will allow the client to undertake the delegated action. > > > > Additionally, the delegation process will allow for: > > - Fine-grained specification of resource access > > - Delegation between multiple users > > - Web, mobile, single-page, and other client applications > > > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > > > - Cryptographic agility for keys, message signatures, and proof of > possession > > - User interaction mechanisms including web and non-web methods > > - Token presentation mechanisms and key bindings > > > > The artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 and its extensions. > > > > While this work could be done in within the OAuth working group, I now > believe that it should be done in a new working group, and that we should > try to get that working group up and running prior to the Vancouver meeti= ng > in March.. I think this group should stay here on the TxAuth list, and it= =E2=80=99s > my suggestion that the resulting work be called OAuth 3.0. > > > > Why a new group? I think that the OAuth working group should remain > focused on extending, patching, and adapting OAuth 2.0 to a changing worl= d. > I plan to be engaged in both groups, and I know most of you are as well, > but that=E2=80=99s not universal. Since OAuth 2.0 is so established alrea= dy, there > are a LOT of people who aren=E2=80=99t going to be interested in somethin= g new any > time soon. But on the other hand, there are a number of people for whom > OAuth 2.0 does not work, or is at the very least a poor fit, and we=E2=80= =99ll want > to bring them in at this early stage. So even with significant overlap, I > think there=E2=80=99s enough disconnect in the community from both sides = that > warrants a new group. In addition, I think this is a big enough piece of > work that it=E2=80=99s simply too much for the OAuth working group to be = able to > focus on. We wouldn=E2=80=99t be able to get additional meeting time, and= OAuth > already has trouble fitting into its two meeting slots as it is. > > > > I=E2=80=99ve published a blog post detailing more of my rationale: > > > > > https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-worki= ng-group-d6229ba8e36? > > > > Please suggest changes to the proposed charter text above. It=E2=80=99s m= y hope > that we can get the chartering process started. > > > > =E2=80=94 Justin > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > --000000000000983d32059a2ccd79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would an automated system as you describe not be acting on= behalf of the enterprise? A party does not need to be a person. But perhap= s I am not understanding your point.

Perhaps you mistype= d, but I'm confused with=C2=A0

we should not suggest= that the client or = authorizing party is directly interacting with the AS.

We are stating the software client IS interacting with the= AS.




=
=E1=90=A7

On Fri, Dec 20, 2019 at 5:08 PM Ri= chard Backman, Annabelle <richann= a@amazon.com> wrote:

I=E2=80=99m not sure if this is what Eve had in mind= , but consider an automated system in an enterprise context that has been a= uthorized by an administrator. The automated system isn=E2=80=99t acting as= or on behalf of the administrator, and the administrator hasn=E2=80=99t =E2=80=9Cdelegated access=E2=80=9D; they=E2=80=99ve gran= ted access, just as they do when they assign permissions to users/group= s/roles/etc.

Maybe I=E2=80=99m being too literal, but =E2=80=9Cth= rough an authorization server=E2=80=9D in paragraph 1 implies a specific co= ntext/information/request flow to me. Given that one of TxAuth=E2=80=99s fe= atures is decoupling the different communication channels, we should not suggest that the client or authorizing party is directly interacting w= ith the AS.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Bac= kman

AWS Identity

=C2=A0

=C2=A0

From: = Txauth <txauth-bounces@ietf.org<= /a>> on behalf of Dick Hardt <dick.hardt@gmail.com>
Date: Friday, December 20, 2019 at 4:14 PM
To: Eve Maler <eve@xmlgrrl.com>
Cc: "rdd@cert= .org" <rdd@ce= rt.org>, "= txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: [Txauth] TxAuth Proposed Charter

=C2=A0

Eve: do you not think the software client is acting = on behalf of some party? Or do you think that software always is acting on = behalf of some party, and the mentioned phrase is redundant?

=C2=A0

Justin: a couple questions

=C2=A0

1. What is meant by "Delegation between multipl= e users" ?

=C2=A0

2. Why do you restrict this to HTTP?

=C2=A0

3. Why is authentication not in scope?=

=C2=A0

4. When you say "not backwards compatible with = OAuth 2.0 and its extensions", do you expect to define a new standard = to replace RFC 6750? Developers will have to have a new method to call APIs= ?

=C2=A0

=C2=A0

On Fri, Dec 20, 2019 at 3:27 PM Eve Maler <eve@xmlgrrl.com> wrot= e:

Re =E2=80=9Cto a software client _acting on behalf of= an authorizing party_=E2=80=9D: There is a whole lot of philosophy behind = whom the delegated access is performed on behalf of, unless the scenario is single-user or some "act as" semantic is = spelled out on the wire. Does it need to be stated here? What's the con= sequence if the highlighted phrase were removed?=C2=A0=

Eve Maler (sent from = my iPad) |=C2=A0cell +1 425 345 6756



On Dec 20, 2019, at 4:3= 4 PM, Justin Richer <jricher@mit.edu> wrote:

Hi all,

=C2=A0

As discussed in Singapore, no matter what forum TxAu= th takes, its work will require a new charter. With that in mind, I=E2=80= =99ve taken a bit of time to put together a proposed charter text for the T= xAuth work:

=C2=A0

This group is chartered to develop a next-generation= transactional authorization and delegation protocol for HTTP-based APIs an= d their clients. These transactions will allow an authorizing party to dele= gate a right of access for an API or set of APIs through an authorization server to a software client acting= on behalf of an authorizing party.=C2=A0

=C2=A0

The group will deliver a protocol specification deta= iling how a client can request and obtain delegated access, how an authoriz= ation server can provide delegated access, how an authorized party can auth= orize delegated access, and how that authorized access can be communicated to the resources being protected. Th= ese actions will be connected through an explicit transaction between the c= lient and authorization server, resulting in an artifact that will allow th= e client to undertake the delegated action.=C2=A0

=C2=A0

Additionally, the delegation process will allow for:=

- Fine-grained specification of resource access

- Delegation between multiple users

- Web, mobile, single-page, and other client applica= tions

=C2=A0

The group will define extension points for this prot= ocol to allow for flexibility in areas including:

=C2=A0

- Cryptographic agility for keys, message signatures= , and proof of possession=C2=A0

- User interaction mechanisms including web and non-= web methods

- Token presentation mechanisms and key bindings<= /u>

=C2=A0

The artifacts for this work are not intended or expe= cted to be backwards-compatible with OAuth 2.0 and its extensions.=C2=A0=

=C2=A0

While this work could be done in within the OAuth wo= rking group, I now believe that it should be done in a new working group, a= nd that we should try to get that working group up and running prior to the= Vancouver meeting in March.. I think this group should stay here on the TxAuth list, and it=E2=80=99s my sugges= tion that the resulting work be called OAuth 3.0.=C2=A0

=C2=A0

Why a new group? I think that the OAuth working grou= p should remain focused on extending, patching, and adapting OAuth 2.0 to a= changing world. I plan to be engaged in both groups, and I know most of yo= u are as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so established already, there are a LOT of people who a= ren=E2=80=99t going to be interested in something new any time soon. But on= the other hand, there are a number of people for whom OAuth 2.0 does not w= ork, or is at the very least a poor fit, and we=E2=80=99ll want to bring them in at this early stage. So even with = significant overlap, I think there=E2=80=99s enough disconnect in the commu= nity from both sides that warrants a new group. In addition, I think this i= s a big enough piece of work that it=E2=80=99s simply too much for the OAuth working group to be able to focus on. We wouldn=E2=80= =99t be able to get additional meeting time, and OAuth already has trouble = fitting into its two meeting slots as it is.

=C2=A0

I=E2=80=99ve published a blog post detailing more of= my rationale:

=C2=A0

=C2=A0

Please suggest changes to the proposed charter text = above. It=E2=80=99s my hope that we can get the chartering process started.=

=C2=A0

=C2=A0=E2=80=94 Justin

--
Txauth mailing list
Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth

--000000000000983d32059a2ccd79-- From nobody Fri Dec 20 18:03:52 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BC41209F9 for ; Fri, 20 Dec 2019 18:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.228 X-Spam-Level: ** X-Spam-Status: No, score=2.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 rZXIkA2PjUGo for ; Fri, 20 Dec 2019 18:03:49 -0800 (PST) Received: from alkaline-solutions.com (unknown [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA991209F6 for ; Fri, 20 Dec 2019 18:03:49 -0800 (PST) Received: from [IPv6:2601:282:202:b210:d9b6:2afe:46b2:d3a7] (unknown [IPv6:2601:282:202:b210:d9b6:2afe:46b2:d3a7]) by alkaline-solutions.com (Postfix) with ESMTPSA id 478803155C; Sat, 21 Dec 2019 02:04:59 +0000 (UTC) From: David Waite Content-Type: multipart/alternative; boundary="Apple-Mail=_BE206DEE-E33A-4BE4-B682-4CA30F352471" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 20 Dec 2019 19:03:46 -0700 References: To: Justin Richer , txauth@ietf.org In-Reply-To: Message-Id: <2B4EEA97-BB91-4368-B460-4FE161C9A155@alkaline-solutions.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 02:03:51 -0000 --Apple-Mail=_BE206DEE-E33A-4BE4-B682-4CA30F352471 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 20, 2019, at 3:34 PM, Justin Richer wrote: > transactional authorization and delegation protocol for HTTP-based = APIs and their clients. Its far past time for me to ask this without seeing like an annoying = pedant, but here goes anyway (maybe I _am_ an annoying pedant?): What does =E2=80=9Ctransactional authorization=E2=80=9D mean in this = context? In this sense, are we saying this is a transaction for gaining = authorization? If that is the case, are we talking about transaction in = the sense of an =E2=80=9Cexchange=E2=80=9D (such as token exchange or = the process of trading client credentials for an access token under = client credentials grant today?) Or perhaps that the process of getting = authorization is an atomic action? If we are saying it is a protocol for setting up authorizations which = are transactional, are we specifically talking about authorizations to = preform atomic actions, such as a money transfer? Or is there another definition that I=E2=80=99m missing? The process of gaining proof of authorization does not seem to fit the = definition of being =E2=80=99transactional=E2=80=99 in the atomic sense. = In particular, requests for authorization may be continued with = additional information such as the result of the user hitting an = interaction endpoint, or an attempt to get new proof of authorization = (possibly with different access) off of a previous handle. To me, the two most significant differences between TXAuth and the = existing OAuth 2.x body of work are that: 1. The process of requesting authorization is exclusively made via = direct communication between the client and authorization server, rather = than sometimes through an indirect channel. This comes from the = realizations both that there are plenty of use-cases for delegated = authorization that won=E2=80=99t allow for a simple browser redirect, = and that the optimization of sometimes making a request indirectly - = through insecure parameters in the user channel - isn=E2=80=99t worth = the security consequences. 2. the authorization process itself is made a reified first-class = citizen - today with a transaction handle, perhaps in the future (if I = can make a convincing argument) as a specific authorization resource at = a particular URL. The closest OAuth 2 has to this is the optional = refresh token, which doesn=E2=80=99t have the power to perform = additional client challenges or to make further requests for user = interaction. However, it wouldn=E2=80=99t normally occur to me to use the word = =E2=80=9Ctransaction=E2=80=9D to describe either of these. -DW= --Apple-Mail=_BE206DEE-E33A-4BE4-B682-4CA30F352471 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Dec 20, 2019, at 3:34 = PM, Justin Richer <jricher@mit.edu> wrote:

transactional = authorization and delegation protocol for HTTP-based APIs and their = clients.

Its far past time for me to ask this without seeing = like an annoying pedant, but here goes anyway (maybe I _am_ an annoying = pedant?):

What does = =E2=80=9Ctransactional authorization=E2=80=9D mean in this = context?

In = this sense, are we saying this is a transaction for gaining = authorization? If that is the case, are we talking about transaction in = the sense of an =E2=80=9Cexchange=E2=80=9D (such as token exchange or = the process of trading client credentials for an access token under = client credentials grant today?) Or perhaps that the process of getting = authorization is an atomic action?

If we are saying it is a protocol for = setting up authorizations which are transactional, are we specifically = talking about authorizations to preform atomic actions, such as a money = transfer?

Or = is there another definition that I=E2=80=99m missing?

The process of gaining = proof of authorization does not seem to fit the definition of being = =E2=80=99transactional=E2=80=99 in the atomic sense. In particular, = requests for authorization may be continued with additional information = such as the result of the user hitting an interaction endpoint, or an = attempt to get new proof of authorization (possibly with different = access) off of a previous handle.

To me, the two most significant = differences between TXAuth and the existing OAuth 2.x body of work are = that:

1. The = process of requesting authorization is exclusively made via direct = communication between the client and authorization server, rather than = sometimes through an indirect channel. This comes from the realizations = both that there are plenty of use-cases for delegated authorization that = won=E2=80=99t allow for a simple browser redirect, and that the = optimization of sometimes making a request indirectly - through insecure = parameters in the user channel - isn=E2=80=99t worth the security = consequences.

2.= the authorization process itself is made a reified first-class citizen = - today with a transaction handle, perhaps in the future (if I can make = a convincing argument) as a specific authorization resource at a = particular URL. The closest OAuth 2 has to this is the optional refresh = token, which doesn=E2=80=99t have the power to perform additional client = challenges or to make further requests for user interaction.

However, it wouldn=E2=80=99= t normally occur to me to use the word =E2=80=9Ctransaction=E2=80=9D to = describe either of these.

-DW
= --Apple-Mail=_BE206DEE-E33A-4BE4-B682-4CA30F352471-- From nobody Fri Dec 20 19:15:26 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EE1120919 for ; Fri, 20 Dec 2019 19:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=xmlgrrl-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 zrE_JoCfgfgW for ; Fri, 20 Dec 2019 19:15:22 -0800 (PST) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 56728120906 for ; Fri, 20 Dec 2019 19:15:22 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id 59so14366317otp.12 for ; Fri, 20 Dec 2019 19:15:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xmlgrrl-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=OrNBb0A9N1webfmSEPVrkHELUVKFuOPW16iLeZ6cvtI=; b=kN9hKTXQRBtJqBVlWnFgip0N7wA8yOUsxYoKNBeSn9HmE6KaBDsh2b48kN9GNCQ9QL Yzgo6kzEzz8eh4ORyC8CD4vCIb9x0Ytmsd1lBHivKmIDlC+Vie1H7xb8AJoT31ldxOhy jL5z3rniPWT2TMLbMiqAX44TP+Xkxqhjydj4c5B6JRiNaR45NMrVkvBG1TqLov6cVWxq vv8wR4KXu8W+arN3wmyvuni528VdWHRvqRA29NuuHXnfogEvj3/ft1+gs2iR4XblfxWB edFcoe2L135KhYJympqU7XdzLn0OAR8m1OWbtDtUy+7rIKlCD5z+dZuD7B/07/vm0Fix E1VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=OrNBb0A9N1webfmSEPVrkHELUVKFuOPW16iLeZ6cvtI=; b=aMKv1TnFEO4bdScNYwZAFihJGz3WmnX5e9P2r+zmfCVe/IN2symc5VbVIefiMPCBFY k1tUece8QPIiViCyCX3BMoqYjmdyH0CwgxrR7znbtlClg5Yj/OmRheTd8ND0gUw88QuI MvuCjxw4Z0iiVK8/L+YrnzuiPV1L/T2pyRsLlhQHFhWQVP6hlkcwTmrpzsXUd9pLZGx3 CftAxguZjgA0tRNurxiLoLZhH6lxU5rmFJGn/6z/US/pNKZzT45r1HAp8OgGiVXzzwvi UbRMXnWQE8T/LVN/TacqoxyGJFblngVOaQaWerpznEqgoNeKWXSI0fP3tmTPZ9kira+p 7Cpg== X-Gm-Message-State: APjAAAXI9hmyUxL14B9t9FGNCNTInc8K3mEUmcz6soVmO8wXT9EXkrnI GwcHEE2Qw1DV5ghp+ibK6591ew== X-Google-Smtp-Source: APXvYqzIivOK7IV7wrCxBx0Y87ohQB77zZs1sRJzhufERxVYsMlkzcRzCLQ0kshZHBj0Hix1zDIJvw== X-Received: by 2002:a9d:6f8f:: with SMTP id h15mr17842830otq.1.1576898121508; Fri, 20 Dec 2019 19:15:21 -0800 (PST) Received: from [192.168.168.101] ([47.188.76.15]) by smtp.gmail.com with ESMTPSA id m89sm2864975otc.41.2019.12.20.19.15.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Dec 2019 19:15:20 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-A652E46E-DB4C-4F81-9244-3F3A8A9191CE Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Eve Maler In-Reply-To: <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> Date: Fri, 20 Dec 2019 21:15:19 -0600 Cc: Dick Hardt , "rdd@cert.org" , "txauth@ietf.org" , Justin Richer , Benjamin Kaduk Message-Id: <159AB77B-1189-41F0-A016-E1F16DEA5EAC@xmlgrrl.com> References: <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> To: "Richard Backman, Annabelle" X-Mailer: iPad Mail (17C54) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 03:15:25 -0000 --Apple-Mail-A652E46E-DB4C-4F81-9244-3F3A8A9191CE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I was thinking of Dick's second construction: Software always acts on behalf= of some party because it can't be a ''party" itself, so the phrase may just= raise more questions than it answers. In business-legal terms, a client is v= ery probably acting only as a limited agent or fiduciary for the resource ow= ner, for starters, given that it has some third-party publisher/operator and= imposes T's and C's. The UMA group has done significant business-legal modeling work around multi= -party delegation of access rights. If there's interest I can provide a summ= ary. There are certainly scenarios, maybe like Annabelle's?, where a party o= n either end might be a "legal person" (enterprise) rather than a human. Eve Maler (sent from my iPad) | cell +1 425 345 6756 > On Dec 20, 2019, at 7:08 PM, Richard Backman, Annabelle wrote: >=20 > =EF=BB=BF > I=E2=80=99m not sure if this is what Eve had in mind, but consider an auto= mated system in an enterprise context that has been authorized by an adminis= trator. The automated system isn=E2=80=99t acting as or on behalf of the adm= inistrator, and the administrator hasn=E2=80=99t =E2=80=9Cdelegated access=E2= =80=9D; they=E2=80=99ve granted access, just as they do when they assign per= missions to users/groups/roles/etc. > Maybe I=E2=80=99m being too literal, but =E2=80=9Cthrough an authorization= server=E2=80=9D in paragraph 1 implies a specific context/information/reque= st flow to me. Given that one of TxAuth=E2=80=99s features is decoupling the= different communication channels, we should not suggest that the client or a= uthorizing party is directly interacting with the AS. > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: Txauth on behalf of Dick Hardt > Date: Friday, December 20, 2019 at 4:14 PM > To: Eve Maler > Cc: "rdd@cert.org" , "txauth@ietf.org" , Ju= stin Richer , Benjamin Kaduk > Subject: Re: [Txauth] TxAuth Proposed Charter > =20 > Eve: do you not think the software client is acting on behalf of some part= y? Or do you think that software always is acting on behalf of some party, a= nd the mentioned phrase is redundant? > =20 > Justin: a couple questions > =20 > 1. What is meant by "Delegation between multiple users" ? > =20 > 2. Why do you restrict this to HTTP? > =20 > 3. Why is authentication not in scope? > =20 > 4. When you say "not backwards compatible with OAuth 2.0 and its extension= s", do you expect to define a new standard to replace RFC 6750? Developers w= ill have to have a new method to call APIs? > =20 > =20 > On Fri, Dec 20, 2019 at 3:27 PM Eve Maler wrote: > Re =E2=80=9Cto a software client _acting on behalf of an authorizing party= _=E2=80=9D: There is a whole lot of philosophy behind whom the delegated acc= ess is performed on behalf of, unless the scenario is single-user or some "a= ct as" semantic is spelled out on the wire. Does it need to be stated here? W= hat's the consequence if the highlighted phrase were removed?=20 >=20 > Eve Maler (sent from my iPad) | cell +1 425 345 6756 >=20 >=20 > On Dec 20, 2019, at 4:34 PM, Justin Richer wrote: >=20 > Hi all, > =20 > As discussed in Singapore, no matter what forum TxAuth takes, its work wil= l require a new charter. With that in mind, I=E2=80=99ve taken a bit of time= to put together a proposed charter text for the TxAuth work: > =20 > This group is chartered to develop a next-generation transactional authori= zation and delegation protocol for HTTP-based APIs and their clients. These t= ransactions will allow an authorizing party to delegate a right of access fo= r an API or set of APIs through an authorization server to a software client= acting on behalf of an authorizing party.=20 > =20 > The group will deliver a protocol specification detailing how a client can= request and obtain delegated access, how an authorization server can provid= e delegated access, how an authorized party can authorize delegated access, a= nd how that authorized access can be communicated to the resources being pro= tected. These actions will be connected through an explicit transaction betw= een the client and authorization server, resulting in an artifact that will a= llow the client to undertake the delegated action.=20 > =20 > Additionally, the delegation process will allow for: > - Fine-grained specification of resource access > - Delegation between multiple users > - Web, mobile, single-page, and other client applications > =20 > The group will define extension points for this protocol to allow for flex= ibility in areas including: > =20 > - Cryptographic agility for keys, message signatures, and proof of possess= ion=20 > - User interaction mechanisms including web and non-web methods > - Token presentation mechanisms and key bindings > =20 > The artifacts for this work are not intended or expected to be backwards-c= ompatible with OAuth 2.0 and its extensions.=20 > =20 > While this work could be done in within the OAuth working group, I now bel= ieve that it should be done in a new working group, and that we should try t= o get that working group up and running prior to the Vancouver meeting in Ma= rch.. I think this group should stay here on the TxAuth list, and it=E2=80=99= s my suggestion that the resulting work be called OAuth 3.0.=20 > =20 > Why a new group? I think that the OAuth working group should remain focuse= d on extending, patching, and adapting OAuth 2.0 to a changing world. I plan= to be engaged in both groups, and I know most of you are as well, but that=E2= =80=99s not universal. Since OAuth 2.0 is so established already, there are a= LOT of people who aren=E2=80=99t going to be interested in something new an= y time soon. But on the other hand, there are a number of people for whom OA= uth 2.0 does not work, or is at the very least a poor fit, and we=E2=80=99ll= want to bring them in at this early stage. So even with significant overlap= , I think there=E2=80=99s enough disconnect in the community from both sides= that warrants a new group. In addition, I think this is a big enough piece o= f work that it=E2=80=99s simply too much for the OAuth working group to be a= ble to focus on. We wouldn=E2=80=99t be able to get additional meeting time,= and OAuth already has trouble fitting into its two meeting slots as it is. > =20 > I=E2=80=99ve published a blog post detailing more of my rationale: > =20 > https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? > =20 > Please suggest changes to the proposed charter text above. It=E2=80=99s my= hope that we can get the chartering process started. > =20 > =E2=80=94 Justin > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail-A652E46E-DB4C-4F81-9244-3F3A8A9191CE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I was thinking of Dick's second constructio= n: Software always acts on behalf of some party because it can't be a ''part= y" itself, so the phrase may just raise more questions than it answers. In b= usiness-legal terms, a client is very probably acting only as a limited agent or fiduciary for the resource owner, for starters, given that it ha= s some third-party publisher/operator and imposes T's and C's.

The UMA group has done significant business-legal modeling work around= multi-party delegation of access rights. If there's interest I can provide a= summary. There are certainly scenarios, maybe like Annabelle's?, where a pa= rty on either end might be a "legal person" (enterprise) rather than a human= .

Eve M= aler (sent from my iPad) | cell= +1 425 345 6756

On Dec 20, 2019, at 7:08 PM, Richard Backman, Annabelle <richanna@a= mazon.com> wrote:

=EF=BB=BF

I=E2=80=99m not sure if this is what Eve had in mind,= but consider an automated system in an enterprise context that has been aut= horized by an administrator. The automated system isn=E2=80=99t acting as or= on behalf of the administrator, and the administrator hasn=E2=80=99t =E2=80=9Cdelegated access=E2=80=9D; they=E2=80=99ve grant= ed access, just as they do when they assign permissions to users/groups/= roles/etc.

Maybe I=E2=80=99m being too literal, but =E2=80=9Cthr= ough an authorization server=E2=80=9D in paragraph 1 implies a specific cont= ext/information/request flow to me. Given that one of TxAuth=E2=80=99s featu= res is decoupling the different communication channels, we should not suggest that the client or authorizing party is directly interacting wi= th the AS.

 

=E2=80=93 =

Annabelle Richard Ba= ckman

AWS Identity

 

 

From:= Txauth <txauth-b= ounces@ietf.org> on behalf of Dick Hardt <dick.hardt@gmail.com>
= Date: Friday, December 20, 2019 at 4:14 PM
To: Eve Maler <eve@xmlgrrl.com>
Cc: "rdd@cert.org" <rdd@cert.org>, "txauth@ietf.org" <txauth= @ietf.org>, Justin Richer <jricher@mit.edu>, Benjamin Kaduk <kad= uk@mit.edu>
Subject: Re: [Txauth] TxAuth Proposed Charter

 

Eve: do you not think the software client is acting o= n behalf of some party? Or do you think that software always is acting on be= half of some party, and the mentioned phrase is redundant?

 

Justin: a couple questions

 

1. What is meant by "Delegation between multiple user= s" ?

 

2. Why do you restrict this to HTTP?

 

3. Why is authentication not in scope?

=

 

4. When you say "not backwards compatible with OAuth 2= .0 and its extensions", do you expect to define a new standard to replace RFC= 6750? Developers will have to have a new method to call APIs?

 

 

On Fri, Dec 20, 2019 at 3:27 PM Eve Maler <eve@xmlgrrl.com> wrote:

Re =E2=80=9Cto a software client _acting on behalf of= an authorizing party_=E2=80=9D: There is a whole lot of philosophy behind w= hom the delegated access is performed on behalf of, unless the scenario is single-user or some "act as" semantic is spelled out= on the wire. Does it need to be stated here? What's the consequence if the h= ighlighted phrase were removed? 

Eve Maler (sent from= my iPad) | cell +1 425 345 6756



On Dec 20, 2019, at 4:= 34 PM, Justin Richer <jricher@mit.edu> wrote:

Hi all,

 

As discussed in Singapore, no matter what forum TxAut= h takes, its work will require a new charter. With that in mind, I=E2=80=99v= e taken a bit of time to put together a proposed charter text for the TxAuth= work:

 

This group is chartered to develop a next-generation t= ransactional authorization and delegation protocol for HTTP-based APIs and t= heir clients. These transactions will allow an authorizing party to delegate= a right of access for an API or set of APIs through an authorization server to a software client acting o= n behalf of an authorizing party. 

 

The group will deliver a protocol specification detai= ling how a client can request and obtain delegated access, how an authorizat= ion server can provide delegated access, how an authorized party can authori= ze delegated access, and how that authorized access can be communicated to the resources being protected. The= se actions will be connected through an explicit transaction between the cli= ent and authorization server, resulting in an artifact that will allow the c= lient to undertake the delegated action. 

 

Additionally, the delegation process will allow for:<= o:p>

- Fine-grained specification of resource access<= /o:p>

- Delegation between multiple users

- Web, mobile, single-page, and other client applicat= ions

 

The group will define extension points for this proto= col to allow for flexibility in areas including:

 

- Cryptographic agility for keys, message signatures,= and proof of possession 

- User interaction mechanisms including web and non-w= eb methods

- Token presentation mechanisms and key bindings=

 

The artifacts for this work are not intended or expec= ted to be backwards-compatible with OAuth 2.0 and its extensions. =

 

While this work could be done in within the OAuth wor= king group, I now believe that it should be done in a new working group, and= that we should try to get that working group up and running prior to the Va= ncouver meeting in March.. I think this group should stay here on the TxAuth list, and it=E2=80=99s my suggest= ion that the resulting work be called OAuth 3.0. 

 

Why a new group? I think that the OAuth working group= should remain focused on extending, patching, and adapting OAuth 2.0 to a c= hanging world. I plan to be engaged in both groups, and I know most of you a= re as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so established already, there are a LOT of people who ar= en=E2=80=99t going to be interested in something new any time soon. But on t= he other hand, there are a number of people for whom OAuth 2.0 does not work= , or is at the very least a poor fit, and we=E2=80=99ll want to bring them in at this early stage. So even with s= ignificant overlap, I think there=E2=80=99s enough disconnect in the communi= ty from both sides that warrants a new group. In addition, I think this is a= big enough piece of work that it=E2=80=99s simply too much for the OAuth working group to be able to focus on. We wouldn=E2=80=99= t be able to get additional meeting time, and OAuth already has trouble fitt= ing into its two meeting slots as it is.

 

I=E2=80=99ve published a blog post detailing more of m= y rationale:

 

 

Please suggest changes to the proposed charter text a= bove. It=E2=80=99s my hope that we can get the chartering process started.

 

 =E2=80=94 Justin

--
Txauth mailing list
Txauth@ietf.org
= h= ttps://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org
= h= ttps://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail-A652E46E-DB4C-4F81-9244-3F3A8A9191CE-- From nobody Fri Dec 20 23:09:49 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749E9120A28 for ; Fri, 20 Dec 2019 23:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.599 X-Spam-Level: X-Spam-Status: No, score=-12.599 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 SXtxup2Cqiqb for ; Fri, 20 Dec 2019 23:09:43 -0800 (PST) Received: from smtp-fw-9102.amazon.com (smtp-fw-9102.amazon.com [207.171.184.29]) (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 5EE31120A24 for ; Fri, 20 Dec 2019 23:09:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1576912183; x=1608448183; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GJW2aFZr1ns0jWi9XaJKHuQyNI928zBmVvC6Hv3bKQI=; b=OuloljWxSUHXnJDOdtsSpbQIh2P99JSTdQN889QdPSodD0qeLvCVFiyP wQSWJWemTAcp0MFMDaqs/tPr1TLApDRtOhMblOxSNbg0Y/5wYyy7qpZl2 wra79MPXxoAdu4EjjTpa0jZsiHunPxl+673x8UTwhHoyMrjt8XOsvxP4W 8=; IronPort-SDR: KCmaLrWSbpRei8C1PLMGc+R2PgR23Q/4534b7GUY2YCzlN/Q4zthBopjqXYd5OSYMlbl+eygmf /lYUzK4w/cQQ== X-IronPort-AV: E=Sophos; i="5.69,338,1571702400"; d="scan'208,217"; a="14928407" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-81e76b79.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9102.sea19.amazon.com with ESMTP; 21 Dec 2019 07:09:33 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2b-81e76b79.us-west-2.amazon.com (Postfix) with ESMTPS id 5F8E1A21BC; Sat, 21 Dec 2019 07:09:32 +0000 (UTC) Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 21 Dec 2019 07:09:31 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 21 Dec 2019 07:09:31 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Sat, 21 Dec 2019 07:09:31 +0000 From: "Richard Backman, Annabelle" To: Dick Hardt CC: Eve Maler , "rdd@cert.org" , "txauth@ietf.org" , Justin Richer , Benjamin Kaduk Thread-Topic: [Txauth] TxAuth Proposed Charter Thread-Index: AQHVt4W+Cd5+sniY+0u9RUqE6+8fD6fDqwuAgAAMvQD//4lSAIAAjYeAgABdgjw= Date: Sat, 21 Dec 2019 07:09:31 +0000 Message-ID: <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_958491C881C8469D973D40AD9769F21Camazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 07:09:46 -0000 --_000_958491C881C8469D973D40AD9769F21Camazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBEZWMgMjAsIDIwMTksIGF0IDU6MzUgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21h aWwuY29tPiB3cm90ZToNCg0K77u/DQpXb3VsZCBhbiBhdXRvbWF0ZWQgc3lzdGVtIGFzIHlvdSBk ZXNjcmliZSBub3QgYmUgYWN0aW5nIG9uIGJlaGFsZiBvZiB0aGUgZW50ZXJwcmlzZT8gQSBwYXJ0 eSBkb2VzIG5vdCBuZWVkIHRvIGJlIGEgcGVyc29uLiBCdXQgcGVyaGFwcyBJIGFtIG5vdCB1bmRl cnN0YW5kaW5nIHlvdXIgcG9pbnQuDQoNClllcywgaW4gdGhlIHNhbWUgc2Vuc2UgdGhhdCBhbnkg ZW1wbG95ZWUgb2YgdGhlIGVudGVycHJpc2UgYWN0cyBvbiBpdHMgYmVoYWxmLiBUaGUgaW1wb3J0 YW50IHRoaW5nIGlzIHRoYXQgd2UgcmVjb2duaXplIHRoYXQgdGhlIGF1dG9tYXRlZCBzeXN0ZW0g aXNu4oCZdCBhY3RpbmcgSW4gYmVoYWxmIG9mIOKAnEJvYiwgdGhlIGFkbWluaXN0cmF0b3Igd2hv IHNldCBpdCB1cC7igJ0gVGhlIGF1dGhvcml6aW5nIGFjdG9yIChCb2IpIG1heSBiZSBhdXRob3Jp emluZyB0aGUgY2xpZW50IG9uIGJlaGFsZiBvZiB0aGUgYXV0aG9yaXppbmcgcGFydHkgKHRoZSBl bnRlcnByaXNlKS4gRnJvbSBhbiBhdWRpdGluZyBhbmQgZ292ZXJuYW5jZSBzdGFuZHBvaW50LCB0 aGUgY2xpZW504oCZcyBhY3Rpb25zIHNob3VsZCBiZSBhdHRyaWJ1dGVkIHRvIHRoZSBjbGllbnQg KGFuZCB0aGUgZW50ZXJwcmlzZSwgaWYgaXTigJlzIGFjdGluZyBpbiBhIG11bHRpIHRlbmFudCBl bnZpcm9ubWVudCksIG5vdCBCb2IuDQoNCndlIHNob3VsZCBub3Qgc3VnZ2VzdCB0aGF0IHRoZSBj bGllbnQgb3IgYXV0aG9yaXppbmcgcGFydHkgaXMgZGlyZWN0bHkgaW50ZXJhY3Rpbmcgd2l0aCB0 aGUgQVMuDQoNCldlIGFyZSBzdGF0aW5nIHRoZSBzb2Z0d2FyZSBjbGllbnQgSVMgaW50ZXJhY3Rp bmcgd2l0aCB0aGUgQVMuDQoNCiBUaGUga2V5IHdvcmQgaXMg4oCcZGlyZWN0bHku4oCdIEFyZSB3 ZSBhc3N1bWluZyB0aGUgY2xpZW50IHdpbGwgYWx3YXlzIGRpcmVjdGx5IGNvbW11bmljYXRlIHdp dGggdGhlIEFTPyBDb3VsZCB0cmFuc2FjdGlvbnMgc3RhcnQgd2l0aCBhIGNsaWVudCBjYWxsaW5n IGFuIFJTLCB3aGljaCBjYWxscyB0aGUgQVM/IEnigJltIG9ubHkganVzdCBzdGFydGluZyB0byBl eHBsb3JlIHRoaXMgIGlkZWEgYnV0IGl0IHNlZW1zIGludGVyZXN0aW5nLiBUaGVyZeKAmXMgc3Rp bGwgYW4gQVMgaW52b2x2ZWQsIGFuZCBhIHRyYW5zYWN0aW9uIGJldHdlZW4gQVMgYW5kIGNsaWVu dCwgYnV0IG5vdCBuZWNlc3NhcmlseSBkaXJlY3QgaW50ZXJhY3Rpb24uDQoNCkFzIEkgc2FpZCwg bWF5YmUgSeKAmW0gYmVpbmcgdG9vIGxpdGVyYWwuDQoNCltodHRwczovL21haWxmb29nYWUuYXBw c3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZ0eXBlPXpl cm9jb250ZW50Jmd1aWQ9ODExMjdhOWQtMDY0MS00MjNjLWJlNzctODEyMDcwMjQxMTAzXeGQpw0K T24gRnJpLCBEZWMgMjAsIDIwMTkgYXQgNTowOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxs ZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3Rl Og0KSeKAmW0gbm90IHN1cmUgaWYgdGhpcyBpcyB3aGF0IEV2ZSBoYWQgaW4gbWluZCwgYnV0IGNv bnNpZGVyIGFuIGF1dG9tYXRlZCBzeXN0ZW0gaW4gYW4gZW50ZXJwcmlzZSBjb250ZXh0IHRoYXQg aGFzIGJlZW4gYXV0aG9yaXplZCBieSBhbiBhZG1pbmlzdHJhdG9yLiBUaGUgYXV0b21hdGVkIHN5 c3RlbSBpc27igJl0IGFjdGluZyBhcyBvciBvbiBiZWhhbGYgb2YgdGhlIGFkbWluaXN0cmF0b3Is IGFuZCB0aGUgYWRtaW5pc3RyYXRvciBoYXNu4oCZdCDigJxkZWxlZ2F0ZWQgYWNjZXNz4oCdOyB0 aGV54oCZdmUgZ3JhbnRlZCBhY2Nlc3MsIGp1c3QgYXMgdGhleSBkbyB3aGVuIHRoZXkgYXNzaWdu IHBlcm1pc3Npb25zIHRvIHVzZXJzL2dyb3Vwcy9yb2xlcy9ldGMuDQpNYXliZSBJ4oCZbSBiZWlu ZyB0b28gbGl0ZXJhbCwgYnV0IOKAnHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJ0g aW4gcGFyYWdyYXBoIDEgaW1wbGllcyBhIHNwZWNpZmljIGNvbnRleHQvaW5mb3JtYXRpb24vcmVx dWVzdCBmbG93IHRvIG1lLiBHaXZlbiB0aGF0IG9uZSBvZiBUeEF1dGjigJlzIGZlYXR1cmVzIGlz IGRlY291cGxpbmcgdGhlIGRpZmZlcmVudCBjb21tdW5pY2F0aW9uIGNoYW5uZWxzLCB3ZSBzaG91 bGQgbm90IHN1Z2dlc3QgdGhhdCB0aGUgY2xpZW50IG9yIGF1dGhvcml6aW5nIHBhcnR5IGlzIGRp cmVjdGx5IGludGVyYWN0aW5nIHdpdGggdGhlIEFTLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERp Y2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNv bT4+DQpEYXRlOiBGcmlkYXksIERlY2VtYmVyIDIwLCAyMDE5IGF0IDQ6MTQgUE0NClRvOiBFdmUg TWFsZXIgPGV2ZUB4bWxncnJsLmNvbTxtYWlsdG86ZXZlQHhtbGdycmwuY29tPj4NCkNjOiAicmRk QGNlcnQub3JnPG1haWx0bzpyZGRAY2VydC5vcmc+IiA8cmRkQGNlcnQub3JnPG1haWx0bzpyZGRA Y2VydC5vcmc+PiwgInR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPiIgPHR4 YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPj4sIEp1c3RpbiBSaWNoZXIgPGpy aWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4sIEJlbmphbWluIEthZHVrIDxr YWR1a0BtaXQuZWR1PG1haWx0bzprYWR1a0BtaXQuZWR1Pj4NClN1YmplY3Q6IFJlOiBbVHhhdXRo XSBUeEF1dGggUHJvcG9zZWQgQ2hhcnRlcg0KDQpFdmU6IGRvIHlvdSBub3QgdGhpbmsgdGhlIHNv ZnR3YXJlIGNsaWVudCBpcyBhY3Rpbmcgb24gYmVoYWxmIG9mIHNvbWUgcGFydHk/IE9yIGRvIHlv dSB0aGluayB0aGF0IHNvZnR3YXJlIGFsd2F5cyBpcyBhY3Rpbmcgb24gYmVoYWxmIG9mIHNvbWUg cGFydHksIGFuZCB0aGUgbWVudGlvbmVkIHBocmFzZSBpcyByZWR1bmRhbnQ/DQoNCkp1c3Rpbjog YSBjb3VwbGUgcXVlc3Rpb25zDQoNCjEuIFdoYXQgaXMgbWVhbnQgYnkgIkRlbGVnYXRpb24gYmV0 d2VlbiBtdWx0aXBsZSB1c2VycyIgPw0KDQoyLiBXaHkgZG8geW91IHJlc3RyaWN0IHRoaXMgdG8g SFRUUD8NCg0KMy4gV2h5IGlzIGF1dGhlbnRpY2F0aW9uIG5vdCBpbiBzY29wZT8NCg0KNC4gV2hl biB5b3Ugc2F5ICJub3QgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBPQXV0aCAyLjAgYW5kIGl0 cyBleHRlbnNpb25zIiwgZG8geW91IGV4cGVjdCB0byBkZWZpbmUgYSBuZXcgc3RhbmRhcmQgdG8g cmVwbGFjZSBSRkMgNjc1MD8gRGV2ZWxvcGVycyB3aWxsIGhhdmUgdG8gaGF2ZSBhIG5ldyBtZXRo b2QgdG8gY2FsbCBBUElzPw0KDQoNCk9uIEZyaSwgRGVjIDIwLCAyMDE5IGF0IDM6MjcgUE0gRXZl IE1hbGVyIDxldmVAeG1sZ3JybC5jb208bWFpbHRvOmV2ZUB4bWxncnJsLmNvbT4+IHdyb3RlOg0K UmUg4oCcdG8gYSBzb2Z0d2FyZSBjbGllbnQgX2FjdGluZyBvbiBiZWhhbGYgb2YgYW4gYXV0aG9y aXppbmcgcGFydHlf4oCdOiBUaGVyZSBpcyBhIHdob2xlIGxvdCBvZiBwaGlsb3NvcGh5IGJlaGlu ZCB3aG9tIHRoZSBkZWxlZ2F0ZWQgYWNjZXNzIGlzIHBlcmZvcm1lZCBvbiBiZWhhbGYgb2YsIHVu bGVzcyB0aGUgc2NlbmFyaW8gaXMgc2luZ2xlLXVzZXIgb3Igc29tZSAiYWN0IGFzIiBzZW1hbnRp YyBpcyBzcGVsbGVkIG91dCBvbiB0aGUgd2lyZS4gRG9lcyBpdCBuZWVkIHRvIGJlIHN0YXRlZCBo ZXJlPyBXaGF0J3MgdGhlIGNvbnNlcXVlbmNlIGlmIHRoZSBoaWdobGlnaHRlZCBwaHJhc2Ugd2Vy ZSByZW1vdmVkPw0KRXZlIE1hbGVyIChzZW50IGZyb20gbXkgaVBhZCkgfCBjZWxsICsxIDQyNSAz NDUgNjc1Ng0KDQoNCk9uIERlYyAyMCwgMjAxOSwgYXQgNDozNCBQTSwgSnVzdGluIFJpY2hlciA8 anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCkhpIGFsbCwN Cg0KQXMgZGlzY3Vzc2VkIGluIFNpbmdhcG9yZSwgbm8gbWF0dGVyIHdoYXQgZm9ydW0gVHhBdXRo IHRha2VzLCBpdHMgd29yayB3aWxsIHJlcXVpcmUgYSBuZXcgY2hhcnRlci4gV2l0aCB0aGF0IGlu IG1pbmQsIEnigJl2ZSB0YWtlbiBhIGJpdCBvZiB0aW1lIHRvIHB1dCB0b2dldGhlciBhIHByb3Bv c2VkIGNoYXJ0ZXIgdGV4dCBmb3IgdGhlIFR4QXV0aCB3b3JrOg0KDQpUaGlzIGdyb3VwIGlzIGNo YXJ0ZXJlZCB0byBkZXZlbG9wIGEgbmV4dC1nZW5lcmF0aW9uIHRyYW5zYWN0aW9uYWwgYXV0aG9y aXphdGlvbiBhbmQgZGVsZWdhdGlvbiBwcm90b2NvbCBmb3IgSFRUUC1iYXNlZCBBUElzIGFuZCB0 aGVpciBjbGllbnRzLiBUaGVzZSB0cmFuc2FjdGlvbnMgd2lsbCBhbGxvdyBhbiBhdXRob3Jpemlu ZyBwYXJ0eSB0byBkZWxlZ2F0ZSBhIHJpZ2h0IG9mIGFjY2VzcyBmb3IgYW4gQVBJIG9yIHNldCBv ZiBBUElzIHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gYSBzb2Z0d2FyZSBjbGll bnQgYWN0aW5nIG9uIGJlaGFsZiBvZiBhbiBhdXRob3JpemluZyBwYXJ0eS4NCg0KVGhlIGdyb3Vw IHdpbGwgZGVsaXZlciBhIHByb3RvY29sIHNwZWNpZmljYXRpb24gZGV0YWlsaW5nIGhvdyBhIGNs aWVudCBjYW4gcmVxdWVzdCBhbmQgb2J0YWluIGRlbGVnYXRlZCBhY2Nlc3MsIGhvdyBhbiBhdXRo b3JpemF0aW9uIHNlcnZlciBjYW4gcHJvdmlkZSBkZWxlZ2F0ZWQgYWNjZXNzLCBob3cgYW4gYXV0 aG9yaXplZCBwYXJ0eSBjYW4gYXV0aG9yaXplIGRlbGVnYXRlZCBhY2Nlc3MsIGFuZCBob3cgdGhh dCBhdXRob3JpemVkIGFjY2VzcyBjYW4gYmUgY29tbXVuaWNhdGVkIHRvIHRoZSByZXNvdXJjZXMg YmVpbmcgcHJvdGVjdGVkLiBUaGVzZSBhY3Rpb25zIHdpbGwgYmUgY29ubmVjdGVkIHRocm91Z2gg YW4gZXhwbGljaXQgdHJhbnNhY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCBhdXRob3JpemF0 aW9uIHNlcnZlciwgcmVzdWx0aW5nIGluIGFuIGFydGlmYWN0IHRoYXQgd2lsbCBhbGxvdyB0aGUg Y2xpZW50IHRvIHVuZGVydGFrZSB0aGUgZGVsZWdhdGVkIGFjdGlvbi4NCg0KQWRkaXRpb25hbGx5 LCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYWxsb3cgZm9yOg0KLSBGaW5lLWdyYWluZWQg c3BlY2lmaWNhdGlvbiBvZiByZXNvdXJjZSBhY2Nlc3MNCi0gRGVsZWdhdGlvbiBiZXR3ZWVuIG11 bHRpcGxlIHVzZXJzDQotIFdlYiwgbW9iaWxlLCBzaW5nbGUtcGFnZSwgYW5kIG90aGVyIGNsaWVu dCBhcHBsaWNhdGlvbnMNCg0KVGhlIGdyb3VwIHdpbGwgZGVmaW5lIGV4dGVuc2lvbiBwb2ludHMg Zm9yIHRoaXMgcHJvdG9jb2wgdG8gYWxsb3cgZm9yIGZsZXhpYmlsaXR5IGluIGFyZWFzIGluY2x1 ZGluZzoNCg0KLSBDcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3NhZ2Ugc2lnbmF0 dXJlcywgYW5kIHByb29mIG9mIHBvc3Nlc3Npb24NCi0gVXNlciBpbnRlcmFjdGlvbiBtZWNoYW5p c21zIGluY2x1ZGluZyB3ZWIgYW5kIG5vbi13ZWIgbWV0aG9kcw0KLSBUb2tlbiBwcmVzZW50YXRp b24gbWVjaGFuaXNtcyBhbmQga2V5IGJpbmRpbmdzDQoNClRoZSBhcnRpZmFjdHMgZm9yIHRoaXMg d29yayBhcmUgbm90IGludGVuZGVkIG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1jb21wYXRp YmxlIHdpdGggT0F1dGggMi4wIGFuZCBpdHMgZXh0ZW5zaW9ucy4NCg0KV2hpbGUgdGhpcyB3b3Jr IGNvdWxkIGJlIGRvbmUgaW4gd2l0aGluIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLCBJIG5vdyBi ZWxpZXZlIHRoYXQgaXQgc2hvdWxkIGJlIGRvbmUgaW4gYSBuZXcgd29ya2luZyBncm91cCwgYW5k IHRoYXQgd2Ugc2hvdWxkIHRyeSB0byBnZXQgdGhhdCB3b3JraW5nIGdyb3VwIHVwIGFuZCBydW5u aW5nIHByaW9yIHRvIHRoZSBWYW5jb3V2ZXIgbWVldGluZyBpbiBNYXJjaC4uIEkgdGhpbmsgdGhp cyBncm91cCBzaG91bGQgc3RheSBoZXJlIG9uIHRoZSBUeEF1dGggbGlzdCwgYW5kIGl04oCZcyBt eSBzdWdnZXN0aW9uIHRoYXQgdGhlIHJlc3VsdGluZyB3b3JrIGJlIGNhbGxlZCBPQXV0aCAzLjAu DQoNCldoeSBhIG5ldyBncm91cD8gSSB0aGluayB0aGF0IHRoZSBPQXV0aCB3b3JraW5nIGdyb3Vw IHNob3VsZCByZW1haW4gZm9jdXNlZCBvbiBleHRlbmRpbmcsIHBhdGNoaW5nLCBhbmQgYWRhcHRp bmcgT0F1dGggMi4wIHRvIGEgY2hhbmdpbmcgd29ybGQuIEkgcGxhbiB0byBiZSBlbmdhZ2VkIGlu IGJvdGggZ3JvdXBzLCBhbmQgSSBrbm93IG1vc3Qgb2YgeW91IGFyZSBhcyB3ZWxsLCBidXQgdGhh dOKAmXMgbm90IHVuaXZlcnNhbC4gU2luY2UgT0F1dGggMi4wIGlzIHNvIGVzdGFibGlzaGVkIGFs cmVhZHksIHRoZXJlIGFyZSBhIExPVCBvZiBwZW9wbGUgd2hvIGFyZW7igJl0IGdvaW5nIHRvIGJl IGludGVyZXN0ZWQgaW4gc29tZXRoaW5nIG5ldyBhbnkgdGltZSBzb29uLiBCdXQgb24gdGhlIG90 aGVyIGhhbmQsIHRoZXJlIGFyZSBhIG51bWJlciBvZiBwZW9wbGUgZm9yIHdob20gT0F1dGggMi4w IGRvZXMgbm90IHdvcmssIG9yIGlzIGF0IHRoZSB2ZXJ5IGxlYXN0IGEgcG9vciBmaXQsIGFuZCB3 ZeKAmWxsIHdhbnQgdG8gYnJpbmcgdGhlbSBpbiBhdCB0aGlzIGVhcmx5IHN0YWdlLiBTbyBldmVu IHdpdGggc2lnbmlmaWNhbnQgb3ZlcmxhcCwgSSB0aGluayB0aGVyZeKAmXMgZW5vdWdoIGRpc2Nv bm5lY3QgaW4gdGhlIGNvbW11bml0eSBmcm9tIGJvdGggc2lkZXMgdGhhdCB3YXJyYW50cyBhIG5l dyBncm91cC4gSW4gYWRkaXRpb24sIEkgdGhpbmsgdGhpcyBpcyBhIGJpZyBlbm91Z2ggcGllY2Ug b2Ygd29yayB0aGF0IGl04oCZcyBzaW1wbHkgdG9vIG11Y2ggZm9yIHRoZSBPQXV0aCB3b3JraW5n IGdyb3VwIHRvIGJlIGFibGUgdG8gZm9jdXMgb24uIFdlIHdvdWxkbuKAmXQgYmUgYWJsZSB0byBn ZXQgYWRkaXRpb25hbCBtZWV0aW5nIHRpbWUsIGFuZCBPQXV0aCBhbHJlYWR5IGhhcyB0cm91Ymxl IGZpdHRpbmcgaW50byBpdHMgdHdvIG1lZXRpbmcgc2xvdHMgYXMgaXQgaXMuDQoNCknigJl2ZSBw dWJsaXNoZWQgYSBibG9nIHBvc3QgZGV0YWlsaW5nIG1vcmUgb2YgbXkgcmF0aW9uYWxlOg0KDQpo dHRwczovL21lZGl1bS5jb20vQGp1c3RpbnNlY3VyaXR5L3RoZS1jYXNlLWZvci1vYXV0aC0zLTAt d2h5LWEtbmV3LXdvcmtpbmctZ3JvdXAtZDYyMjliYThlMzY/DQoNClBsZWFzZSBzdWdnZXN0IGNo YW5nZXMgdG8gdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCBhYm92ZS4gSXTigJlzIG15IGhvcGUg dGhhdCB3ZSBjYW4gZ2V0IHRoZSBjaGFydGVyaW5nIHByb2Nlc3Mgc3RhcnRlZC4NCg0KIOKAlCBK dXN0aW4NCi0tDQpUeGF1dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4 YXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhh dXRoDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlzdA0KVHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1 dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0 aA0K --_000_958491C881C8469D973D40AD9769F21Camazoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 YnI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk9uIERlYyAyMCwg MjAxOSwgYXQgNTozNSBQTSwgRGljayBIYXJkdCAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7 IHdyb3RlOjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj7vu78NCjxkaXYgZGlyPSJsdHIiPldvdWxkIGFuIGF1 dG9tYXRlZCBzeXN0ZW0gYXMgeW91IGRlc2NyaWJlIG5vdCBiZSBhY3Rpbmcgb24gYmVoYWxmIG9m IHRoZSBlbnRlcnByaXNlPyBBIHBhcnR5IGRvZXMgbm90IG5lZWQgdG8gYmUgYSBwZXJzb24uIEJ1 dCBwZXJoYXBzIEkgYW0gbm90IHVuZGVyc3RhbmRpbmcgeW91ciBwb2ludC48L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+WWVzLCBpbiB0aGUgc2Ft ZSBzZW5zZSB0aGF0IGFueSBlbXBsb3llZSBvZiB0aGUgZW50ZXJwcmlzZSBhY3RzIG9uIGl0cyBi ZWhhbGYuIFRoZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCB3ZSByZWNvZ25pemUgdGhhdCB0aGUg YXV0b21hdGVkIHN5c3RlbSBpc27igJl0IGFjdGluZyBJbiBiZWhhbGYgb2Yg4oCcQm9iLCB0aGUg YWRtaW5pc3RyYXRvciB3aG8gc2V0IGl0IHVwLuKAnSBUaGUgYXV0aG9yaXppbmcNCjxpPmFjdG9y PC9pPiAoQm9iKSBtYXkgYmUgYXV0aG9yaXppbmcgdGhlIGNsaWVudCBvbiBiZWhhbGYgb2YgdGhl IGF1dGhvcml6aW5nIDxpPg0KcGFydHk8L2k+ICh0aGUgZW50ZXJwcmlzZSkuIEZyb20gYW4gYXVk aXRpbmcgYW5kIGdvdmVybmFuY2Ugc3RhbmRwb2ludCwgdGhlIGNsaWVudOKAmXMgYWN0aW9ucyBz aG91bGQgYmUgYXR0cmlidXRlZCB0byB0aGUgY2xpZW50IChhbmQgdGhlIGVudGVycHJpc2UsIGlm IGl04oCZcyBhY3RpbmcgaW4gYSBtdWx0aSB0ZW5hbnQgZW52aXJvbm1lbnQpLCBub3QgQm9iLjwv ZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxk aXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBw eDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCI+DQo8ZGl2PndlIHNob3VsZCBub3Qgc3VnZ2VzdCB0 aGF0IDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYigyNTUsMjU1LDApIj50aGUgY2xp ZW50PC9zcGFuPiBvciBhdXRob3JpemluZyBwYXJ0eSBpcyBkaXJlY3RseSBpbnRlcmFjdGluZyB3 aXRoIHRoZSBBUy48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQpXZSBhcmUgc3RhdGluZyB0aGUgc29mdHdhcmUgY2xpZW50IElTIGludGVyYWN0aW5nIHdpdGgg dGhlIEFTLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PiZuYnNwO1RoZSBrZXkgd29yZCBpcyDigJxkaXJlY3RseS7igJ0gQXJlIHdl IGFzc3VtaW5nIHRoZSBjbGllbnQgd2lsbCBhbHdheXMgZGlyZWN0bHkgY29tbXVuaWNhdGUgd2l0 aCB0aGUgQVM/IENvdWxkIHRyYW5zYWN0aW9ucyBzdGFydCB3aXRoIGEgY2xpZW50IGNhbGxpbmcg YW4gUlMsIHdoaWNoIGNhbGxzIHRoZSBBUz8gSeKAmW0gb25seSBqdXN0IHN0YXJ0aW5nIHRvIGV4 cGxvcmUgdGhpcyAmbmJzcDtpZGVhIGJ1dCBpdCBzZWVtcyBpbnRlcmVzdGluZy4gVGhlcmXigJlz DQogc3RpbGwgYW4gQVMgaW52b2x2ZWQsIGFuZCBhIHRyYW5zYWN0aW9uIGJldHdlZW4gQVMgYW5k IGNsaWVudCwgYnV0IG5vdCBuZWNlc3NhcmlseSBkaXJlY3QgaW50ZXJhY3Rpb24uPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BcyBJIHNhaWQsIG1heWJlIEnigJltIGJlaW5nIHRvbyBs aXRlcmFsLjwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0i bHRyIj4NCjxkaXYgaHNwYWNlPSJzdHJlYWstcHQtbWFyayIgc3R5bGU9Im1heC1oZWlnaHQ6MXB4 Ij48aW1nIGFsdD0iIiBzdHlsZT0id2lkdGg6MHB4O21heC1oZWlnaHQ6MHB4O292ZXJmbG93Omhp ZGRlbiIgc3JjPSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGph eTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD04 MTEyN2E5ZC0wNjQxLTQyM2MtYmU3Ny04MTIwNzAyNDExMDMiIGRhdGEtdW5pcXVlLWlkZW50aWZp ZXI9IiI+PGZvbnQgY29sb3I9IiNmZmZmZmYiIHNpemU9IjEiPuGQpzwvZm9udD48L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRy Ij5PbiBGcmksIERlYyAyMCwgMjAxOSBhdCA1OjA4IFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJl bGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSI+cmljaGFubmFAYW1h em9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFw eCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJF Ti1VUyI+DQo8ZGl2IGNsYXNzPSJnbWFpbC1tXzI4MzY0NjI1NTA1NTQ4MzcwODhXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gbm90IHN1cmUgaWYgdGhpcyBpcyB3aGF0 IEV2ZSBoYWQgaW4gbWluZCwgYnV0IGNvbnNpZGVyIGFuIGF1dG9tYXRlZCBzeXN0ZW0gaW4gYW4g ZW50ZXJwcmlzZSBjb250ZXh0IHRoYXQgaGFzIGJlZW4gYXV0aG9yaXplZCBieSBhbiBhZG1pbmlz dHJhdG9yLiBUaGUgYXV0b21hdGVkIHN5c3RlbSBpc27igJl0IGFjdGluZyBhcyBvciBvbiBiZWhh bGYgb2YgdGhlIGFkbWluaXN0cmF0b3IsIGFuZCB0aGUgYWRtaW5pc3RyYXRvcg0KIGhhc27igJl0 IOKAnGRlbGVnYXRlZCBhY2Nlc3PigJ07IHRoZXnigJl2ZSA8aT5ncmFudGVkPC9pPiBhY2Nlc3Ms IGp1c3QgYXMgdGhleSBkbyB3aGVuIHRoZXkgYXNzaWduIHBlcm1pc3Npb25zIHRvIHVzZXJzL2dy b3Vwcy9yb2xlcy9ldGMuPHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1heWJlIEnigJltIGJlaW5n IHRvbyBsaXRlcmFsLCBidXQg4oCcdGhyb3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlcuKAnSBp biBwYXJhZ3JhcGggMSBpbXBsaWVzIGEgc3BlY2lmaWMgY29udGV4dC9pbmZvcm1hdGlvbi9yZXF1 ZXN0IGZsb3cgdG8gbWUuIEdpdmVuIHRoYXQgb25lIG9mIFR4QXV0aOKAmXMgZmVhdHVyZXMgaXMg ZGVjb3VwbGluZyB0aGUgZGlmZmVyZW50IGNvbW11bmljYXRpb24gY2hhbm5lbHMsIHdlIHNob3Vs ZA0KIG5vdCBzdWdnZXN0IHRoYXQgdGhlIGNsaWVudCBvciBhdXRob3JpemluZyBwYXJ0eSBpcyBk aXJlY3RseSBpbnRlcmFjdGluZyB3aXRoIHRoZSBBUy48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCI+4oCTJm5ic3A7PHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMnB0Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0 Ij5BV1MgSWRlbnRpdHk8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXItcmlnaHQ6bm9u ZTtib3JkZXItYm90dG9tOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItdG9wOjFwdCBzb2xp ZCByZ2IoMTgxLDE5NiwyMjMpO3BhZGRpbmc6M3B0IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdDtjb2xvcjpibGFjayI+VHhhdXRo ICZsdDs8YSBocmVmPSJtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj50eGF1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhh cmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRh eSwgRGVjZW1iZXIgMjAsIDIwMTkgYXQgNDoxNCBQTTxicj4NCjxiPlRvOiA8L2I+RXZlIE1hbGVy ICZsdDs8YSBocmVmPSJtYWlsdG86ZXZlQHhtbGdycmwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXZl QHhtbGdycmwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0 bzpyZGRAY2VydC5vcmciIHRhcmdldD0iX2JsYW5rIj5yZGRAY2VydC5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86cmRkQGNlcnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+cmRkQGNlcnQu b3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj50eGF1dGhAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 dHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoQGlldGYub3JnPC9hPiZndDss DQogSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFy Z2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7LCBCZW5qYW1pbiBLYWR1ayAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmthZHVrQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5rYWR1a0BtaXQu ZWR1PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtUeGF1dGhdIFR4QXV0aCBQcm9w b3NlZCBDaGFydGVyPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZlOiBkbyB5b3Ugbm90IHRoaW5rIHRoZSBz b2Z0d2FyZSBjbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFsZiBvZiBzb21lIHBhcnR5PyBPciBkbyB5 b3UgdGhpbmsgdGhhdCBzb2Z0d2FyZSBhbHdheXMgaXMgYWN0aW5nIG9uIGJlaGFsZiBvZiBzb21l IHBhcnR5LCBhbmQgdGhlIG1lbnRpb25lZCBwaHJhc2UgaXMgcmVkdW5kYW50Pw0KPHU+PC91Pjx1 PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1Pjwv dT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0aW46IGEgY291 cGxlIHF1ZXN0aW9uczx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4xLiBXaGF0IGlzIG1lYW50IGJ5ICZxdW90O0RlbGVnYXRpb24gYmV0 d2VlbiBtdWx0aXBsZSB1c2VycyZxdW90OyA/PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIFdoeSBkbyB5b3UgcmVzdHJpY3QgdGhp cyB0byBIVFRQPzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4zLiBXaHkgaXMgYXV0aGVudGljYXRpb24gbm90IGluIHNjb3BlPzx1Pjwv dT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91 PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40 LiBXaGVuIHlvdSBzYXkgJnF1b3Q7bm90IGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggT0F1dGgg Mi4wIGFuZCBpdHMgZXh0ZW5zaW9ucyZxdW90OywgZG8geW91IGV4cGVjdCB0byBkZWZpbmUgYSBu ZXcgc3RhbmRhcmQgdG8gcmVwbGFjZSBSRkMgNjc1MD8gRGV2ZWxvcGVycyB3aWxsIGhhdmUgdG8g aGF2ZSBhIG5ldyBtZXRob2QgdG8gY2FsbCBBUElzPzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gRnJpLCBEZWMgMjAsIDIwMTkgYXQgMzoyNyBQTSBFdmUgTWFsZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpldmVAeG1sZ3JybC5jb20iIHRhcmdldD0iX2JsYW5rIj5ldmVAeG1sZ3JybC5j b208L2E+Jmd0OyB3cm90ZTo8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlci10b3A6bm9uZTtib3JkZXItcmlnaHQ6bm9uZTtib3JkZXItYm90dG9tOm5v bmU7Ym9yZGVyLWxlZnQ6MXB0IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZzowaW4gMGlu IDBpbiA2cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTJwdCI+UmUg4oCcPHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPnRvIGEgc29mdHdhcmUgY2xpZW50 IF9hY3Rpbmcgb24gYmVoYWxmIG9mIGFuIGF1dGhvcml6aW5nIHBhcnR5X+KAnTogVGhlcmUgaXMg YSB3aG9sZSBsb3Qgb2YgcGhpbG9zb3BoeSBiZWhpbmQgd2hvbSB0aGUgZGVsZWdhdGVkIGFjY2Vz cyBpcyBwZXJmb3JtZWQgb24gYmVoYWxmIG9mLCB1bmxlc3MNCiB0aGUgc2NlbmFyaW8gaXMgc2lu Z2xlLXVzZXIgb3Igc29tZSAmcXVvdDthY3QgYXMmcXVvdDsgc2VtYW50aWMgaXMgc3BlbGxlZCBv dXQgb24gdGhlIHdpcmUuIERvZXMgaXQgbmVlZCB0byBiZSBzdGF0ZWQgaGVyZT8gV2hhdCdzIHRo ZSBjb25zZXF1ZW5jZSBpZiB0aGUgaGlnaGxpZ2h0ZWQgcGhyYXNlIHdlcmUgcmVtb3ZlZD8mbmJz cDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTNwdCI+RXZlIE1hbGVyIChzZW50IGZyb20g bXkgaVBhZCkgfCZuYnNwO2NlbGwgJiM0MzsxIDQyNSAzNDUgNjc1Njwvc3Bhbj48dT48L3U+PHU+ PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KPHU+PC91Pjx1PjwvdT48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1cHQ7bWFyZ2luLWJvdHRvbTo1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTJwdCI+T24gRGVjIDIwLCAyMDE5LCBhdCA0OjM0IFBNLCBKdXN0aW4gUmlj aGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+ anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjVwdDttYXJnaW4t Ym90dG9tOjVwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgYWxsLCA8dT48L3U+ PHU+PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGRpc2N1c3Nl ZCBpbiBTaW5nYXBvcmUsIG5vIG1hdHRlciB3aGF0IGZvcnVtIFR4QXV0aCB0YWtlcywgaXRzIHdv cmsgd2lsbCByZXF1aXJlIGEgbmV3IGNoYXJ0ZXIuIFdpdGggdGhhdCBpbiBtaW5kLCBJ4oCZdmUg dGFrZW4gYSBiaXQgb2YgdGltZSB0byBwdXQgdG9nZXRoZXIgYSBwcm9wb3NlZCBjaGFydGVyIHRl eHQgZm9yIHRoZSBUeEF1dGggd29yazo8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzBwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZl bG9wIGEgbmV4dC1nZW5lcmF0aW9uIHRyYW5zYWN0aW9uYWwgYXV0aG9yaXphdGlvbiBhbmQgZGVs ZWdhdGlvbiBwcm90b2NvbCBmb3IgSFRUUC1iYXNlZCBBUElzIGFuZCB0aGVpciBjbGllbnRzLiBU aGVzZSB0cmFuc2FjdGlvbnMgd2lsbCBhbGxvdyBhbiBhdXRob3JpemluZyBwYXJ0eSB0byBkZWxl Z2F0ZSBhIHJpZ2h0IG9mIGFjY2VzcyBmb3IgYW4gQVBJDQogb3Igc2V0IG9mIEFQSXMgdGhyb3Vn aCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBhIHNvZnR3YXJlIGNsaWVudCBhY3Rpbmcgb24g YmVoYWxmIG9mIGFuIGF1dGhvcml6aW5nIHBhcnR5LiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZ3JvdXAgd2lsbCBk ZWxpdmVyIGEgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBkZXRhaWxpbmcgaG93IGEgY2xpZW50IGNh biByZXF1ZXN0IGFuZCBvYnRhaW4gZGVsZWdhdGVkIGFjY2VzcywgaG93IGFuIGF1dGhvcml6YXRp b24gc2VydmVyIGNhbiBwcm92aWRlIGRlbGVnYXRlZCBhY2Nlc3MsIGhvdyBhbiBhdXRob3JpemVk IHBhcnR5IGNhbiBhdXRob3JpemUgZGVsZWdhdGVkIGFjY2VzcywgYW5kIGhvdyB0aGF0DQogYXV0 aG9yaXplZCBhY2Nlc3MgY2FuIGJlIGNvbW11bmljYXRlZCB0byB0aGUgcmVzb3VyY2VzIGJlaW5n IHByb3RlY3RlZC4gVGhlc2UgYWN0aW9ucyB3aWxsIGJlIGNvbm5lY3RlZCB0aHJvdWdoIGFuIGV4 cGxpY2l0IHRyYW5zYWN0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIsIHJlc3VsdGluZyBpbiBhbiBhcnRpZmFjdCB0aGF0IHdpbGwgYWxsb3cgdGhlIGNsaWVu dCB0byB1bmRlcnRha2UgdGhlIGRlbGVnYXRlZA0KIGFjdGlvbi4mbmJzcDs8dT48L3U+PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8 dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWRkaXRpb25h bGx5LCB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzIHdpbGwgYWxsb3cgZm9yOjx1PjwvdT48dT48L3U+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBGaW5lLWdyYWluZWQg c3BlY2lmaWNhdGlvbiBvZiByZXNvdXJjZSBhY2Nlc3M8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gRGVsZWdhdGlvbiBiZXR3ZWVuIG11bHRp cGxlIHVzZXJzPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tIFdlYiwgbW9iaWxlLCBzaW5nbGUtcGFnZSwgYW5kIG90aGVyIGNsaWVudCBhcHBs aWNhdGlvbnM8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIGdyb3VwIHdpbGwgZGVmaW5lIGV4dGVuc2lvbiBwb2ludHMgZm9yIHRo aXMgcHJvdG9jb2wgdG8gYWxsb3cgZm9yIGZsZXhpYmlsaXR5IGluIGFyZWFzIGluY2x1ZGluZzo8 dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1 PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSBDcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3NhZ2Ugc2lnbmF0dXJlcywg YW5kIHByb29mIG9mIHBvc3Nlc3Npb24mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVXNlciBpbnRlcmFjdGlvbiBtZWNoYW5pc21z IGluY2x1ZGluZyB3ZWIgYW5kIG5vbi13ZWIgbWV0aG9kczx1PjwvdT48dT48L3U+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBUb2tlbiBwcmVzZW50YXRpb24gbWVj aGFuaXNtcyBhbmQga2V5IGJpbmRpbmdzPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBhcnRpZmFjdHMgZm9yIHRoaXMgd29yayBh cmUgbm90IGludGVuZGVkIG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1jb21wYXRpYmxlIHdp dGggT0F1dGggMi4wIGFuZCBpdHMgZXh0ZW5zaW9ucy4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1Pjwv dT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2hpbGUgdGhpcyB3b3JrIGNvdWxkIGJlIGRvbmUgaW4gd2l0aGluIHRoZSBPQXV0aCB3b3JraW5n IGdyb3VwLCBJIG5vdyBiZWxpZXZlIHRoYXQgaXQgc2hvdWxkIGJlIGRvbmUgaW4gYSBuZXcgd29y a2luZyBncm91cCwgYW5kIHRoYXQgd2Ugc2hvdWxkIHRyeSB0byBnZXQgdGhhdCB3b3JraW5nIGdy b3VwIHVwIGFuZCBydW5uaW5nIHByaW9yIHRvIHRoZSBWYW5jb3V2ZXIgbWVldGluZyBpbiBNYXJj aC4uIEkgdGhpbmsNCiB0aGlzIGdyb3VwIHNob3VsZCBzdGF5IGhlcmUgb24gdGhlIFR4QXV0aCBs aXN0LCBhbmQgaXTigJlzIG15IHN1Z2dlc3Rpb24gdGhhdCB0aGUgcmVzdWx0aW5nIHdvcmsgYmUg Y2FsbGVkIE9BdXRoIDMuMC4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2h5IGEgbmV3IGdyb3VwPyBJIHRoaW5rIHRoYXQg dGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIHJlbWFpbiBmb2N1c2VkIG9uIGV4dGVuZGlu ZywgcGF0Y2hpbmcsIGFuZCBhZGFwdGluZyBPQXV0aCAyLjAgdG8gYSBjaGFuZ2luZyB3b3JsZC4g SSBwbGFuIHRvIGJlIGVuZ2FnZWQgaW4gYm90aCBncm91cHMsIGFuZCBJIGtub3cgbW9zdCBvZiB5 b3UgYXJlIGFzIHdlbGwsIGJ1dCB0aGF04oCZcyBub3QgdW5pdmVyc2FsLg0KIFNpbmNlIE9BdXRo IDIuMCBpcyBzbyBlc3RhYmxpc2hlZCBhbHJlYWR5LCB0aGVyZSBhcmUgYSBMT1Qgb2YgcGVvcGxl IHdobyBhcmVu4oCZdCBnb2luZyB0byBiZSBpbnRlcmVzdGVkIGluIHNvbWV0aGluZyBuZXcgYW55 IHRpbWUgc29vbi4gQnV0IG9uIHRoZSBvdGhlciBoYW5kLCB0aGVyZSBhcmUgYSBudW1iZXIgb2Yg cGVvcGxlIGZvciB3aG9tIE9BdXRoIDIuMCBkb2VzIG5vdCB3b3JrLCBvciBpcyBhdCB0aGUgdmVy eSBsZWFzdCBhIHBvb3IgZml0LA0KIGFuZCB3ZeKAmWxsIHdhbnQgdG8gYnJpbmcgdGhlbSBpbiBh dCB0aGlzIGVhcmx5IHN0YWdlLiBTbyBldmVuIHdpdGggc2lnbmlmaWNhbnQgb3ZlcmxhcCwgSSB0 aGluayB0aGVyZeKAmXMgZW5vdWdoIGRpc2Nvbm5lY3QgaW4gdGhlIGNvbW11bml0eSBmcm9tIGJv dGggc2lkZXMgdGhhdCB3YXJyYW50cyBhIG5ldyBncm91cC4gSW4gYWRkaXRpb24sIEkgdGhpbmsg dGhpcyBpcyBhIGJpZyBlbm91Z2ggcGllY2Ugb2Ygd29yayB0aGF0IGl04oCZcyBzaW1wbHkgdG9v DQogbXVjaCBmb3IgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgdG8gYmUgYWJsZSB0byBmb2N1cyBv bi4gV2Ugd291bGRu4oCZdCBiZSBhYmxlIHRvIGdldCBhZGRpdGlvbmFsIG1lZXRpbmcgdGltZSwg YW5kIE9BdXRoIGFscmVhZHkgaGFzIHRyb3VibGUgZml0dGluZyBpbnRvIGl0cyB0d28gbWVldGlu ZyBzbG90cyBhcyBpdCBpcy48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmXZlIHB1Ymxpc2hlZCBhIGJsb2cgcG9zdCBkZXRhaWxp bmcgbW9yZSBvZiBteSByYXRpb25hbGU6PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vbWVkaXVtLmNvbS9A anVzdGluc2VjdXJpdHkvdGhlLWNhc2UtZm9yLW9hdXRoLTMtMC13aHktYS1uZXctd29ya2luZy1n cm91cC1kNjIyOWJhOGUzNj8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21lZGl1bS5jb20vQGp1 c3RpbnNlY3VyaXR5L3RoZS1jYXNlLWZvci1vYXV0aC0zLTAtd2h5LWEtbmV3LXdvcmtpbmctZ3Jv dXAtZDYyMjliYThlMzY/PC9hPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ugc3VnZ2VzdCBjaGFuZ2VzIHRvIHRoZSBwcm9w b3NlZCBjaGFydGVyIHRleHQgYWJvdmUuIEl04oCZcyBteSBob3BlIHRoYXQgd2UgY2FuIGdldCB0 aGUgY2hhcnRlcmluZyBwcm9jZXNzIHN0YXJ0ZWQuPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW48dT48L3U+ PHU+PC91PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KVHhhdXRo IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5UeGF1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT48dT48L3U+PHU+PC91Pjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t LSA8YnI+DQpUeGF1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlR4YXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlR4YXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjx1 PjwvdT48dT48L3U+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_958491C881C8469D973D40AD9769F21Camazoncom_-- From nobody Sat Dec 21 04:37:48 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC9F120A4A for ; Sat, 21 Dec 2019 04:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 vjKydevUwjy4 for ; Sat, 21 Dec 2019 04:37:44 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 52B27120A3A for ; Sat, 21 Dec 2019 04:37:44 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBLCbKUc027753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Dec 2019 07:37:20 -0500 From: Justin Richer Message-Id: <3423A32E-3D54-4C5E-9EC5-C3A36258B65D@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_C0C59FCA-DDAC-4F81-9C8F-2CC0577644E1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 21 Dec 2019 07:37:19 -0500 In-Reply-To: <2B4EEA97-BB91-4368-B460-4FE161C9A155@alkaline-solutions.com> Cc: txauth@ietf.org To: David Waite References: <2B4EEA97-BB91-4368-B460-4FE161C9A155@alkaline-solutions.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 12:37:47 -0000 --Apple-Mail=_C0C59FCA-DDAC-4F81-9C8F-2CC0577644E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 First, naming things is hard.=20 But second, the two key points that you pull our below are important, = and both of those led me to the =E2=80=9Ctransactional=E2=80=9D name. = What I realized is that the process of authorization is, itself, a = transaction between multiple parties. The whole idea with a transaction = is that you have multiple actions that get bound together into one = result. By reifying that transaction, you can start to think of the = process in these terms: 1. Client starts a transaction with the AS 2. User modifies the transaction=E2=80=99s state at the AS with their = authorization 3. Client continues the transaction with the AS 4. AS creates a token representing the end result of the transaction = (access) So it=E2=80=99s stateful, multi-step, and multi-party.There=E2=80=99s = also a common thread binding each step to the next, which is at least in = line with your notion of atomicity. If any part of the process fails, = you can stop the whole thing and throw it out. When it=E2=80=99s = finished, you commit it into an artifact (the token).=20 We are not saying that it=E2=80=99s authorization for transactional = APIs, though it obviously could be used for that.=20 =E2=80=94 Justin > On Dec 20, 2019, at 9:03 PM, David Waite = wrote: >=20 >> On Dec 20, 2019, at 3:34 PM, Justin Richer > wrote: >=20 >> transactional authorization and delegation protocol for HTTP-based = APIs and their clients. >=20 >=20 > Its far past time for me to ask this without seeing like an annoying = pedant, but here goes anyway (maybe I _am_ an annoying pedant?): >=20 > What does =E2=80=9Ctransactional authorization=E2=80=9D mean in this = context? >=20 > In this sense, are we saying this is a transaction for gaining = authorization? If that is the case, are we talking about transaction in = the sense of an =E2=80=9Cexchange=E2=80=9D (such as token exchange or = the process of trading client credentials for an access token under = client credentials grant today?) Or perhaps that the process of getting = authorization is an atomic action? >=20 > If we are saying it is a protocol for setting up authorizations which = are transactional, are we specifically talking about authorizations to = preform atomic actions, such as a money transfer? >=20 > Or is there another definition that I=E2=80=99m missing? >=20 > The process of gaining proof of authorization does not seem to fit the = definition of being =E2=80=99transactional=E2=80=99 in the atomic sense. = In particular, requests for authorization may be continued with = additional information such as the result of the user hitting an = interaction endpoint, or an attempt to get new proof of authorization = (possibly with different access) off of a previous handle. >=20 > To me, the two most significant differences between TXAuth and the = existing OAuth 2.x body of work are that: >=20 > 1. The process of requesting authorization is exclusively made via = direct communication between the client and authorization server, rather = than sometimes through an indirect channel. This comes from the = realizations both that there are plenty of use-cases for delegated = authorization that won=E2=80=99t allow for a simple browser redirect, = and that the optimization of sometimes making a request indirectly - = through insecure parameters in the user channel - isn=E2=80=99t worth = the security consequences. >=20 > 2. the authorization process itself is made a reified first-class = citizen - today with a transaction handle, perhaps in the future (if I = can make a convincing argument) as a specific authorization resource at = a particular URL. The closest OAuth 2 has to this is the optional = refresh token, which doesn=E2=80=99t have the power to perform = additional client challenges or to make further requests for user = interaction. >=20 > However, it wouldn=E2=80=99t normally occur to me to use the word = =E2=80=9Ctransaction=E2=80=9D to describe either of these. >=20 > -DW --Apple-Mail=_C0C59FCA-DDAC-4F81-9C8F-2CC0577644E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 First, naming things is hard. 

But second, the two key points that you = pull our below are important, and both of those led me to the = =E2=80=9Ctransactional=E2=80=9D name. What I realized is that the = process of authorization is, itself, a transaction between multiple = parties.  The whole idea with a transaction is that you have = multiple actions that get bound together into one result. By = reifying that transaction, you can start to think of the process in = these terms:

1. Client starts a transaction with = the AS
2. User modifies the transaction=E2=80=99s = state at the AS with their authorization
3. Client = continues the transaction with the AS
4. AS creates = a token representing the end result of the transaction = (access)


So it=E2=80=99s stateful, multi-step, = and multi-party.There=E2=80=99s also a common thread binding each step = to the next, which is at least in line with your notion of atomicity. If = any part of the process fails, you can stop the whole thing and throw it = out. When it=E2=80=99s finished, you commit it into an artifact (the = token). 

We= are not saying that it=E2=80=99s authorization for transactional APIs, = though it obviously could be used for that. 
 =E2=80=94 Justin


On Dec 20, 2019, at 9:03 PM, David Waite = <david@alkaline-solutions.com> wrote:

On Dec 20, 2019, at 3:34 = PM, Justin Richer <jricher@mit.edu> wrote:

transactional = authorization and delegation protocol for HTTP-based APIs and their = clients.

Its far past time for me to ask this without seeing = like an annoying pedant, but here goes anyway (maybe I _am_ an annoying = pedant?):

What does = =E2=80=9Ctransactional authorization=E2=80=9D mean in this = context?

In = this sense, are we saying this is a transaction for gaining = authorization? If that is the case, are we talking about transaction in = the sense of an =E2=80=9Cexchange=E2=80=9D (such as token exchange or = the process of trading client credentials for an access token under = client credentials grant today?) Or perhaps that the process of getting = authorization is an atomic action?

If we are saying it is a protocol for = setting up authorizations which are transactional, are we specifically = talking about authorizations to preform atomic actions, such as a money = transfer?

Or = is there another definition that I=E2=80=99m missing?

The process of gaining = proof of authorization does not seem to fit the definition of being = =E2=80=99transactional=E2=80=99 in the atomic sense. In particular, = requests for authorization may be continued with additional information = such as the result of the user hitting an interaction endpoint, or an = attempt to get new proof of authorization (possibly with different = access) off of a previous handle.

To me, the two most significant = differences between TXAuth and the existing OAuth 2.x body of work are = that:

1. The = process of requesting authorization is exclusively made via direct = communication between the client and authorization server, rather than = sometimes through an indirect channel. This comes from the realizations = both that there are plenty of use-cases for delegated authorization that = won=E2=80=99t allow for a simple browser redirect, and that the = optimization of sometimes making a request indirectly - through insecure = parameters in the user channel - isn=E2=80=99t worth the security = consequences.

2.= the authorization process itself is made a reified first-class citizen = - today with a transaction handle, perhaps in the future (if I can make = a convincing argument) as a specific authorization resource at a = particular URL. The closest OAuth 2 has to this is the optional refresh = token, which doesn=E2=80=99t have the power to perform additional client = challenges or to make further requests for user interaction.

However, it wouldn=E2=80=99= t normally occur to me to use the word =E2=80=9Ctransaction=E2=80=9D to = describe either of these.

-DW

= --Apple-Mail=_C0C59FCA-DDAC-4F81-9C8F-2CC0577644E1-- From nobody Sat Dec 21 04:41:12 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B62120A3A for ; Sat, 21 Dec 2019 04:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 TyC0Dh7lI_ZO for ; Sat, 21 Dec 2019 04:41:09 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 D0A99120A4A for ; Sat, 21 Dec 2019 04:41:08 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBLCesM6028708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Dec 2019 07:40:55 -0500 From: Justin Richer Message-Id: <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_18E8D22D-79C1-4B77-A668-8F0886D5D31C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 21 Dec 2019 07:40:54 -0500 In-Reply-To: <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> Cc: Dick Hardt , Eve Maler , "rdd@cert.org" , "txauth@ietf.org" , Benjamin Kaduk To: "Richard Backman, Annabelle" References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 12:41:12 -0000 --Apple-Mail=_18E8D22D-79C1-4B77-A668-8F0886D5D31C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 21, 2019, at 2:09 AM, Richard Backman, Annabelle = wrote: >=20 >=20 >> On Dec 20, 2019, at 5:35 PM, Dick Hardt wrote: >>=20 >> =EF=BB=BF >> Would an automated system as you describe not be acting on behalf of = the enterprise? A party does not need to be a person. But perhaps I am = not understanding your point. >=20 > Yes, in the same sense that any employee of the enterprise acts on its = behalf. The important thing is that we recognize that the automated = system isn=E2=80=99t acting In behalf of =E2=80=9CBob, the administrator = who set it up.=E2=80=9D The authorizing actor (Bob) may be authorizing = the client on behalf of the authorizing party (the enterprise). =46rom = an auditing and governance standpoint, the client=E2=80=99s actions = should be attributed to the client (and the enterprise, if it=E2=80=99s = acting in a multi tenant environment), not Bob. All these parties would need to be represented in the transaction, yes. >=20 >> we should not suggest that the client or authorizing party is = directly interacting with the AS. >>=20 >> We are stating the software client IS interacting with the AS. >=20 > The key word is =E2=80=9Cdirectly.=E2=80=9D Are we assuming the = client will always directly communicate with the AS? Could transactions = start with a client calling an RS, which calls the AS? I=E2=80=99m only = just starting to explore this idea but it seems interesting. There=E2=80=99= s still an AS involved, and a transaction between AS and client, but not = necessarily direct interaction. Even if the client starts at the RS, the client still has to go talk to = the AS. I haven=E2=80=99t built this out, but I see it working somewhat = like UMA. In XYZ=E2=80=99s terms: 1. Client calls the RS trying to Do A Thing 2. RS calls the AS requesting a Resource Handle (because that=E2=80=99s = what the RS represents, resources) =E2=80=94 at least good enough to = cover what the client tried to do, could be more 3. RS gives the Resource Handle and AS Transaction Endpoint back to the = client 4. Client calls the AS Transaction Endpoint to start a transaction, = includes the Resource Handle as part of its request (note: doesn=E2=80=99t= have to be the whole resource section, client can add stuff) 5. Process continues as normal =E2=80=94 Justin >=20 > As I said, maybe I=E2=80=99m being too literal. >=20 >> =E1=90=A7 >> On Fri, Dec 20, 2019 at 5:08 PM Richard Backman, Annabelle = > wrote: >> I=E2=80=99m not sure if this is what Eve had in mind, but consider an = automated system in an enterprise context that has been authorized by an = administrator. The automated system isn=E2=80=99t acting as or on behalf = of the administrator, and the administrator hasn=E2=80=99t =E2=80=9Cdelega= ted access=E2=80=9D; they=E2=80=99ve granted access, just as they do = when they assign permissions to users/groups/roles/etc. >>=20 >> Maybe I=E2=80=99m being too literal, but =E2=80=9Cthrough an = authorization server=E2=80=9D in paragraph 1 implies a specific = context/information/request flow to me. Given that one of TxAuth=E2=80=99s= features is decoupling the different communication channels, we should = not suggest that the client or authorizing party is directly interacting = with the AS. >>=20 >> =20 >>=20 >> =E2=80=93=20 >>=20 >> Annabelle Richard Backman >>=20 >> AWS Identity >>=20 >> =20 >>=20 >> =20 >>=20 >> From: Txauth > on behalf of Dick Hardt = > >> Date: Friday, December 20, 2019 at 4:14 PM >> To: Eve Maler > >> Cc: "rdd@cert.org " >, "txauth@ietf.org " = >, Justin Richer = >, Benjamin Kaduk = > >> Subject: Re: [Txauth] TxAuth Proposed Charter >>=20 >> =20 >>=20 >> Eve: do you not think the software client is acting on behalf of some = party? Or do you think that software always is acting on behalf of some = party, and the mentioned phrase is redundant? >>=20 >> =20 >>=20 >> Justin: a couple questions >>=20 >> =20 >>=20 >> 1. What is meant by "Delegation between multiple users" ? >>=20 >> =20 >>=20 >> 2. Why do you restrict this to HTTP? >>=20 >> =20 >>=20 >> 3. Why is authentication not in scope? >>=20 >> =20 >>=20 >> 4. When you say "not backwards compatible with OAuth 2.0 and its = extensions", do you expect to define a new standard to replace RFC 6750? = Developers will have to have a new method to call APIs? >>=20 >> =20 >>=20 >> =20 >>=20 >> On Fri, Dec 20, 2019 at 3:27 PM Eve Maler > wrote: >>=20 >> Re =E2=80=9Cto a software client _acting on behalf of an authorizing = party_=E2=80=9D: There is a whole lot of philosophy behind whom the = delegated access is performed on behalf of, unless the scenario is = single-user or some "act as" semantic is spelled out on the wire. Does = it need to be stated here? What's the consequence if the highlighted = phrase were removed?=20 >>=20 >> Eve Maler (sent from my iPad) | cell +1 425 345 6756 >>=20 >>=20 >>=20 >>=20 >> On Dec 20, 2019, at 4:34 PM, Justin Richer > wrote: >>=20 >> Hi all, >>=20 >> =20 >>=20 >> As discussed in Singapore, no matter what forum TxAuth takes, its = work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of time to put together a proposed charter text for the TxAuth work: >>=20 >> =20 >>=20 >> This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 >>=20 >> =20 >>=20 >> The group will deliver a protocol specification detailing how a = client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>=20 >> =20 >>=20 >> Additionally, the delegation process will allow for: >>=20 >> - Fine-grained specification of resource access >>=20 >> - Delegation between multiple users >>=20 >> - Web, mobile, single-page, and other client applications >>=20 >> =20 >>=20 >> The group will define extension points for this protocol to allow for = flexibility in areas including: >>=20 >> =20 >>=20 >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >>=20 >> - User interaction mechanisms including web and non-web methods >>=20 >> - Token presentation mechanisms and key bindings >>=20 >> =20 >>=20 >> The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >>=20 >> =20 >>=20 >> While this work could be done in within the OAuth working group, I = now believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March.. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>=20 >> =20 >>=20 >> Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing = world. I plan to be engaged in both groups, and I know most of you are = as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>=20 >> =20 >>=20 >> I=E2=80=99ve published a blog post detailing more of my rationale: >>=20 >> =20 >>=20 >> = https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? = >> =20 >>=20 >> Please suggest changes to the proposed charter text above. It=E2=80=99s= my hope that we can get the chartering process started. >>=20 >> =20 >>=20 >> =E2=80=94 Justin >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_18E8D22D-79C1-4B77-A668-8F0886D5D31C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 21, 2019, at 2:09 AM, Richard Backman, Annabelle <richanna@amazon.com>= wrote:


On Dec 20, 2019, at 5:35 PM, Dick = Hardt <dick.hardt@gmail.com> wrote:

=EF=BB=BF
Would an automated system as you describe = not be acting on behalf of the enterprise? A party does not need to be a = person. But perhaps I am not understanding your point.

Yes, in the same sense that any employee of the = enterprise acts on its behalf. The important thing is that we recognize = that the automated system isn=E2=80=99t acting In behalf of =E2=80=9CBob, = the administrator who set it up.=E2=80=9D The authorizing actor (Bob) may be authorizing the client on behalf of = the authorizing party (the enterprise). =46rom an auditing and governance = standpoint, the client=E2=80=99s actions should be attributed to the = client (and the enterprise, if it=E2=80=99s acting in a multi tenant = environment), not Bob.

All these parties would need to be represented in = the transaction, yes.


we should not suggest that the client = or authorizing party is directly interacting with the AS.

We are stating the software client IS interacting with the AS.

 The key word is =E2=80=9Cdirectly.=E2=80=9D Are we = assuming the client will always directly communicate with the AS? Could = transactions start with a client calling an RS, which calls the AS? = I=E2=80=99m only just starting to explore this  idea but it seems = interesting. There=E2=80=99s still an AS involved, and a transaction between AS and client, but not = necessarily direct interaction.

Even if the client starts at the RS, the client = still has to go talk to the AS. I haven=E2=80=99t built this out, but I = see it working somewhat like UMA. In XYZ=E2=80=99s terms:


1. Client calls the RS = trying to Do A Thing
2. RS calls the AS requesting a Resource = Handle (because that=E2=80=99s what the RS represents, resources) =E2=80=94= at least good enough to cover what the client tried to do, could be = more
3. RS gives the Resource Handle and AS Transaction = Endpoint back to the client
4. Client calls the AS Transaction = Endpoint to start a transaction, includes the Resource Handle as part of = its request (note: doesn=E2=80=99t have to be the whole resource = section, client can add stuff)
5. Process continues as = normal


 =E2=80=94 Justin


As I said, maybe I=E2=80=99m being too literal.

3D""=E1=90=A7
On Fri, Dec 20, 2019 at 5:08 PM = Richard Backman, Annabelle <richanna@amazon.com> wrote:

I=E2=80=99m not sure if this is what Eve had in = mind, but consider an automated system in an enterprise context that has = been authorized by an administrator. The automated system isn=E2=80=99t = acting as or on behalf of the administrator, and the administrator hasn=E2=80=99t =E2=80=9Cdelegated access=E2=80=9D; they=E2=80=99ve granted access, just as they do when they assign = permissions to users/groups/roles/etc.

Maybe I=E2=80=99m being too = literal, but =E2=80=9Cthrough an authorization server=E2=80=9D in = paragraph 1 implies a specific context/information/request flow to me. = Given that one of TxAuth=E2=80=99s features is decoupling the different = communication channels, we should not suggest that the client or authorizing party is directly = interacting with the AS.

 

=E2=80=93 

Annabelle Richard Backman

AWS Identity

 

 

From: Txauth <txauth-bounces@ietf.org> on behalf = of Dick Hardt <dick.hardt@gmail.com>
Date: Friday, December 20, 2019 at 4:14 PM
To: Eve Maler <eve@xmlgrrl.com>
Cc: "rdd@cert.org" <rdd@cert.org>, "txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: [Txauth] TxAuth Proposed Charter

 

Eve: do you not think the = software client is acting on behalf of some party? Or do you think that = software always is acting on behalf of some party, and the mentioned = phrase is redundant?

 

Justin: a couple questions

 

1. What is meant by "Delegation = between multiple users" ?

 

2. Why do you restrict this to = HTTP?

 

3. Why is authentication not in = scope?

 

4. When you say "not backwards = compatible with OAuth 2.0 and its extensions", do you expect to define a = new standard to replace RFC 6750? Developers will have to have a new = method to call APIs?

 

 

On Fri, Dec 20, 2019 at 3:27 PM = Eve Maler <eve@xmlgrrl.com> wrote:

Re = =E2=80=9Cto a = software client _acting on behalf of an authorizing party_=E2=80=9D: = There is a whole lot of philosophy behind whom the delegated access is = performed on behalf of, unless the scenario is single-user or some "act as" semantic is spelled out on = the wire. Does it need to be stated here? What's the consequence if the = highlighted phrase were removed? 

Eve Maler (sent from my iPad) | cell +1 425 345 = 6756



On Dec 20, 2019, at = 4:34 PM, Justin Richer <jricher@mit.edu> wrote:

Hi all,

 

As discussed in Singapore, no = matter what forum TxAuth takes, its work will require a new charter. = With that in mind, I=E2=80=99ve taken a bit of time to put together a = proposed charter text for the TxAuth work:

 

This group is chartered to = develop a next-generation transactional authorization and delegation = protocol for HTTP-based APIs and their clients. These transactions will = allow an authorizing party to delegate a right of access for an API or set of APIs through an authorization server to a software client = acting on behalf of an authorizing party. 

 

The group will deliver a protocol = specification detailing how a client can request and obtain delegated = access, how an authorization server can provide delegated access, how an = authorized party can authorize delegated access, and how that authorized access can be communicated to the resources being protected. = These actions will be connected through an explicit transaction between = the client and authorization server, resulting in an artifact that will = allow the client to undertake the delegated action. 

 

Additionally, the delegation = process will allow for:

- Fine-grained specification of = resource access

- Delegation between multiple = users

- Web, mobile, single-page, and = other client applications

 

The group will define extension = points for this protocol to allow for flexibility in areas including:

 

- Cryptographic agility for keys, = message signatures, and proof of possession 

- User interaction mechanisms = including web and non-web methods

- Token presentation mechanisms = and key bindings

 

The artifacts for this work are = not intended or expected to be backwards-compatible with OAuth 2.0 and = its extensions. 

 

While this work could be done in = within the OAuth working group, I now believe that it should be done in = a new working group, and that we should try to get that working group up = and running prior to the Vancouver meeting in March.. I think this group should stay here on the TxAuth list, and it=E2=80=99s my = suggestion that the resulting work be called OAuth 3.0. 

 

Why a new group? I think that the = OAuth working group should remain focused on extending, patching, and = adapting OAuth 2.0 to a changing world. I plan to be engaged in both = groups, and I know most of you are as well, but that=E2=80=99s not = universal. Since OAuth 2.0 is so established already, there are a LOT of people = who aren=E2=80=99t going to be interested in something new any time = soon. But on the other hand, there are a number of people for whom OAuth = 2.0 does not work, or is at the very least a poor fit, and we=E2=80=99ll want to bring them in at this early stage. So even = with significant overlap, I think there=E2=80=99s enough disconnect in = the community from both sides that warrants a new group. In addition, I = think this is a big enough piece of work that it=E2=80=99s simply too much for the OAuth working group to be able to focus on. We wouldn=E2=80=99= t be able to get additional meeting time, and OAuth already has trouble = fitting into its two meeting slots as it is.

 

I=E2=80=99ve published a blog = post detailing more of my rationale:

 

https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a= -new-working-group-d6229ba8e36?

 

Please suggest changes to the = proposed charter text above. It=E2=80=99s my hope that we can get the = chartering process started.

 

 =E2=80=94 Justin

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


= --Apple-Mail=_18E8D22D-79C1-4B77-A668-8F0886D5D31C-- From nobody Sat Dec 21 04:47:40 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BB2120A4C for ; Sat, 21 Dec 2019 04:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 Zn3graHhmgln for ; Sat, 21 Dec 2019 04:47:36 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 20ABE120A4A for ; Sat, 21 Dec 2019 04:47:36 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBLClW8Q030054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 21 Dec 2019 07:47:32 -0500 From: Justin Richer Message-Id: <07AEE8DB-A0EE-4780-9CE7-B578F69948F9@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_AE876CFE-E7EF-41D2-9A24-32617413D037" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 21 Dec 2019 07:47:32 -0500 In-Reply-To: Cc: Eve Maler , "rdd@cert.org" , txauth@ietf.org, Benjamin Kaduk To: Dick Hardt References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 12:47:39 -0000 --Apple-Mail=_AE876CFE-E7EF-41D2-9A24-32617413D037 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 20, 2019, at 7:13 PM, Dick Hardt wrote: >=20 > Eve: do you not think the software client is acting on behalf of some = party? Or do you think that software always is acting on behalf of some = party, and the mentioned phrase is redundant? >=20 I think what Eve=E2=80=99s saying is that the authorizing party might = not be interacting with the client. That=E2=80=99s where things get = fuzzy =E2=80=94 if the authorizing party authorizes the client but = someone else is using it, the authorizing party is really authorizing = the requesting party that=E2=80=99s using the client, too. This is where = UMA=E2=80=99s terminology can be a better fit here. Separating the RO = and RqP roles could help, but how to express that in succinct charter = text. > Justin: a couple questions >=20 > 1. What is meant by "Delegation between multiple users=E2=80=9D ? See above. >=20 > 2. Why do you restrict this to HTTP? Because I want us to use all of the features and benefits of HTTP = instead of having to invent within-protocol functions to replicate them. = I don=E2=80=99t want SOAP, which pretends to be transport agnostic much = to its detriment. If someone wants to do OAuth 3 on not-HTTP, they can = define what that looks like. This is what happened with the COAP/CORE = stuff and OAuth 2. >=20 > 3. Why is authentication not in scope? It felt, to me, like that might be a bridge too far. If we do decide = it=E2=80=99s in scope, then I think it should be clearly layered on top = of the authorization layer.=20 >=20 > 4. When you say "not backwards compatible with OAuth 2.0 and its = extensions", do you expect to define a new standard to replace RFC 6750? = Developers will have to have a new method to call APIs? Kinda. First, it=E2=80=99s more 6749 that I want to step away from. But = even then, I think keeping just the header version of 6750 is OK enough = if someone wants to keep using that. The thing is, won=E2=80=99t someone = seeing an OAuth 2 header assume the rest of OAuth 2 infrastructure? In = some cases this won=E2=80=99t matter, but in many that could be really = confusing.=20 One of the problems, though, is that 6750 has already been clouded by = things like the MTLS binding, where they use =E2=80=9Cbearer=E2=80=9D = tokens that have to be bound to the client=E2=80=99s certificate. So =E2=80= =A6 not much of a bearer token anymore. Ultimately, I don=E2=80=99t want anything that has an error-fallthrough = compatibility process. That is to say, I try doing OAuth 2, have that = fail, and then try it as OAuth 3 =E2=80=94 or vice versa. =E2=80=94 Justin >=20 >=20 > On Fri, Dec 20, 2019 at 3:27 PM Eve Maler > wrote: > Re =E2=80=9Cto a software client _acting on behalf of an authorizing = party_=E2=80=9D: There is a whole lot of philosophy behind whom the = delegated access is performed on behalf of, unless the scenario is = single-user or some "act as" semantic is spelled out on the wire. Does = it need to be stated here? What's the consequence if the highlighted = phrase were removed?=20 >=20 > Eve Maler (sent from my iPad) | cell +1 425 345 6756 >=20 >> On Dec 20, 2019, at 4:34 PM, Justin Richer > wrote: >>=20 >> =EF=BB=BFHi all, >>=20 >> As discussed in Singapore, no matter what forum TxAuth takes, its = work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of time to put together a proposed charter text for the TxAuth work: >>=20 >> This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 >>=20 >> The group will deliver a protocol specification detailing how a = client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>=20 >> Additionally, the delegation process will allow for: >> - Fine-grained specification of resource access >> - Delegation between multiple users >> - Web, mobile, single-page, and other client applications >>=20 >> The group will define extension points for this protocol to allow for = flexibility in areas including: >>=20 >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >> - User interaction mechanisms including web and non-web methods >> - Token presentation mechanisms and key bindings >>=20 >> The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >>=20 >> While this work could be done in within the OAuth working group, I = now believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March.. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>=20 >> Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing = world. I plan to be engaged in both groups, and I know most of you are = as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>=20 >> I=E2=80=99ve published a blog post detailing more of my rationale: >>=20 >> = https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? = >>=20 >> Please suggest changes to the proposed charter text above. It=E2=80=99s= my hope that we can get the chartering process started. >>=20 >> =E2=80=94 Justin >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_AE876CFE-E7EF-41D2-9A24-32617413D037 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 20, 2019, at 7:13 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Eve: = do you not think the software client is acting on behalf of some party? = Or do you think that software always is acting on behalf of some party, = and the mentioned phrase is redundant?


I think what Eve=E2=80=99s saying is that the = authorizing party might not be interacting with the client. That=E2=80=99s= where things get fuzzy =E2=80=94 if the authorizing party authorizes = the client but someone else is using it, the authorizing party is really = authorizing the requesting party that=E2=80=99s using the client, too. = This is where UMA=E2=80=99s terminology can be a better fit here. = Separating the RO and RqP roles could help, but how to express that in = succinct charter text.

Justin: a couple questions

1. What is meant by = "Delegation between multiple users=E2=80=9D = ?

See = above.


2. Why do you restrict = this to HTTP?

Because I want us to use all of the features and = benefits of HTTP instead of having to invent within-protocol functions = to replicate them. I don=E2=80=99t want SOAP, which pretends to be = transport agnostic much to its detriment. If someone wants to do OAuth 3 = on not-HTTP, they can define what that looks like. This is what happened = with the COAP/CORE stuff and OAuth 2.


3. Why is authentication not in = scope?

It felt, to me, like that might be a bridge too = far. If we do decide it=E2=80=99s in scope, then I think it should be = clearly layered on top of the authorization layer. 


4. When you say "not backwards = compatible with OAuth 2.0 and its extensions", do you expect to define a = new standard to replace RFC 6750? Developers will have to have a new = method to call APIs?

Kinda. First, it=E2=80=99s more 6749 that I want = to step away from. But even then, I think keeping just the header = version of 6750 is OK enough if someone wants to keep using that. The = thing is, won=E2=80=99t someone seeing an OAuth 2 header assume the rest = of OAuth 2 infrastructure? In some cases this won=E2=80=99t matter, but = in many that could be really confusing. 

One of the problems, though, is that 6750 has = already been clouded by things like the MTLS binding, where they use = =E2=80=9Cbearer=E2=80=9D tokens that have to be bound to the client=E2=80=99= s certificate. So =E2=80=A6 not much of a bearer token = anymore.

Ultimately, I don=E2=80=99t = want anything that has an error-fallthrough compatibility process. That = is to say, I try doing OAuth 2, have that fail, and then try it as OAuth = 3 =E2=80=94 or vice versa.

 =E2=80= =94 Justin



On Fri, Dec 20, 2019 at 3:27 PM Eve Maler <eve@xmlgrrl.com> = wrote:
Re = =E2=80=9Cto a software client _acting on behalf of an authorizing = party_=E2=80=9D: There is a whole lot of philosophy behind whom the = delegated access is performed on behalf of, unless the scenario is = single-user or some "act as" semantic is spelled out on the wire. Does = it need to be stated here? What's the consequence if the highlighted = phrase were removed? 

Eve Maler (sent from my iPad) | cell +1 425 345 = 6756

On Dec 20, 2019, at 4:34 = PM, Justin Richer <jricher@mit.edu> wrote:

=EF=BB=BFHi all,

As discussed in Singapore, no matter = what forum TxAuth takes, its work will require a new charter. With that = in mind, I=E2=80=99ve taken a bit of time to put together a proposed = charter text for the TxAuth work:

This group is = chartered to develop a next-generation transactional authorization and = delegation protocol for HTTP-based APIs and their clients. These = transactions will allow an authorizing party to delegate a right of = access for an API or set of APIs through an authorization server to a = software client acting on behalf of an authorizing = party. 

The= group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can = provide delegated access, how an authorized party can authorize = delegated access, and how that authorized access can be communicated to = the resources being protected. These actions will be connected through = an explicit transaction between the client and authorization server, = resulting in an artifact that will allow the client to undertake the = delegated action. 

Additionally, the delegation process will allow = for:
- Fine-grained specification of resource = access
- Delegation between multiple = users
- Web, mobile, single-page, and other client = applications

The= group will define extension points for this protocol to allow for = flexibility in areas including:

- Cryptographic agility for keys, = message signatures, and proof of possession 
- = User interaction mechanisms including web and non-web methods
- Token presentation mechanisms and key bindings

The artifacts for this = work are not intended or expected to be backwards-compatible with OAuth = 2.0 and its extensions. 

While this work could be done in within = the OAuth working group, I now believe that it should be done in a new = working group, and that we should try to get that working group up and = running prior to the Vancouver meeting in March.. I think this group = should stay here on the TxAuth list, and it=E2=80=99s my suggestion that = the resulting work be called OAuth 3.0. 

Why a new group? I think that the OAuth = working group should remain focused on extending, patching, and adapting = OAuth 2.0 to a changing world. I plan to be engaged in both groups, and = I know most of you are as well, but that=E2=80=99s not universal. Since = OAuth 2.0 is so established already, there are a LOT of people who = aren=E2=80=99t going to be interested in something new any time soon. = But on the other hand, there are a number of people for whom OAuth 2.0 = does not work, or is at the very least a poor fit, and we=E2=80=99ll = want to bring them in at this early stage. So even with significant = overlap, I think there=E2=80=99s enough disconnect in the community from = both sides that warrants a new group. In addition, I think this is a big = enough piece of work that it=E2=80=99s simply too much for the OAuth = working group to be able to focus on. We wouldn=E2=80=99t be able to get = additional meeting time, and OAuth already has trouble fitting into its = two meeting slots as it is.

I=E2=80=99ve published a blog post detailing more of my = rationale:

https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a= -new-working-group-d6229ba8e36?

Please suggest changes to the proposed = charter text above. It=E2=80=99s my hope that we can get the chartering = process started.

 =E2=80=94 Justin
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_AE876CFE-E7EF-41D2-9A24-32617413D037-- From nobody Sat Dec 21 13:51:52 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B46912007A for ; Sat, 21 Dec 2019 13:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 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, MALFORMED_FREEMAIL=1.601, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 S3FLYrZi83_S for ; Sat, 21 Dec 2019 13:51:48 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 CD275120025 for ; Sat, 21 Dec 2019 13:51:47 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id j42so12751005wrj.12 for ; Sat, 21 Dec 2019 13:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=IFdxWhZ7exMXNCg+GXF+RfyrXKW5Mqwxkf3TadKOlHg=; b=Q02ItANXota4oW3OU0aX5/28VQBIn9vqBu7xFXtJoepSUaGQ7VaxiSehA3JsMROK19 t8pBwly8tkIt3pcbQGEjg2jWhGts+z0hUSu9eunheEslKA6rSvl+iVyHOy6t8PK3cZVm /wyppullTLe86kJD/0sMp5Py8tLMwMXRJ8PpKdf62W2gYsWigINNZrdyAegRJVRIDozj A9XpJ8lncU3W9bWMdKnM+fuz+i/dkY4QIrH8AU8b8A9djBedFmALUJdm13aeOb7kpCOf Lv+/yJjrsKGR6ckJSTRIysVGxbvmEfFYs6yQRWZFSHPdb9o7nJuqFIhpESwtqyXbfLRy 2lYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=IFdxWhZ7exMXNCg+GXF+RfyrXKW5Mqwxkf3TadKOlHg=; b=df6GJJkOATpIezhLs2+f4HuXTOAUpOb1ROZLNMSDQSRkj8wsFZzpY0Ff6kpaVqhZJt Wfb67Xw66ObrbyA1+b7Br9fimM4aj37ehrInZyCA36IxoZMxpICB3G6roHVhNnDaBhxZ aq42g/71FTb4petrbyw3jITFHoSH+LqrKw61nt9zHaaeO55ccvccMCWFP1Xr5GS8z38H /AzQi3XlcUCTNIdYz6+djQguJ5aI0qq6Lv/Z+9I1HK5py7/ExsL2QKbk8g7fyKwe1Uek 1TiyFBPo/RvtEp9rT8jXmU0s4PjNZ7tb2Uz594D28M4a1mt697/u05H1ZiUUCfoaKnjf BX9Q== X-Gm-Message-State: APjAAAV30b2xUx1uDFNn74FU3fISxDdy4s2UUJFsnvSkokRakAVlLFP/ L42nZ/au8VhqbkD+w49Vo0cXdGH32JU= X-Google-Smtp-Source: APXvYqxGdzyV/gyvfCOqDqbPxx3MRUvgyab/Jr+qMqRCD1WW3eApOANMl712SAzRX2YPVpjtL3Ctxw== X-Received: by 2002:adf:fcc4:: with SMTP id f4mr22212261wrs.247.1576965106224; Sat, 21 Dec 2019 13:51:46 -0800 (PST) Received: from [10.0.0.144] (bzq-79-179-17-120.red.bezeqint.net. [79.179.17.120]) by smtp.gmail.com with ESMTPSA id u22sm14908730wru.30.2019.12.21.13.51.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Dec 2019 13:51:45 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.20.0.191208 Date: Sat, 21 Dec 2019 23:51:41 +0200 From: Yaron Sheffer To: Justin Richer , CC: "rdd@cert.org" , Benjamin Kaduk Message-ID: Thread-Topic: [Txauth] TxAuth Proposed Charter References: In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3659817104_1777048734" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2019 21:51:50 -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_3659817104_1777048734 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Justin, =20 I think the charter should mention target use cases. For example, =E2=80=9Call us= e cases supported by OAuth 2 will be supported by the new protocol=E2=80=9D or =E2=80=9C= the protocol will support at least use cases X and Y=E2=80=9D. =20 And given the importance of OIDC, we could say something like: =E2=80=9CThe proto= col will allow future extension to support authentication, in an analogous w= ay to OpenID Connect. However authentication is explicitly not part of the i= nitial scope.=E2=80=9D =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Txauth on behalf of Justin Richer Date: Saturday, December 21, 2019 at 00:34 To: Cc: "rdd@cert.org" , Benjamin Kaduk Subject: [Txauth] TxAuth Proposed Charter =20 Hi all, =20 As discussed in Singapore, no matter what forum TxAuth takes, its work will= require a new charter. With that in mind, I=E2=80=99ve taken a bit of time to put= together a proposed charter text for the TxAuth work: =20 This group is chartered to develop a next-generation transactional authoriz= ation and delegation protocol for HTTP-based APIs and their clients. These t= ransactions will allow an authorizing party to delegate a right of access fo= r an API or set of APIs through an authorization server to a software client= acting on behalf of an authorizing party.=20 =20 The group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can provide= delegated access, how an authorized party can authorize delegated access, a= nd how that authorized access can be communicated to the resources being pro= tected. These actions will be connected through an explicit transaction betw= een the client and authorization server, resulting in an artifact that will = allow the client to undertake the delegated action.=20 =20 Additionally, the delegation process will allow for: - Fine-grained specification of resource access - Delegation between multiple users - Web, mobile, single-page, and other client applications =20 The group will define extension points for this protocol to allow for flexi= bility in areas including: =20 - Cryptographic agility for keys, message signatures, and proof of possessi= on=20 - User interaction mechanisms including web and non-web methods - Token presentation mechanisms and key bindings =20 The artifacts for this work are not intended or expected to be backwards-co= mpatible with OAuth 2.0 and its extensions.=20 =20 While this work could be done in within the OAuth working group, I now beli= eve that it should be done in a new working group, and that we should try to= get that working group up and running prior to the Vancouver meeting in Mar= ch. I think this group should stay here on the TxAuth list, and it=E2=80=99s my su= ggestion that the resulting work be called OAuth 3.0.=20 =20 Why a new group? I think that the OAuth working group should remain focused= on extending, patching, and adapting OAuth 2.0 to a changing world. I plan = to be engaged in both groups, and I know most of you are as well, but that=E2=80= =99s not universal. Since OAuth 2.0 is so established already, there are a LOT= of people who aren=E2=80=99t going to be interested in something new any time soo= n. But on the other hand, there are a number of people for whom OAuth 2.0 do= es not work, or is at the very least a poor fit, and we=E2=80=99ll want to bring t= hem in at this early stage. So even with significant overlap, I think there=E2= =80=99s enough disconnect in the community from both sides that warrants a new g= roup. In addition, I think this is a big enough piece of work that it=E2=80=99s si= mply too much for the OAuth working group to be able to focus on. We wouldn=E2= =80=99t be able to get additional meeting time, and OAuth already has trouble fi= tting into its two meeting slots as it is. =20 I=E2=80=99ve published a blog post detailing more of my rationale: =20 https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working= -group-d6229ba8e36? =20 Please suggest changes to the proposed charter text above. It=E2=80=99s my hope t= hat we can get the chartering process started. =20 =E2=80=94 Justin -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3659817104_1777048734 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Justin,

&= nbsp;

I think the charter should mention target = use cases. For example, =E2=80=9Call use cases supported by OAuth 2 will be suppor= ted by the new protocol=E2=80=9D or =E2=80=9Cthe protocol will support at least use case= s X and Y=E2=80=9D.

 

And given the importance of OIDC, we could say something like: =E2=80= =9CThe protocol will allow future extension to support authentication, in an a= nalogous way to OpenID Connect. However authentication is explicitly not par= t of the initial scope.=E2=80=9D

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 =

F= rom: Txauth <txauth= -bounces@ietf.org> on behalf of Justin Richer <jricher@mit.edu>
= Date: Saturday, December 21, 2019 at 00:34
To: <txauth@i= etf.org>
Cc: "rdd@cert.org" <rdd@cert.org>, Ben= jamin Kaduk <kaduk@mit.edu>
Subject: [Txauth] TxAuth Propose= d Charter

 

Hi all,

 

As discussed in Singapor= e, no matter what forum TxAuth takes, its work will require a new charter. W= ith that in mind, I=E2=80=99ve taken a bit of time to put together a proposed char= ter text for the TxAuth work:

 

This group is chartered to develop a next-gener= ation transactional authorization and delegation protocol for HTTP-based API= s and their clients. These transactions will allow an authorizing party to d= elegate a right of access for an API or set of APIs through an authorization= server to a software client acting on behalf of an authorizing party. =

 

The group will deliver a protocol specification detailin= g how a client can request and obtain delegated access, how an authorization= server can provide delegated access, how an authorized party can authorize = delegated access, and how that authorized access can be communicated to the = resources being protected. These actions will be connected through an explic= it transaction between the client and authorization server, resulting in an = artifact that will allow the client to undertake the delegated action. =

 

Additionally, the delegation process will allow for:

- Fine-grained specification of res= ource access

- Delegation betwee= n multiple users

- Web, mobile, = single-page, and other client applications

 

The group will= define extension points for this protocol to allow for flexibility in areas= including:

 

- Cryptographic agility for keys, message sig= natures, and proof of possession 

- User interaction mechanisms including web and non-web methods<= /o:p>

- Token presentation mechanisms and k= ey bindings

 

The artifacts for this work are not intended = or expected to be backwards-compatible with OAuth 2.0 and its extensions.&nb= sp;

 

While this work could be done in within = the OAuth working group, I now believe that it should be done in a new worki= ng group, and that we should try to get that working group up and running pr= ior to the Vancouver meeting in March. I think this group should stay here o= n the TxAuth list, and it=E2=80=99s my suggestion that the resulting work be calle= d OAuth 3.0. 

 

Why a new group? I think that the OAut= h working group should remain focused on extending, patching, and adapting O= Auth 2.0 to a changing world. I plan to be engaged in both groups, and I kno= w most of you are as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so= established already, there are a LOT of people who aren=E2=80=99t going to be int= erested in something new any time soon. But on the other hand, there are a n= umber of people for whom OAuth 2.0 does not work, or is at the very least a = poor fit, and we=E2=80=99ll want to bring them in at this early stage. So even wit= h significant overlap, I think there=E2=80=99s enough disconnect in the community = from both sides that warrants a new group. In addition, I think this is a bi= g enough piece of work that it=E2=80=99s simply too much for the OAuth working gro= up to be able to focus on. We wouldn=E2=80=99t be able to get additional meeting t= ime, and OAuth already has trouble fitting into its two meeting slots as it = is.

 

<= div>

I=E2=80=99ve published a blog post detailing more of my rat= ionale:

-- Txauth= mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth <= o:p>

--B_3659817104_1777048734-- From nobody Sat Dec 21 22:06:16 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15D612008C for ; Sat, 21 Dec 2019 22:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.798 X-Spam-Level: X-Spam-Status: No, score=-11.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 euUpBgqBlEtl for ; Sat, 21 Dec 2019 22:06:12 -0800 (PST) Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (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 6CB5512007A for ; Sat, 21 Dec 2019 22:06:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1576994772; x=1608530772; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2GaZ9F9ZF/kxR3HxsYAfNgsGXlPVFY97Ajk/weMjOaw=; b=Pvj4RH84iwQuiWfkZVGTy5HqUH4GD7ybOpl4racGYQ6gA42RlDP10c5u Y+g32dO8YTik2PV9//+w0iTSL7yiQJrZVeFHoUeAnyHhV12a/NyrBFHJ1 iP6qYkDJnsQAGBG+g8dONrySerhmSJUScc0/QB3L3X2XCj4vHNi+dZ59J 4=; IronPort-SDR: q+vWAPP5lw7lHok30UT3DkCfcYz29z/WBlVWBGTggl7yToA6FIYmsQZhnXqnFIwRzGxNyqPbHq GDMWveZRwSyQ== X-IronPort-AV: E=Sophos; i="5.69,342,1571702400"; d="scan'208,217"; a="16363997" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2b-c300ac87.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 22 Dec 2019 06:06:00 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan2.pdx.amazon.com [10.170.41.162]) by email-inbound-relay-2b-c300ac87.us-west-2.amazon.com (Postfix) with ESMTPS id 919CFA18F9; Sun, 22 Dec 2019 06:05:59 +0000 (UTC) Received: from EX13D11UWC003.ant.amazon.com (10.43.162.162) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 22 Dec 2019 06:05:58 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC003.ant.amazon.com (10.43.162.162) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 22 Dec 2019 06:05:58 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Sun, 22 Dec 2019 06:05:58 +0000 From: "Richard Backman, Annabelle" To: Justin Richer CC: Dick Hardt , Eve Maler , "rdd@cert.org" , "txauth@ietf.org" , "Benjamin Kaduk" Thread-Topic: [Txauth] TxAuth Proposed Charter Thread-Index: AQHVt4W+Cd5+sniY+0u9RUqE6+8fD6fDqwuAgAAMvQD//4lSAIAAjYeAgABdgjyAAFyWAIABI/3h Date: Sun, 22 Dec 2019 06:05:58 +0000 Message-ID: References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com>, <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> In-Reply-To: <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_E62A1BAB32B84A63A54E41DF48EE112Eamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2019 06:06:15 -0000 --_000_E62A1BAB32B84A63A54E41DF48EE112Eamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBEZWMgMjEsIDIwMTksIGF0IDQ6NDIgQU0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0 LmVkdT4gd3JvdGU6DQoNCkV2ZW4gaWYgdGhlIGNsaWVudCBzdGFydHMgYXQgdGhlIFJTLCB0aGUg Y2xpZW50IHN0aWxsIGhhcyB0byBnbyB0YWxrIHRvIHRoZSBBUy4gSSBoYXZlbuKAmXQgYnVpbHQg dGhpcyBvdXQsIGJ1dCBJIHNlZSBpdCB3b3JraW5nIHNvbWV3aGF0IGxpa2UgVU1BLiBJbiBYWVri gJlzIHRlcm1zOg0KDQoNCjEuIENsaWVudCBjYWxscyB0aGUgUlMgdHJ5aW5nIHRvIERvIEEgVGhp bmcNCjIuIFJTIGNhbGxzIHRoZSBBUyByZXF1ZXN0aW5nIGEgUmVzb3VyY2UgSGFuZGxlIChiZWNh dXNlIHRoYXTigJlzIHdoYXQgdGhlIFJTIHJlcHJlc2VudHMsIHJlc291cmNlcykg4oCUIGF0IGxl YXN0IGdvb2QgZW5vdWdoIHRvIGNvdmVyIHdoYXQgdGhlIGNsaWVudCB0cmllZCB0byBkbywgY291 bGQgYmUgbW9yZQ0KMy4gUlMgZ2l2ZXMgdGhlIFJlc291cmNlIEhhbmRsZSBhbmQgQVMgVHJhbnNh Y3Rpb24gRW5kcG9pbnQgYmFjayB0byB0aGUgY2xpZW50DQo0LiBDbGllbnQgY2FsbHMgdGhlIEFT IFRyYW5zYWN0aW9uIEVuZHBvaW50IHRvIHN0YXJ0IGEgdHJhbnNhY3Rpb24sIGluY2x1ZGVzIHRo ZSBSZXNvdXJjZSBIYW5kbGUgYXMgcGFydCBvZiBpdHMgcmVxdWVzdCAobm90ZTogZG9lc27igJl0 IGhhdmUgdG8gYmUgdGhlIHdob2xlIHJlc291cmNlIHNlY3Rpb24sIGNsaWVudCBjYW4gYWRkIHN0 dWZmKQ0KNS4gUHJvY2VzcyBjb250aW51ZXMgYXMgbm9ybWFsDQoNCkl0IGRlcGVuZHMgb24gd2hh dCB5b3UgY29uc2lkZXIgdGhlIOKAnEFT4oCdLiBDb25zaWRlciB0aGUgZm9sbG93aW5nIGh5cG90 aGV0aWNhbCBhcmNoaXRlY3R1cmU6DQoNCuKAoiBUaGUgUlMsIGNsaWVudCwgYW5kIHR4IGVuZHBv aW50IGFyZSBvbiB0aGUgcHVibGljIEludGVybmV0Lg0K4oCiIFRoZSB0eCBlbmRwb2ludCByZXR1 cm5zIGludGVyYWN0aW9uIHVybHMgdGhhdCBwb2ludCB0byBhbiBJZFAgdGhhdCBpcyBpbmFjY2Vz c2libGUgZnJvbSB0aGUgcHVibGljIEludGVybmV0Lg0K4oCiIFRoZSB1c2VyIGFnZW50IGNhbiBy ZWFjaCB0aGUgSWRQLCBidXQgbm9uZSBvZiB0aGUgb3RoZXIgc3lzdGVtcyBjYW4uDQrigKIgV2hl biB0aGUgVUEgaXMgcmVkaXJlY3RlZCB0byB0aGUgSWRQLCB0aGUgSWRQIGNhbGxzIHRoZSB0eCBl bmRwb2ludCBzeXN0ZW0gdG8gcmV0cmlldmUgdHJhbnNhY3Rpb24gZGV0YWlscy4NCuKAoiBXaGVu IGF1dGhvcml6YXRpb24gaXMgZ3JhbnRlZCwgdGhlIElkUCBwdXNoZXMgYXJ0aWZhY3RzIGRpcmVj dGx5IHRvIGFuIGVuZHBvaW50IHByb3ZpZGVkIGJ5IHRoZSBjbGllbnQuDQoNCkluIHRoaXMgZXhh bXBsZSwgdGhlIGNsaWVudCBvbmx5IGludGVyYWN0cyB3aXRoIHRoZSBSUyBhbmQgdGhlIHR4IGVu ZHBvaW50LiBJdCBzZWVtcyBvZGQgdG8gbWUgdG8gY29uc2lkZXIgdGhlIHN5c3RlbSBob3N0aW5n IHRoZSB0eCBlbmRwb2ludCB0byBiZSB0aGUgQVMgKG9yIGF0IGxlYXN0IHBhcnQgb2YgdGhlIEFT KSwgYXMgaXRzIGEgZ2xvcmlmaWVkIG1lc3NhZ2UgcXVldWUgd2l0aCBlc3NlbnRpYWxseSBubyBh dXRob3JpdHkgaW4gdGhpcyBhcmNoaXRlY3R1cmUuDQoNCldlIGNvdWxkIGdvIGEgc3RlcCBmdXJ0 aGVyIGFuZCByZW1vdmUgdGhlIGNsaWVudOKAmXMgaW50ZXJhY3Rpb24gd2l0aCB0aGUgdHggZW5k cG9pbnQgYnkgaGF2aW5nIHRoZSBSUyByZXR1cm4gdGhlIGludGVyYWN0aW9uIHVybCBkaXJlY3Rs eSAoeW914oCZZCBuZWVkIHRvIHNlY3VyZSB0aGUgY2xpZW50IG5vbmNlIGlmIHlvdSB3YW50IHRv IGhpZGUgaXQgZnJvbSB0aGUgUlMsIGJ1dCB0aGF04oCZcyBub3QgdGhhdCBoYXJkKS4NCg0KSXMg dGhlIG1lYW5pbmcgb2Yg4oCcYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJ0gKG9yIHRoZSBwaHJhc2Ug 4oCcdGhyb3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlcuKAnSkgZmxleGlibGUgZW5vdWdoIHRv IGFjY29tbW9kYXRlIHRoZXNlIGNhc2VzPyBPciBhcmUgdGhleSBjb25zaWRlcmVkIG91dCBvZiBz Y29wZSBmb3IgVHhBdXRoPw0KDQog4oCUIEp1c3Rpbg0KDQoNCkFzIEkgc2FpZCwgbWF5YmUgSeKA mW0gYmVpbmcgdG9vIGxpdGVyYWwuDQoNCltodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20v dD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5iV0ZwYkM1amIyMCUzRCZ0eXBlPXplcm9jb250ZW50 Jmd1aWQ9ODExMjdhOWQtMDY0MS00MjNjLWJlNzctODEyMDcwMjQxMTAzXeGQpw0KT24gRnJpLCBE ZWMgMjAsIDIwMTkgYXQgNTowOCBQTSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFu bmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KSeKAmW0g bm90IHN1cmUgaWYgdGhpcyBpcyB3aGF0IEV2ZSBoYWQgaW4gbWluZCwgYnV0IGNvbnNpZGVyIGFu IGF1dG9tYXRlZCBzeXN0ZW0gaW4gYW4gZW50ZXJwcmlzZSBjb250ZXh0IHRoYXQgaGFzIGJlZW4g YXV0aG9yaXplZCBieSBhbiBhZG1pbmlzdHJhdG9yLiBUaGUgYXV0b21hdGVkIHN5c3RlbSBpc27i gJl0IGFjdGluZyBhcyBvciBvbiBiZWhhbGYgb2YgdGhlIGFkbWluaXN0cmF0b3IsIGFuZCB0aGUg YWRtaW5pc3RyYXRvciBoYXNu4oCZdCDigJxkZWxlZ2F0ZWQgYWNjZXNz4oCdOyB0aGV54oCZdmUg Z3JhbnRlZCBhY2Nlc3MsIGp1c3QgYXMgdGhleSBkbyB3aGVuIHRoZXkgYXNzaWduIHBlcm1pc3Np b25zIHRvIHVzZXJzL2dyb3Vwcy9yb2xlcy9ldGMuDQpNYXliZSBJ4oCZbSBiZWluZyB0b28gbGl0 ZXJhbCwgYnV0IOKAnHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJ0gaW4gcGFyYWdy YXBoIDEgaW1wbGllcyBhIHNwZWNpZmljIGNvbnRleHQvaW5mb3JtYXRpb24vcmVxdWVzdCBmbG93 IHRvIG1lLiBHaXZlbiB0aGF0IG9uZSBvZiBUeEF1dGjigJlzIGZlYXR1cmVzIGlzIGRlY291cGxp bmcgdGhlIGRpZmZlcmVudCBjb21tdW5pY2F0aW9uIGNoYW5uZWxzLCB3ZSBzaG91bGQgbm90IHN1 Z2dlc3QgdGhhdCB0aGUgY2xpZW50IG9yIGF1dGhvcml6aW5nIHBhcnR5IGlzIGRpcmVjdGx5IGlu dGVyYWN0aW5nIHdpdGggdGhlIEFTLg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4N CkFXUyBJZGVudGl0eQ0KDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERpY2sgSGFyZHQg PGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQpEYXRl OiBGcmlkYXksIERlY2VtYmVyIDIwLCAyMDE5IGF0IDQ6MTQgUE0NClRvOiBFdmUgTWFsZXIgPGV2 ZUB4bWxncnJsLmNvbTxtYWlsdG86ZXZlQHhtbGdycmwuY29tPj4NCkNjOiAicmRkQGNlcnQub3Jn PG1haWx0bzpyZGRAY2VydC5vcmc+IiA8cmRkQGNlcnQub3JnPG1haWx0bzpyZGRAY2VydC5vcmc+ PiwgInR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPiIgPHR4YXV0aEBpZXRm Lm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPj4sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0 LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4sIEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQu ZWR1PG1haWx0bzprYWR1a0BtaXQuZWR1Pj4NClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBUeEF1dGgg UHJvcG9zZWQgQ2hhcnRlcg0KDQpFdmU6IGRvIHlvdSBub3QgdGhpbmsgdGhlIHNvZnR3YXJlIGNs aWVudCBpcyBhY3Rpbmcgb24gYmVoYWxmIG9mIHNvbWUgcGFydHk/IE9yIGRvIHlvdSB0aGluayB0 aGF0IHNvZnR3YXJlIGFsd2F5cyBpcyBhY3Rpbmcgb24gYmVoYWxmIG9mIHNvbWUgcGFydHksIGFu ZCB0aGUgbWVudGlvbmVkIHBocmFzZSBpcyByZWR1bmRhbnQ/DQoNCkp1c3RpbjogYSBjb3VwbGUg cXVlc3Rpb25zDQoNCjEuIFdoYXQgaXMgbWVhbnQgYnkgIkRlbGVnYXRpb24gYmV0d2VlbiBtdWx0 aXBsZSB1c2VycyIgPw0KDQoyLiBXaHkgZG8geW91IHJlc3RyaWN0IHRoaXMgdG8gSFRUUD8NCg0K My4gV2h5IGlzIGF1dGhlbnRpY2F0aW9uIG5vdCBpbiBzY29wZT8NCg0KNC4gV2hlbiB5b3Ugc2F5 ICJub3QgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBPQXV0aCAyLjAgYW5kIGl0cyBleHRlbnNp b25zIiwgZG8geW91IGV4cGVjdCB0byBkZWZpbmUgYSBuZXcgc3RhbmRhcmQgdG8gcmVwbGFjZSBS RkMgNjc1MD8gRGV2ZWxvcGVycyB3aWxsIGhhdmUgdG8gaGF2ZSBhIG5ldyBtZXRob2QgdG8gY2Fs bCBBUElzPw0KDQoNCk9uIEZyaSwgRGVjIDIwLCAyMDE5IGF0IDM6MjcgUE0gRXZlIE1hbGVyIDxl dmVAeG1sZ3JybC5jb208bWFpbHRvOmV2ZUB4bWxncnJsLmNvbT4+IHdyb3RlOg0KUmUg4oCcdG8g YSBzb2Z0d2FyZSBjbGllbnQgX2FjdGluZyBvbiBiZWhhbGYgb2YgYW4gYXV0aG9yaXppbmcgcGFy dHlf4oCdOiBUaGVyZSBpcyBhIHdob2xlIGxvdCBvZiBwaGlsb3NvcGh5IGJlaGluZCB3aG9tIHRo ZSBkZWxlZ2F0ZWQgYWNjZXNzIGlzIHBlcmZvcm1lZCBvbiBiZWhhbGYgb2YsIHVubGVzcyB0aGUg c2NlbmFyaW8gaXMgc2luZ2xlLXVzZXIgb3Igc29tZSAiYWN0IGFzIiBzZW1hbnRpYyBpcyBzcGVs bGVkIG91dCBvbiB0aGUgd2lyZS4gRG9lcyBpdCBuZWVkIHRvIGJlIHN0YXRlZCBoZXJlPyBXaGF0 J3MgdGhlIGNvbnNlcXVlbmNlIGlmIHRoZSBoaWdobGlnaHRlZCBwaHJhc2Ugd2VyZSByZW1vdmVk Pw0KRXZlIE1hbGVyIChzZW50IGZyb20gbXkgaVBhZCkgfCBjZWxsICsxIDQyNSAzNDUgNjc1Ng0K DQoNCk9uIERlYyAyMCwgMjAxOSwgYXQgNDozNCBQTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBt aXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCkhpIGFsbCwNCg0KQXMgZGlz Y3Vzc2VkIGluIFNpbmdhcG9yZSwgbm8gbWF0dGVyIHdoYXQgZm9ydW0gVHhBdXRoIHRha2VzLCBp dHMgd29yayB3aWxsIHJlcXVpcmUgYSBuZXcgY2hhcnRlci4gV2l0aCB0aGF0IGluIG1pbmQsIEni gJl2ZSB0YWtlbiBhIGJpdCBvZiB0aW1lIHRvIHB1dCB0b2dldGhlciBhIHByb3Bvc2VkIGNoYXJ0 ZXIgdGV4dCBmb3IgdGhlIFR4QXV0aCB3b3JrOg0KDQpUaGlzIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0 byBkZXZlbG9wIGEgbmV4dC1nZW5lcmF0aW9uIHRyYW5zYWN0aW9uYWwgYXV0aG9yaXphdGlvbiBh bmQgZGVsZWdhdGlvbiBwcm90b2NvbCBmb3IgSFRUUC1iYXNlZCBBUElzIGFuZCB0aGVpciBjbGll bnRzLiBUaGVzZSB0cmFuc2FjdGlvbnMgd2lsbCBhbGxvdyBhbiBhdXRob3JpemluZyBwYXJ0eSB0 byBkZWxlZ2F0ZSBhIHJpZ2h0IG9mIGFjY2VzcyBmb3IgYW4gQVBJIG9yIHNldCBvZiBBUElzIHRo cm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8gYSBzb2Z0d2FyZSBjbGllbnQgYWN0aW5n IG9uIGJlaGFsZiBvZiBhbiBhdXRob3JpemluZyBwYXJ0eS4NCg0KVGhlIGdyb3VwIHdpbGwgZGVs aXZlciBhIHByb3RvY29sIHNwZWNpZmljYXRpb24gZGV0YWlsaW5nIGhvdyBhIGNsaWVudCBjYW4g cmVxdWVzdCBhbmQgb2J0YWluIGRlbGVnYXRlZCBhY2Nlc3MsIGhvdyBhbiBhdXRob3JpemF0aW9u IHNlcnZlciBjYW4gcHJvdmlkZSBkZWxlZ2F0ZWQgYWNjZXNzLCBob3cgYW4gYXV0aG9yaXplZCBw YXJ0eSBjYW4gYXV0aG9yaXplIGRlbGVnYXRlZCBhY2Nlc3MsIGFuZCBob3cgdGhhdCBhdXRob3Jp emVkIGFjY2VzcyBjYW4gYmUgY29tbXVuaWNhdGVkIHRvIHRoZSByZXNvdXJjZXMgYmVpbmcgcHJv dGVjdGVkLiBUaGVzZSBhY3Rpb25zIHdpbGwgYmUgY29ubmVjdGVkIHRocm91Z2ggYW4gZXhwbGlj aXQgdHJhbnNhY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCBhdXRob3JpemF0aW9uIHNlcnZl ciwgcmVzdWx0aW5nIGluIGFuIGFydGlmYWN0IHRoYXQgd2lsbCBhbGxvdyB0aGUgY2xpZW50IHRv IHVuZGVydGFrZSB0aGUgZGVsZWdhdGVkIGFjdGlvbi4NCg0KQWRkaXRpb25hbGx5LCB0aGUgZGVs ZWdhdGlvbiBwcm9jZXNzIHdpbGwgYWxsb3cgZm9yOg0KLSBGaW5lLWdyYWluZWQgc3BlY2lmaWNh dGlvbiBvZiByZXNvdXJjZSBhY2Nlc3MNCi0gRGVsZWdhdGlvbiBiZXR3ZWVuIG11bHRpcGxlIHVz ZXJzDQotIFdlYiwgbW9iaWxlLCBzaW5nbGUtcGFnZSwgYW5kIG90aGVyIGNsaWVudCBhcHBsaWNh dGlvbnMNCg0KVGhlIGdyb3VwIHdpbGwgZGVmaW5lIGV4dGVuc2lvbiBwb2ludHMgZm9yIHRoaXMg cHJvdG9jb2wgdG8gYWxsb3cgZm9yIGZsZXhpYmlsaXR5IGluIGFyZWFzIGluY2x1ZGluZzoNCg0K LSBDcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3NhZ2Ugc2lnbmF0dXJlcywgYW5k IHByb29mIG9mIHBvc3Nlc3Npb24NCi0gVXNlciBpbnRlcmFjdGlvbiBtZWNoYW5pc21zIGluY2x1 ZGluZyB3ZWIgYW5kIG5vbi13ZWIgbWV0aG9kcw0KLSBUb2tlbiBwcmVzZW50YXRpb24gbWVjaGFu aXNtcyBhbmQga2V5IGJpbmRpbmdzDQoNClRoZSBhcnRpZmFjdHMgZm9yIHRoaXMgd29yayBhcmUg bm90IGludGVuZGVkIG9yIGV4cGVjdGVkIHRvIGJlIGJhY2t3YXJkcy1jb21wYXRpYmxlIHdpdGgg T0F1dGggMi4wIGFuZCBpdHMgZXh0ZW5zaW9ucy4NCg0KV2hpbGUgdGhpcyB3b3JrIGNvdWxkIGJl IGRvbmUgaW4gd2l0aGluIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLCBJIG5vdyBiZWxpZXZlIHRo YXQgaXQgc2hvdWxkIGJlIGRvbmUgaW4gYSBuZXcgd29ya2luZyBncm91cCwgYW5kIHRoYXQgd2Ug c2hvdWxkIHRyeSB0byBnZXQgdGhhdCB3b3JraW5nIGdyb3VwIHVwIGFuZCBydW5uaW5nIHByaW9y IHRvIHRoZSBWYW5jb3V2ZXIgbWVldGluZyBpbiBNYXJjaC4uIEkgdGhpbmsgdGhpcyBncm91cCBz aG91bGQgc3RheSBoZXJlIG9uIHRoZSBUeEF1dGggbGlzdCwgYW5kIGl04oCZcyBteSBzdWdnZXN0 aW9uIHRoYXQgdGhlIHJlc3VsdGluZyB3b3JrIGJlIGNhbGxlZCBPQXV0aCAzLjAuDQoNCldoeSBh IG5ldyBncm91cD8gSSB0aGluayB0aGF0IHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIHNob3VsZCBy ZW1haW4gZm9jdXNlZCBvbiBleHRlbmRpbmcsIHBhdGNoaW5nLCBhbmQgYWRhcHRpbmcgT0F1dGgg Mi4wIHRvIGEgY2hhbmdpbmcgd29ybGQuIEkgcGxhbiB0byBiZSBlbmdhZ2VkIGluIGJvdGggZ3Jv dXBzLCBhbmQgSSBrbm93IG1vc3Qgb2YgeW91IGFyZSBhcyB3ZWxsLCBidXQgdGhhdOKAmXMgbm90 IHVuaXZlcnNhbC4gU2luY2UgT0F1dGggMi4wIGlzIHNvIGVzdGFibGlzaGVkIGFscmVhZHksIHRo ZXJlIGFyZSBhIExPVCBvZiBwZW9wbGUgd2hvIGFyZW7igJl0IGdvaW5nIHRvIGJlIGludGVyZXN0 ZWQgaW4gc29tZXRoaW5nIG5ldyBhbnkgdGltZSBzb29uLiBCdXQgb24gdGhlIG90aGVyIGhhbmQs IHRoZXJlIGFyZSBhIG51bWJlciBvZiBwZW9wbGUgZm9yIHdob20gT0F1dGggMi4wIGRvZXMgbm90 IHdvcmssIG9yIGlzIGF0IHRoZSB2ZXJ5IGxlYXN0IGEgcG9vciBmaXQsIGFuZCB3ZeKAmWxsIHdh bnQgdG8gYnJpbmcgdGhlbSBpbiBhdCB0aGlzIGVhcmx5IHN0YWdlLiBTbyBldmVuIHdpdGggc2ln bmlmaWNhbnQgb3ZlcmxhcCwgSSB0aGluayB0aGVyZeKAmXMgZW5vdWdoIGRpc2Nvbm5lY3QgaW4g dGhlIGNvbW11bml0eSBmcm9tIGJvdGggc2lkZXMgdGhhdCB3YXJyYW50cyBhIG5ldyBncm91cC4g SW4gYWRkaXRpb24sIEkgdGhpbmsgdGhpcyBpcyBhIGJpZyBlbm91Z2ggcGllY2Ugb2Ygd29yayB0 aGF0IGl04oCZcyBzaW1wbHkgdG9vIG11Y2ggZm9yIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIHRv IGJlIGFibGUgdG8gZm9jdXMgb24uIFdlIHdvdWxkbuKAmXQgYmUgYWJsZSB0byBnZXQgYWRkaXRp b25hbCBtZWV0aW5nIHRpbWUsIGFuZCBPQXV0aCBhbHJlYWR5IGhhcyB0cm91YmxlIGZpdHRpbmcg aW50byBpdHMgdHdvIG1lZXRpbmcgc2xvdHMgYXMgaXQgaXMuDQoNCknigJl2ZSBwdWJsaXNoZWQg YSBibG9nIHBvc3QgZGV0YWlsaW5nIG1vcmUgb2YgbXkgcmF0aW9uYWxlOg0KDQpodHRwczovL21l ZGl1bS5jb20vQGp1c3RpbnNlY3VyaXR5L3RoZS1jYXNlLWZvci1vYXV0aC0zLTAtd2h5LWEtbmV3 LXdvcmtpbmctZ3JvdXAtZDYyMjliYThlMzY/DQoNClBsZWFzZSBzdWdnZXN0IGNoYW5nZXMgdG8g dGhlIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCBhYm92ZS4gSXTigJlzIG15IGhvcGUgdGhhdCB3ZSBj YW4gZ2V0IHRoZSBjaGFydGVyaW5nIHByb2Nlc3Mgc3RhcnRlZC4NCg0KIOKAlCBKdXN0aW4NCi0t DQpUeGF1dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQotLQ0K VHhhdXRoIG1haWxpbmcgbGlzdA0KVHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KDQo= --_000_E62A1BAB32B84A63A54E41DF48EE112Eamazoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 YnI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk9uIERlYyAyMSwg MjAxOSwgYXQgNDo0MiBBTSwgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0OyB3 cm90ZTo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj5FdmVuIGlmIHRoZSBjbGllbnQgc3RhcnRz IGF0IHRoZSBSUywgdGhlIGNsaWVudCBzdGlsbCBoYXMgdG8gZ28gdGFsayB0byB0aGUgQVMuIEkg aGF2ZW7igJl0IGJ1aWx0IHRoaXMgb3V0LCBidXQgSSBzZWUgaXQgd29ya2luZyBzb21ld2hhdCBs aWtlIFVNQS4gSW4gWFla4oCZcyB0ZXJtczo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4xLiBDbGllbnQgY2FsbHMgdGhl IFJTIHRyeWluZyB0byBEbyBBIFRoaW5nPC9kaXY+DQo8ZGl2PjIuIFJTIGNhbGxzIHRoZSBBUyBy ZXF1ZXN0aW5nIGEgUmVzb3VyY2UgSGFuZGxlIChiZWNhdXNlIHRoYXTigJlzIHdoYXQgdGhlIFJT IHJlcHJlc2VudHMsIHJlc291cmNlcykg4oCUIGF0IGxlYXN0IGdvb2QgZW5vdWdoIHRvIGNvdmVy IHdoYXQgdGhlIGNsaWVudCB0cmllZCB0byBkbywgY291bGQgYmUgbW9yZTwvZGl2Pg0KPGRpdj4z LiBSUyBnaXZlcyB0aGUgUmVzb3VyY2UgSGFuZGxlIGFuZCBBUyBUcmFuc2FjdGlvbiBFbmRwb2lu dCBiYWNrIHRvIHRoZSBjbGllbnQ8L2Rpdj4NCjxkaXY+NC4gQ2xpZW50IGNhbGxzIHRoZSBBUyBU cmFuc2FjdGlvbiBFbmRwb2ludCB0byBzdGFydCBhIHRyYW5zYWN0aW9uLCBpbmNsdWRlcyB0aGUg UmVzb3VyY2UgSGFuZGxlIGFzIHBhcnQgb2YgaXRzIHJlcXVlc3QgKG5vdGU6IGRvZXNu4oCZdCBo YXZlIHRvIGJlIHRoZSB3aG9sZSByZXNvdXJjZSBzZWN0aW9uLCBjbGllbnQgY2FuIGFkZCBzdHVm Zik8L2Rpdj4NCjxkaXY+NS4gUHJvY2VzcyBjb250aW51ZXMgYXMgbm9ybWFsPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SXQgZGVw ZW5kcyBvbiB3aGF0IHlvdSBjb25zaWRlciB0aGUg4oCcQVPigJ0uIENvbnNpZGVyIHRoZSBmb2xs b3dpbmcgaHlwb3RoZXRpY2FsIGFyY2hpdGVjdHVyZTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PuKAoiBUaGUgUlMsIGNsaWVudCwgYW5kIHR4IGVuZHBvaW50IGFyZSBvbiB0aGUgcHVi bGljIEludGVybmV0LjwvZGl2Pg0KPGRpdj7igKIgVGhlIHR4IGVuZHBvaW50IHJldHVybnMgaW50 ZXJhY3Rpb24gdXJscyB0aGF0IHBvaW50IHRvIGFuIElkUCB0aGF0IGlzIGluYWNjZXNzaWJsZSBm cm9tIHRoZSBwdWJsaWMgSW50ZXJuZXQuPC9kaXY+DQo8ZGl2PuKAoiBUaGUgdXNlciBhZ2VudCBj YW4gcmVhY2ggdGhlIElkUCwgYnV0IG5vbmUgb2YgdGhlIG90aGVyIHN5c3RlbXMgY2FuLjwvZGl2 Pg0KPGRpdj7igKIgV2hlbiB0aGUgVUEgaXMgcmVkaXJlY3RlZCB0byB0aGUgSWRQLCB0aGUgSWRQ IGNhbGxzIHRoZSB0eCBlbmRwb2ludCBzeXN0ZW0gdG8gcmV0cmlldmUgdHJhbnNhY3Rpb24gZGV0 YWlscy48L2Rpdj4NCjxkaXY+4oCiIFdoZW4gYXV0aG9yaXphdGlvbiBpcyBncmFudGVkLCB0aGUg SWRQIHB1c2hlcyBhcnRpZmFjdHMgZGlyZWN0bHkgdG8gYW4gZW5kcG9pbnQgcHJvdmlkZWQgYnkg dGhlIGNsaWVudC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkluIHRoaXMgZXhhbXBs ZSwgdGhlIGNsaWVudCBvbmx5IGludGVyYWN0cyB3aXRoIHRoZSBSUyBhbmQgdGhlIHR4IGVuZHBv aW50LiBJdCBzZWVtcyBvZGQgdG8gbWUgdG8gY29uc2lkZXIgdGhlIHN5c3RlbSBob3N0aW5nIHRo ZSB0eCBlbmRwb2ludCB0byBiZSB0aGUgQVMgKG9yIGF0IGxlYXN0IHBhcnQgb2YgdGhlIEFTKSwg YXMgaXRzIGEgZ2xvcmlmaWVkIG1lc3NhZ2UgcXVldWUgd2l0aCBlc3NlbnRpYWxseSBubyBhdXRo b3JpdHkgaW4gdGhpcw0KIGFyY2hpdGVjdHVyZS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PldlIGNvdWxkIGdvIGEgc3RlcCBmdXJ0aGVyIGFuZCByZW1vdmUgdGhlIGNsaWVu dOKAmXMgaW50ZXJhY3Rpb24gd2l0aCB0aGUgdHggZW5kcG9pbnQgYnkgaGF2aW5nIHRoZSBSUyBy ZXR1cm4gdGhlIGludGVyYWN0aW9uIHVybCBkaXJlY3RseSAoeW914oCZZCBuZWVkIHRvIHNlY3Vy ZSB0aGUgY2xpZW50IG5vbmNlIGlmIHlvdSB3YW50IHRvIGhpZGUgaXQgZnJvbSB0aGUgUlMsIGJ1 dCB0aGF04oCZcyBub3QgdGhhdCBoYXJkKS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PklzIHRoZSBtZWFuaW5nIG9mIOKAnGF1dGhvcml6YXRpb24gc2VydmVy4oCdIChvciB0aGUgcGhy YXNlIOKAnHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJ0pIGZsZXhpYmxlIGVub3Vn aCB0byBhY2NvbW1vZGF0ZSB0aGVzZSBjYXNlcz8gT3IgYXJlIHRoZXkgY29uc2lkZXJlZCBvdXQg b2Ygc2NvcGUgZm9yIFR4QXV0aD88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxkaXY+Jm5ic3A74oCUIEp1 c3RpbjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9ImF1dG8iIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMgSSBzYWlkLCBtYXli ZSBJ4oCZbSBiZWluZyB0b28gbGl0ZXJhbC48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2 IGhzcGFjZT0ic3RyZWFrLXB0LW1hcmsiIHN0eWxlPSJtYXgtaGVpZ2h0OjFweCIgY2xhc3M9IiI+ PGltZyBhbHQ9IiIgc3R5bGU9IndpZHRoOjBweDttYXgtaGVpZ2h0OjBweDtvdmVyZmxvdzpoaWRk ZW4iIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1 b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9ODEx MjdhOWQtMDY0MS00MjNjLWJlNzctODEyMDcwMjQxMTAzIiBjbGFzcz0iIiBkYXRhLXVuaXF1ZS1p ZGVudGlmaWVyPSIiPjxmb250IGNvbG9yPSIjZmZmZmZmIiBzaXplPSIxIiBjbGFzcz0iIj7hkKc8 L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRyIiBj bGFzcz0iZ21haWxfYXR0ciI+T24gRnJpLCBEZWMgMjAsIDIwMTkgYXQgNTowOCBQTSBSaWNoYXJk IEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hhbm5hQGFtYXpvbi5j b20iIGNsYXNzPSIiPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0 KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgbGFuZz0iRU4tVVMiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iZ21haWwtbV8yODM2NDYyNTUwNTU0ODM3MDg4V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPknigJltIG5vdCBzdXJlIGlmIHRoaXMgaXMgd2hhdCBFdmUgaGFkIGluIG1p bmQsIGJ1dCBjb25zaWRlciBhbiBhdXRvbWF0ZWQgc3lzdGVtIGluIGFuIGVudGVycHJpc2UgY29u dGV4dCB0aGF0IGhhcyBiZWVuIGF1dGhvcml6ZWQgYnkgYW4gYWRtaW5pc3RyYXRvci4gVGhlIGF1 dG9tYXRlZCBzeXN0ZW0gaXNu4oCZdCBhY3RpbmcgYXMgb3Igb24gYmVoYWxmIG9mIHRoZSBhZG1p bmlzdHJhdG9yLCBhbmQgdGhlIGFkbWluaXN0cmF0b3INCiBoYXNu4oCZdCDigJxkZWxlZ2F0ZWQg YWNjZXNz4oCdOyB0aGV54oCZdmUgPGkgY2xhc3M9IiI+Z3JhbnRlZDwvaT4gYWNjZXNzLCBqdXN0 IGFzIHRoZXkgZG8gd2hlbiB0aGV5IGFzc2lnbiBwZXJtaXNzaW9ucyB0byB1c2Vycy9ncm91cHMv cm9sZXMvZXRjLjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5NYXliZSBJ4oCZbSBiZWluZyB0b28gbGl0ZXJhbCwgYnV0IOKAnHRocm91 Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJ0gaW4gcGFyYWdyYXBoIDEgaW1wbGllcyBhIHNw ZWNpZmljIGNvbnRleHQvaW5mb3JtYXRpb24vcmVxdWVzdCBmbG93IHRvIG1lLiBHaXZlbiB0aGF0 IG9uZSBvZiBUeEF1dGjigJlzIGZlYXR1cmVzIGlzIGRlY291cGxpbmcgdGhlIGRpZmZlcmVudCBj b21tdW5pY2F0aW9uIGNoYW5uZWxzLCB3ZSBzaG91bGQNCiBub3Qgc3VnZ2VzdCB0aGF0IHRoZSBj bGllbnQgb3IgYXV0aG9yaXppbmcgcGFydHkgaXMgZGlyZWN0bHkgaW50ZXJhY3Rpbmcgd2l0aCB0 aGUgQVMuPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxkaXYg Y2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy cHQiIGNsYXNzPSIiPuKAkyZuYnNwOzx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJw dCIgY2xhc3M9IiI+QW5uYWJlbGxlIFJpY2hhcmQgQmFja21hbjx1IGNsYXNzPSIiPjwvdT48dSBj bGFzcz0iIj48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTJwdCIgY2xhc3M9IiI+QVdTIElkZW50aXR5PHUgY2xhc3M9IiI+PC91Pjx1 IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyLXJpZ2h0Om5vbmU7Ym9yZGVyLWJvdHRvbTpub25lO2JvcmRlci1sZWZ0Om5v bmU7Ym9yZGVyLXRvcDoxcHQgc29saWQgcmdiKDE4MSwxOTYsMjIzKTtwYWRkaW5nOjNwdCAwaW4g MGluIiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEycHQ7IiBjbGFzcz0iIj5Gcm9tOiA8L3NwYW4+DQo8L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiIGNsYXNzPSIiPlR4YXV0aCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+dHhh dXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgRGljayBIYXJkdCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNz PSIiPkRhdGU6IDwvYj5GcmlkYXksIERlY2VtYmVyIDIwLCAyMDE5IGF0IDQ6MTQgUE08YnIgY2xh c3M9IiI+DQo8YiBjbGFzcz0iIj5UbzogPC9iPkV2ZSBNYWxlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmV2ZUB4bWxncnJsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmV2ZUB4bWxncnJsLmNv bTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6IDwvYj4mcXVvdDs8YSBocmVm PSJtYWlsdG86cmRkQGNlcnQub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+cmRkQGNlcnQu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkZEBjZXJ0Lm9yZyIgdGFyZ2V0PSJf YmxhbmsiIGNsYXNzPSIiPnJkZEBjZXJ0Lm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWls dG86dHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+dHhhdXRoQGlldGYu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPnR4YXV0aEBpZXRmLm9yZzwvYT4mZ3Q7LA0KIEp1c3RpbiBSaWNo ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIiBj bGFzcz0iIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OywgQmVuamFtaW4gS2FkdWsgJmx0OzxhIGhy ZWY9Im1haWx0bzprYWR1a0BtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+a2FkdWtA bWl0LmVkdTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDogPC9iPlJl OiBbVHhhdXRoXSBUeEF1dGggUHJvcG9zZWQgQ2hhcnRlcjx1IGNsYXNzPSIiPjwvdT48dSBjbGFz cz0iIj48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkV2ZTogZG8geW91IG5vdCB0aGluayB0aGUgc29mdHdhcmUgY2xpZW50IGlzIGFjdGluZyBvbiBi ZWhhbGYgb2Ygc29tZSBwYXJ0eT8gT3IgZG8geW91IHRoaW5rIHRoYXQgc29mdHdhcmUgYWx3YXlz IGlzIGFjdGluZyBvbiBiZWhhbGYgb2Ygc29tZSBwYXJ0eSwgYW5kIHRoZSBtZW50aW9uZWQgcGhy YXNlIGlzIHJlZHVuZGFudD8NCjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0K PGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1IGNsYXNzPSIiPjwvdT4mbmJz cDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SnVzdGluOiBhIGNvdXBsZSBxdWVzdGlvbnM8dSBjbGFzcz0iIj48L3U+PHUg Y2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gV2hhdCBpcyBtZWFudCBi eSAmcXVvdDtEZWxlZ2F0aW9uIGJldHdlZW4gbXVsdGlwbGUgdXNlcnMmcXVvdDsgPzx1IGNsYXNz PSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBXaHkg ZG8geW91IHJlc3RyaWN0IHRoaXMgdG8gSFRUUD88dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1 IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gV2h5IGlzIGF1dGhlbnRpY2F0aW9uIG5v dCBpbiBzY29wZT88dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1IGNsYXNzPSIiPjwvdT4mbmJz cDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+NC4gV2hlbiB5b3Ugc2F5ICZxdW90O25vdCBiYWNrd2FyZHMgY29tcGF0aWJs ZSB3aXRoIE9BdXRoIDIuMCBhbmQgaXRzIGV4dGVuc2lvbnMmcXVvdDssIGRvIHlvdSBleHBlY3Qg dG8gZGVmaW5lIGEgbmV3IHN0YW5kYXJkIHRvIHJlcGxhY2UgUkZDIDY3NTA/IERldmVsb3BlcnMg d2lsbCBoYXZlIHRvIGhhdmUgYSBuZXcgbWV0aG9kIHRvIGNhbGwgQVBJcz88dSBjbGFzcz0iIj48 L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xh c3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZy aSwgRGVjIDIwLCAyMDE5IGF0IDM6MjcgUE0gRXZlIE1hbGVyICZsdDs8YSBocmVmPSJtYWlsdG86 ZXZlQHhtbGdycmwuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ZXZlQHhtbGdycmwuY29t PC9hPiZndDsgd3JvdGU6PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItdG9wOm5vbmU7Ym9yZGVyLXJpZ2h0Om5vbmU7 Ym9yZGVyLWJvdHRvbTpub25lO2JvcmRlci1sZWZ0OjFwdCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQp O3BhZGRpbmc6MGluIDBpbiAwaW4gNnB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEycHQiPlJlIOKAnDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9y OiB3aGl0ZTsgYmFja2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5k LXJlcGVhdDogaW5pdGlhbCBpbml0aWFsOyIgY2xhc3M9IiI+dG8gYSBzb2Z0d2FyZSBjbGllbnQg X2FjdGluZyBvbiBiZWhhbGYgb2YgYW4gYXV0aG9yaXppbmcgcGFydHlf4oCdOiBUaGVyZSBpcyBh IHdob2xlDQogbG90IG9mIHBoaWxvc29waHkgYmVoaW5kIHdob20gdGhlIGRlbGVnYXRlZCBhY2Nl c3MgaXMgcGVyZm9ybWVkIG9uIGJlaGFsZiBvZiwgdW5sZXNzIHRoZSBzY2VuYXJpbyBpcyBzaW5n bGUtdXNlciBvciBzb21lICZxdW90O2FjdCBhcyZxdW90OyBzZW1hbnRpYyBpcyBzcGVsbGVkIG91 dCBvbiB0aGUgd2lyZS4gRG9lcyBpdCBuZWVkIHRvIGJlIHN0YXRlZCBoZXJlPyBXaGF0J3MgdGhl IGNvbnNlcXVlbmNlIGlmIHRoZSBoaWdobGlnaHRlZCBwaHJhc2Ugd2VyZSByZW1vdmVkPyZuYnNw Ozwvc3Bhbj48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxM3B0IiBjbGFzcz0iIj5FdmUgTWFsZXIgKHNlbnQgZnJvbSBteSBpUGFkKSB8Jm5i c3A7Y2VsbCAmIzQzOzEgNDI1IDM0NSA2NzU2PC9zcGFuPjx1IGNsYXNzPSIiPjwvdT48dSBjbGFz cz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8dSBjbGFzcz0iIj48L3U+ PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjVwdDtt YXJnaW4tYm90dG9tOjVwdCIgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMnB0Ij5PbiBEZWMgMjAsIDIwMTksIGF0IDQ6MzQgUE0sIEp1c3RpbiBS aWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8dSBjbGFzcz0iIj48L3U+ PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NXB0O21hcmdpbi1ib3R0b206NXB0IiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsIDx1IGNsYXNzPSIiPjwvdT48 dSBjbGFzcz0iIj48L3U+PC9wPg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgZGlzY3Vzc2VkIGluIFNpbmdhcG9y ZSwgbm8gbWF0dGVyIHdoYXQgZm9ydW0gVHhBdXRoIHRha2VzLCBpdHMgd29yayB3aWxsIHJlcXVp cmUgYSBuZXcgY2hhcnRlci4gV2l0aCB0aGF0IGluIG1pbmQsIEnigJl2ZSB0YWtlbiBhIGJpdCBv ZiB0aW1lIHRvIHB1dCB0b2dldGhlciBhIHByb3Bvc2VkIGNoYXJ0ZXIgdGV4dCBmb3IgdGhlIFR4 QXV0aCB3b3JrOjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91PiZuYnNw Ozx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t bGVmdDozMHB0O21hcmdpbi1yaWdodDowaW4iIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgYSBu ZXh0LWdlbmVyYXRpb24gdHJhbnNhY3Rpb25hbCBhdXRob3JpemF0aW9uIGFuZCBkZWxlZ2F0aW9u IHByb3RvY29sIGZvciBIVFRQLWJhc2VkIEFQSXMgYW5kIHRoZWlyIGNsaWVudHMuIFRoZXNlIHRy YW5zYWN0aW9ucyB3aWxsIGFsbG93IGFuIGF1dGhvcml6aW5nIHBhcnR5IHRvIGRlbGVnYXRlIGEg cmlnaHQgb2YgYWNjZXNzIGZvciBhbiBBUEkNCiBvciBzZXQgb2YgQVBJcyB0aHJvdWdoIGFuIGF1 dGhvcml6YXRpb24gc2VydmVyIHRvIGEgc29mdHdhcmUgY2xpZW50IGFjdGluZyBvbiBiZWhhbGYg b2YgYW4gYXV0aG9yaXppbmcgcGFydHkuJm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIi PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBncm91cCB3aWxsIGRlbGl2ZXIgYSBw cm90b2NvbCBzcGVjaWZpY2F0aW9uIGRldGFpbGluZyBob3cgYSBjbGllbnQgY2FuIHJlcXVlc3Qg YW5kIG9idGFpbiBkZWxlZ2F0ZWQgYWNjZXNzLCBob3cgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIg Y2FuIHByb3ZpZGUgZGVsZWdhdGVkIGFjY2VzcywgaG93IGFuIGF1dGhvcml6ZWQgcGFydHkgY2Fu IGF1dGhvcml6ZSBkZWxlZ2F0ZWQgYWNjZXNzLCBhbmQgaG93IHRoYXQNCiBhdXRob3JpemVkIGFj Y2VzcyBjYW4gYmUgY29tbXVuaWNhdGVkIHRvIHRoZSByZXNvdXJjZXMgYmVpbmcgcHJvdGVjdGVk LiBUaGVzZSBhY3Rpb25zIHdpbGwgYmUgY29ubmVjdGVkIHRocm91Z2ggYW4gZXhwbGljaXQgdHJh bnNhY3Rpb24gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCBhdXRob3JpemF0aW9uIHNlcnZlciwgcmVz dWx0aW5nIGluIGFuIGFydGlmYWN0IHRoYXQgd2lsbCBhbGxvdyB0aGUgY2xpZW50IHRvIHVuZGVy dGFrZSB0aGUgZGVsZWdhdGVkDQogYWN0aW9uLiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48dSBjbGFz cz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZGRpdGlvbmFsbHksIHRoZSBkZWxl Z2F0aW9uIHByb2Nlc3Mgd2lsbCBhbGxvdyBmb3I6PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIi PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t IEZpbmUtZ3JhaW5lZCBzcGVjaWZpY2F0aW9uIG9mIHJlc291cmNlIGFjY2Vzczx1IGNsYXNzPSIi PjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LSBEZWxlZ2F0aW9uIGJldHdlZW4gbXVsdGlwbGUgdXNlcnM8dSBjbGFz cz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0gV2ViLCBtb2JpbGUsIHNpbmdsZS1wYWdlLCBhbmQgb3RoZXIg Y2xpZW50IGFwcGxpY2F0aW9uczx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+ PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZ3JvdXAgd2lsbCBkZWZpbmUgZXh0ZW5zaW9uIHBvaW50 cyBmb3IgdGhpcyBwcm90b2NvbCB0byBhbGxvdyBmb3IgZmxleGliaWxpdHkgaW4gYXJlYXMgaW5j bHVkaW5nOjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1 IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tIENyeXB0b2dyYXBoaWMgYWdpbGl0eSBmb3Iga2V5cywgbWVzc2FnZSBzaWduYXR1 cmVzLCBhbmQgcHJvb2Ygb2YgcG9zc2Vzc2lvbiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48dSBjbGFz cz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSBVc2VyIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5jbHVkaW5nIHdlYiBhbmQgbm9uLXdl YiBtZXRob2RzPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFRva2VuIHByZXNlbnRhdGlvbiBt ZWNoYW5pc21zIGFuZCBrZXkgYmluZGluZ3M8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91 PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1IGNs YXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFydGlmYWN0cyBmb3IgdGhpcyB3b3JrIGFy ZSBub3QgaW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmUgYmFja3dhcmRzLWNvbXBhdGlibGUgd2l0 aCBPQXV0aCAyLjAgYW5kIGl0cyBleHRlbnNpb25zLiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48dSBj bGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwv dT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGls ZSB0aGlzIHdvcmsgY291bGQgYmUgZG9uZSBpbiB3aXRoaW4gdGhlIE9BdXRoIHdvcmtpbmcgZ3Jv dXAsIEkgbm93IGJlbGlldmUgdGhhdCBpdCBzaG91bGQgYmUgZG9uZSBpbiBhIG5ldyB3b3JraW5n IGdyb3VwLCBhbmQgdGhhdCB3ZSBzaG91bGQgdHJ5IHRvIGdldCB0aGF0IHdvcmtpbmcgZ3JvdXAg dXAgYW5kIHJ1bm5pbmcgcHJpb3IgdG8gdGhlIFZhbmNvdXZlciBtZWV0aW5nIGluIE1hcmNoLi4g SSB0aGluaw0KIHRoaXMgZ3JvdXAgc2hvdWxkIHN0YXkgaGVyZSBvbiB0aGUgVHhBdXRoIGxpc3Qs IGFuZCBpdOKAmXMgbXkgc3VnZ2VzdGlvbiB0aGF0IHRoZSByZXN1bHRpbmcgd29yayBiZSBjYWxs ZWQgT0F1dGggMy4wLiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+ PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XaHkgYSBuZXcgZ3JvdXA/IEkgdGhpbmsgdGhhdCB0aGUgT0F1 dGggd29ya2luZyBncm91cCBzaG91bGQgcmVtYWluIGZvY3VzZWQgb24gZXh0ZW5kaW5nLCBwYXRj aGluZywgYW5kIGFkYXB0aW5nIE9BdXRoIDIuMCB0byBhIGNoYW5naW5nIHdvcmxkLiBJIHBsYW4g dG8gYmUgZW5nYWdlZCBpbiBib3RoIGdyb3VwcywgYW5kIEkga25vdyBtb3N0IG9mIHlvdSBhcmUg YXMgd2VsbCwgYnV0IHRoYXTigJlzIG5vdCB1bml2ZXJzYWwuDQogU2luY2UgT0F1dGggMi4wIGlz IHNvIGVzdGFibGlzaGVkIGFscmVhZHksIHRoZXJlIGFyZSBhIExPVCBvZiBwZW9wbGUgd2hvIGFy ZW7igJl0IGdvaW5nIHRvIGJlIGludGVyZXN0ZWQgaW4gc29tZXRoaW5nIG5ldyBhbnkgdGltZSBz b29uLiBCdXQgb24gdGhlIG90aGVyIGhhbmQsIHRoZXJlIGFyZSBhIG51bWJlciBvZiBwZW9wbGUg Zm9yIHdob20gT0F1dGggMi4wIGRvZXMgbm90IHdvcmssIG9yIGlzIGF0IHRoZSB2ZXJ5IGxlYXN0 IGEgcG9vciBmaXQsDQogYW5kIHdl4oCZbGwgd2FudCB0byBicmluZyB0aGVtIGluIGF0IHRoaXMg ZWFybHkgc3RhZ2UuIFNvIGV2ZW4gd2l0aCBzaWduaWZpY2FudCBvdmVybGFwLCBJIHRoaW5rIHRo ZXJl4oCZcyBlbm91Z2ggZGlzY29ubmVjdCBpbiB0aGUgY29tbXVuaXR5IGZyb20gYm90aCBzaWRl cyB0aGF0IHdhcnJhbnRzIGEgbmV3IGdyb3VwLiBJbiBhZGRpdGlvbiwgSSB0aGluayB0aGlzIGlz IGEgYmlnIGVub3VnaCBwaWVjZSBvZiB3b3JrIHRoYXQgaXTigJlzIHNpbXBseSB0b28NCiBtdWNo IGZvciB0aGUgT0F1dGggd29ya2luZyBncm91cCB0byBiZSBhYmxlIHRvIGZvY3VzIG9uLiBXZSB3 b3VsZG7igJl0IGJlIGFibGUgdG8gZ2V0IGFkZGl0aW9uYWwgbWVldGluZyB0aW1lLCBhbmQgT0F1 dGggYWxyZWFkeSBoYXMgdHJvdWJsZSBmaXR0aW5nIGludG8gaXRzIHR3byBtZWV0aW5nIHNsb3Rz IGFzIGl0IGlzLjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91PiZuYnNw Ozx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5J4oCZdmUgcHVibGlzaGVkIGEgYmxvZyBwb3N0IGRldGFpbGluZyBtb3JlIG9m IG15IHJhdGlvbmFsZTo8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1IGNsYXNzPSIiPjwvdT4m bmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9tZWRpdW0uY29tL0BqdXN0aW5zZWN1cml0 eS90aGUtY2FzZS1mb3Itb2F1dGgtMy0wLXdoeS1hLW5ldy13b3JraW5nLWdyb3VwLWQ2MjI5YmE4 ZTM2PyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vbWVkaXVtLmNvbS9AanVzdGlu c2VjdXJpdHkvdGhlLWNhc2UtZm9yLW9hdXRoLTMtMC13aHktYS1uZXctd29ya2luZy1ncm91cC1k NjIyOWJhOGUzNj88L2E+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFzcz0iIj48L3U+ Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBzdWdnZXN0IGNoYW5nZXMgdG8gdGhlIHByb3Bvc2VkIGNo YXJ0ZXIgdGV4dCBhYm92ZS4gSXTigJlzIG15IGhvcGUgdGhhdCB3ZSBjYW4gZ2V0IHRoZSBjaGFy dGVyaW5nIHByb2Nlc3Mgc3RhcnRlZC48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91Pjwv cD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1IGNsYXNz PSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A74oCUIEp1c3Rpbjx1IGNsYXNzPSIiPjwvdT48 dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8YnIg Y2xhc3M9IiI+DQpUeGF1dGggbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFp bHRvOlR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPlR4YXV0aEBpZXRm Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjx1IGNsYXNzPSIiPjwvdT48dSBj bGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0tIDxiciBjbGFzcz0iIj4NClR4YXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xh c3M9IiI+DQo8YSBocmVmPSJtYWlsdG86VHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+VHhhdXRoQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+ PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E62A1BAB32B84A63A54E41DF48EE112Eamazoncom_-- From nobody Sun Dec 22 17:35:08 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB770120026 for ; Sun, 22 Dec 2019 17:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 M4kxCUobBGBs for ; Sun, 22 Dec 2019 17:35:01 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 E9205120013 for ; Sun, 22 Dec 2019 17:35:00 -0800 (PST) Received: from [192.168.1.2] (d-24-245-125-213.nh.cpe.atlanticbb.net [24.245.125.213]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBN1Yp5K019064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 22 Dec 2019 20:34:53 -0500 From: Justin Richer Message-Id: <949341AE-C72B-4645-8F20-699F14529FFB@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_B8249B99-E5EB-4E22-B020-DE6CA2EF6140" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 22 Dec 2019 20:34:50 -0500 In-Reply-To: Cc: Dick Hardt , Eve Maler , "rdd@cert.org" , "txauth@ietf.org" , Benjamin Kaduk To: "Richard Backman, Annabelle" References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 01:35:05 -0000 --Apple-Mail=_B8249B99-E5EB-4E22-B020-DE6CA2EF6140 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think you=E2=80=99re conflating the roles that different components = play, in regard to the other components, with the potential deployment = of those components. The spec needs to be written in terms of the roles. = While the roles do need to consider what potential deployments might be, = it=E2=80=99s important that we write things in in terms of how they = interact with each other and not in terms of how they might look under = the covers. So from the clients perspective, the TX Endpoint :is: the AS. The client = doesn=E2=80=99t care that it=E2=80=99s a =E2=80=9Cglorified message = queue=E2=80=9D or if it=E2=80=99s a massive server farm. The client = doesn=E2=80=99t care if there=E2=80=99s a TLS reverse proxy or if it=E2=80= =99s talking directly to the application layer. The only thing the = client cares about is if the TX Endpoint does the things that a TX = Endpoint is supposed to do, and we define that to be the function of the = AS.=20 What=E2=80=99s important in your scenario below is that the client would = have to talk to the RS first every time. That=E2=80=99s one of the = problems that UMA has, and I think something we should avoid. I think = RS-first is an interesting pattern but AS-first ought to drive this.=20 With your hypothetical layout below, it really sounds like the TX = Endpoint is a function of the IDP, which is fine. The client doesn=E2=80=99= t care that it=E2=80=99s deployed using some externalized cloud service. = The only weird thing going on is the push from the AS back to the = client. The client would need to register that with the AS (or through = the AS more specifically) as part of its transaction request. This would = be part of its interaction mechanism, because =E2=80=9Chow you get = messages and updates back to the client=E2=80=9D is part of the = interaction model.=20 So for an RS-first transaction, the client calls the RS: GET /foo The RS returns a resource handle, but the client doesn=E2=80=99t care = where that came from. The RS could talk to the AS to get it. Probably a = new endpoint of some kind, can probably use the same kinds of key = binding that the TX Endpoint has. Or the RS can make one up that the TX = Endpoint can recognize. Or it calls the IdP to get one. The client = doesn=E2=80=99t care, and that=E2=80=99s the key point.=20 WWW-Authenticate tx_endpoint=3D=E2=80=9Chttp://server//tx = =E2=80=9D resource: =E2=80=9Casdf1234=E2=80=9D The client calls the TX endpoint like a normal transaction: POST /tx { resources: [ =E2=80=9Casdf1234=E2=80=9D ], interact: { redirect: true, push: =E2=80=9Chttp://client/push/9876 =E2=80= =9D } } The AS (which is to say the TX Endpoint) tells the client to send the = user agent to the IdP { interact_url: =E2=80=9Chttp://idp/login =E2=80=9D, handle: { value: =E2=80=9Chjkl=E2=80=9D, type: bearer } } Now the client could poll the TX Endpoint but it could also just sit and = wait for an update to be pushed in.=20 There are probably things that need to be tied together for this to be = secure, but I think the basic pattern still fits. Importantly, the = client doesn=E2=80=99t care whereby of that stuff came from =E2=80=94 as = far as it=E2=80=99s concerned, it=E2=80=99s talking to the AS.=20 Remember, the =E2=80=9CAS=E2=80=9D is a logical construct, not a = physical one. Just like the =E2=80=9Cclient=E2=80=9D could be a cluster = of applications and the =E2=80=9CRS=E2=80=9D could be a suite of APIs = tied behind a gateway. =E2=80=94 Justin > On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle = wrote: >=20 >=20 >> On Dec 21, 2019, at 4:42 AM, Justin Richer wrote: >=20 >> Even if the client starts at the RS, the client still has to go talk = to the AS. I haven=E2=80=99t built this out, but I see it working = somewhat like UMA. In XYZ=E2=80=99s terms: >>=20 >>=20 >> 1. Client calls the RS trying to Do A Thing >> 2. RS calls the AS requesting a Resource Handle (because that=E2=80=99s= what the RS represents, resources) =E2=80=94 at least good enough to = cover what the client tried to do, could be more >> 3. RS gives the Resource Handle and AS Transaction Endpoint back to = the client >> 4. Client calls the AS Transaction Endpoint to start a transaction, = includes the Resource Handle as part of its request (note: doesn=E2=80=99t= have to be the whole resource section, client can add stuff) >> 5. Process continues as normal >=20 > It depends on what you consider the =E2=80=9CAS=E2=80=9D. Consider the = following hypothetical architecture: >=20 > =E2=80=A2 The RS, client, and tx endpoint are on the public Internet. > =E2=80=A2 The tx endpoint returns interaction urls that point to an = IdP that is inaccessible from the public Internet. > =E2=80=A2 The user agent can reach the IdP, but none of the other = systems can. > =E2=80=A2 When the UA is redirected to the IdP, the IdP calls the tx = endpoint system to retrieve transaction details. > =E2=80=A2 When authorization is granted, the IdP pushes artifacts = directly to an endpoint provided by the client. >=20 > In this example, the client only interacts with the RS and the tx = endpoint. It seems odd to me to consider the system hosting the tx = endpoint to be the AS (or at least part of the AS), as its a glorified = message queue with essentially no authority in this architecture.=20 >=20 > We could go a step further and remove the client=E2=80=99s interaction = with the tx endpoint by having the RS return the interaction url = directly (you=E2=80=99d need to secure the client nonce if you want to = hide it from the RS, but that=E2=80=99s not that hard). >=20 > Is the meaning of =E2=80=9Cauthorization server=E2=80=9D (or the = phrase =E2=80=9Cthrough an authorization server=E2=80=9D) flexible = enough to accommodate these cases? Or are they considered out of scope = for TxAuth? >=20 >> =E2=80=94 Justin >>=20 >>>=20 >>> As I said, maybe I=E2=80=99m being too literal. >>>=20 >>>> =E1=90=A7 >>>> On Fri, Dec 20, 2019 at 5:08 PM Richard Backman, Annabelle = > wrote: >>>> I=E2=80=99m not sure if this is what Eve had in mind, but consider = an automated system in an enterprise context that has been authorized by = an administrator. The automated system isn=E2=80=99t acting as or on = behalf of the administrator, and the administrator hasn=E2=80=99t = =E2=80=9Cdelegated access=E2=80=9D; they=E2=80=99ve granted access, just = as they do when they assign permissions to users/groups/roles/etc. >>>>=20 >>>> Maybe I=E2=80=99m being too literal, but =E2=80=9Cthrough an = authorization server=E2=80=9D in paragraph 1 implies a specific = context/information/request flow to me. Given that one of TxAuth=E2=80=99s= features is decoupling the different communication channels, we should = not suggest that the client or authorizing party is directly interacting = with the AS. >>>>=20 >>>> =20 >>>>=20 >>>> =E2=80=93=20 >>>>=20 >>>> Annabelle Richard Backman >>>>=20 >>>> AWS Identity >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> From: Txauth > on behalf of Dick Hardt = > >>>> Date: Friday, December 20, 2019 at 4:14 PM >>>> To: Eve Maler > >>>> Cc: "rdd@cert.org " >, "txauth@ietf.org " = >, Justin Richer = >, Benjamin Kaduk = > >>>> Subject: Re: [Txauth] TxAuth Proposed Charter >>>>=20 >>>> =20 >>>>=20 >>>> Eve: do you not think the software client is acting on behalf of = some party? Or do you think that software always is acting on behalf of = some party, and the mentioned phrase is redundant? >>>>=20 >>>> =20 >>>>=20 >>>> Justin: a couple questions >>>>=20 >>>> =20 >>>>=20 >>>> 1. What is meant by "Delegation between multiple users" ? >>>>=20 >>>> =20 >>>>=20 >>>> 2. Why do you restrict this to HTTP? >>>>=20 >>>> =20 >>>>=20 >>>> 3. Why is authentication not in scope? >>>>=20 >>>> =20 >>>>=20 >>>> 4. When you say "not backwards compatible with OAuth 2.0 and its = extensions", do you expect to define a new standard to replace RFC 6750? = Developers will have to have a new method to call APIs? >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Fri, Dec 20, 2019 at 3:27 PM Eve Maler > wrote: >>>>=20 >>>> Re =E2=80=9Cto a software client _acting on behalf of an = authorizing party_=E2=80=9D: There is a whole lot of philosophy behind = whom the delegated access is performed on behalf of, unless the scenario = is single-user or some "act as" semantic is spelled out on the wire. = Does it need to be stated here? What's the consequence if the = highlighted phrase were removed?=20 >>>>=20 >>>> Eve Maler (sent from my iPad) | cell +1 425 345 6756 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Dec 20, 2019, at 4:34 PM, Justin Richer > wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> =20 >>>>=20 >>>> As discussed in Singapore, no matter what forum TxAuth takes, its = work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of time to put together a proposed charter text for the TxAuth work: >>>>=20 >>>> =20 >>>>=20 >>>> This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 >>>>=20 >>>> =20 >>>>=20 >>>> The group will deliver a protocol specification detailing how a = client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>>>=20 >>>> =20 >>>>=20 >>>> Additionally, the delegation process will allow for: >>>>=20 >>>> - Fine-grained specification of resource access >>>>=20 >>>> - Delegation between multiple users >>>>=20 >>>> - Web, mobile, single-page, and other client applications >>>>=20 >>>> =20 >>>>=20 >>>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>>=20 >>>> =20 >>>>=20 >>>> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >>>>=20 >>>> - User interaction mechanisms including web and non-web methods >>>>=20 >>>> - Token presentation mechanisms and key bindings >>>>=20 >>>> =20 >>>>=20 >>>> The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >>>>=20 >>>> =20 >>>>=20 >>>> While this work could be done in within the OAuth working group, I = now believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March.. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>>>=20 >>>> =20 >>>>=20 >>>> Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing = world. I plan to be engaged in both groups, and I know most of you are = as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>>>=20 >>>> =20 >>>>=20 >>>> I=E2=80=99ve published a blog post detailing more of my rationale: >>>>=20 >>>> =20 >>>>=20 >>>> = https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? = >>>> =20 >>>>=20 >>>> Please suggest changes to the proposed charter text above. It=E2=80=99= s my hope that we can get the chartering process started. >>>>=20 >>>> =20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_B8249B99-E5EB-4E22-B020-DE6CA2EF6140 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think you=E2=80=99re conflating the roles that = different components play, in regard to the other components, with the = potential deployment of those components. The spec needs to be written = in terms of the roles. While the roles do need to consider what = potential deployments might be, it=E2=80=99s important that we write = things in in terms of how they interact with each other and not in terms = of how they might look under the covers.

So from the clients perspective, the TX = Endpoint :is: the AS. The client doesn=E2=80=99t care that it=E2=80=99s = a =E2=80=9Cglorified message queue=E2=80=9D or if it=E2=80=99s a massive = server farm. The client doesn=E2=80=99t care if there=E2=80=99s a TLS = reverse proxy or if it=E2=80=99s talking directly to the application = layer. The only thing the client cares about is if the TX Endpoint does = the things that a TX Endpoint is supposed to do, and we define that to = be the function of the AS. 

What=E2=80=99s important in your = scenario below is that the client would have to talk to the RS first = every time. That=E2=80=99s one of the problems that UMA has, and I think = something we should avoid. I think RS-first is an interesting pattern = but AS-first ought to drive this. 

With your hypothetical layout below, it = really sounds like the TX Endpoint is a function of the IDP, which is = fine. The client doesn=E2=80=99t care that it=E2=80=99s deployed using = some externalized cloud service. The only weird thing going on is the = push from the AS back to the client. The client would need to register = that with the AS (or through the AS more specifically) as part of its = transaction request. This would be part of its interaction mechanism, = because =E2=80=9Chow you get messages and updates back to the client=E2=80= =9D is part of the interaction model. 

So for an RS-first transaction, the = client calls the RS:

GET /foo

The RS returns a resource handle, but the client doesn=E2=80=99= t care where that came from. The RS could talk to the AS to get it. = Probably a new endpoint of some kind, can probably use the same kinds of = key binding that the TX Endpoint has. Or the RS can make one up that the = TX Endpoint can recognize. Or it calls the IdP to get one. The client = doesn=E2=80=99t care, and that=E2=80=99s the key point. 

WWW-Authenticate = tx_endpoint=3D=E2=80=9Chttp://server//tx=E2=80=9D resource: = =E2=80=9Casdf1234=E2=80=9D

The client calls the TX endpoint like a normal = transaction:

POST /tx

{
  resources: [ =E2=80=9Casdf1234=E2= =80=9D ],
  interact: {
    redirect: true,
  =   push: =E2=80=9Chttp://client/push/9876=E2=80=9D
  }
}

The AS (which is to say the TX = Endpoint) tells the client to send the user agent to the IdP

{
  interact_url: =E2=80=9Chttp://idp/login=E2=80=9D,
  = handle: { value: =E2=80=9Chjkl=E2=80=9D, type: bearer }
}

Now= the client could poll the TX Endpoint but it could also just sit and = wait for an update to be pushed in. 

There are probably things that need to = be tied together for this to be secure, but I think the basic pattern = still fits. Importantly, the client doesn=E2=80=99t care whereby of that = stuff came from =E2=80=94 as far as it=E2=80=99s concerned, it=E2=80=99s = talking to the AS. 

Remember, the =E2=80=9CAS=E2=80=9D is a logical construct, = not a physical one. Just like the =E2=80=9Cclient=E2=80=9D could be a = cluster of applications and the =E2=80=9CRS=E2=80=9D could be a suite of = APIs tied behind a gateway.

 =E2=80=94 Justin


On Dec 22, 2019, at 1:05 AM, = Richard Backman, Annabelle <richanna@amazon.com> wrote:


On Dec 21, 2019, at 4:42 AM, Justin = Richer <jricher@mit.edu> wrote:

Even if the client starts at the RS, the client still = has to go talk to the AS. I haven=E2=80=99t built this out, but I see it = working somewhat like UMA. In XYZ=E2=80=99s terms:


1. Client calls the RS trying to Do A Thing
2. RS calls the AS requesting a Resource Handle (because = that=E2=80=99s what the RS represents, resources) =E2=80=94 at least = good enough to cover what the client tried to do, could be more
3. RS gives the Resource Handle and AS Transaction = Endpoint back to the client
4. Client calls the AS Transaction Endpoint to start a = transaction, includes the Resource Handle as part of its request (note: = doesn=E2=80=99t have to be the whole resource section, client can add = stuff)
5. Process continues as normal

It depends on what you consider the =E2=80=9CAS=E2=80=9D. = Consider the following hypothetical architecture:

=E2=80=A2 The RS, client, and tx endpoint are on the = public Internet.
=E2=80=A2 The tx endpoint returns interaction urls that = point to an IdP that is inaccessible from the public Internet.
=E2=80=A2 The user agent can reach the IdP, but none of = the other systems can.
=E2=80=A2 When the UA is redirected to the IdP, the IdP = calls the tx endpoint system to retrieve transaction details.
=E2=80=A2 When authorization is granted, the IdP pushes = artifacts directly to an endpoint provided by the client.

In this example, the client only interacts with the RS = and the tx endpoint. It seems odd to me to consider the system hosting = the tx endpoint to be the AS (or at least part of the AS), as its a = glorified message queue with essentially no authority in this architecture. 

We could go a step further and remove the client=E2=80=99s= interaction with the tx endpoint by having the RS return the = interaction url directly (you=E2=80=99d need to secure the client nonce = if you want to hide it from the RS, but that=E2=80=99s not that = hard).

Is the meaning of =E2=80=9Cauthorization server=E2=80=9D = (or the phrase =E2=80=9Cthrough an authorization server=E2=80=9D) = flexible enough to accommodate these cases? Or are they considered out = of scope for TxAuth?

 =E2=80=94 Justin


As I said, maybe I=E2=80=99m being too literal.

3D""=E1=90=A7
On Fri, Dec 20, 2019 at 5:08 PM = Richard Backman, Annabelle <richanna@amazon.com> wrote:

I=E2=80=99m not sure if this is what Eve had in = mind, but consider an automated system in an enterprise context that has = been authorized by an administrator. The automated system isn=E2=80=99t = acting as or on behalf of the administrator, and the administrator hasn=E2=80=99t =E2=80=9Cdelegated access=E2=80=9D; they=E2=80=99ve granted access, just as they do when they assign = permissions to users/groups/roles/etc.

Maybe I=E2=80=99m being too = literal, but =E2=80=9Cthrough an authorization server=E2=80=9D in = paragraph 1 implies a specific context/information/request flow to me. = Given that one of TxAuth=E2=80=99s features is decoupling the different = communication channels, we should not suggest that the client or authorizing party is directly = interacting with the AS.

 

=E2=80=93 

Annabelle Richard Backman

AWS Identity

 

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
Date: Friday, December 20, 2019 at 4:14 PM
To: Eve Maler <eve@xmlgrrl.com>
Cc: "rdd@cert.org" <rdd@cert.org>, "txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: [Txauth] TxAuth Proposed Charter

 

Eve: do you not think the = software client is acting on behalf of some party? Or do you think that = software always is acting on behalf of some party, and the mentioned = phrase is redundant?

 

Justin: a couple questions

 

1. What is meant by "Delegation = between multiple users" ?

 

2. Why do you restrict this to = HTTP?

 

3. Why is authentication not in = scope?

 

4. When you say "not backwards = compatible with OAuth 2.0 and its extensions", do you expect to define a = new standard to replace RFC 6750? Developers will have to have a new = method to call APIs?

 

 

On Fri, Dec 20, 2019 at 3:27 PM = Eve Maler <eve@xmlgrrl.com> wrote:

Re = =E2=80=9Cto a = software client _acting on behalf of an authorizing party_=E2=80=9D: = There is a whole lot of philosophy behind whom the delegated access is performed on = behalf of, unless the scenario is single-user or some "act as" semantic = is spelled out on the wire. Does it need to be stated here? What's the = consequence if the highlighted phrase were removed? 

Eve Maler (sent from my iPad) | cell +1 425 345 = 6756



On Dec 20, 2019, at = 4:34 PM, Justin Richer <jricher@mit.edu> wrote:

Hi all,

 

As discussed in Singapore, no = matter what forum TxAuth takes, its work will require a new charter. = With that in mind, I=E2=80=99ve taken a bit of time to put together a = proposed charter text for the TxAuth work:

 

This group is chartered to = develop a next-generation transactional authorization and delegation = protocol for HTTP-based APIs and their clients. These transactions will = allow an authorizing party to delegate a right of access for an API or set of APIs through an authorization server to a software client = acting on behalf of an authorizing party. 

 

The group will deliver a protocol = specification detailing how a client can request and obtain delegated = access, how an authorization server can provide delegated access, how an = authorized party can authorize delegated access, and how that authorized access can be communicated to the resources being protected. = These actions will be connected through an explicit transaction between = the client and authorization server, resulting in an artifact that will = allow the client to undertake the delegated action. 

 

Additionally, the delegation = process will allow for:

- Fine-grained specification of = resource access

- Delegation between multiple = users

- Web, mobile, single-page, and = other client applications

 

The group will define extension = points for this protocol to allow for flexibility in areas including:

 

- Cryptographic agility for keys, = message signatures, and proof of possession 

- User interaction mechanisms = including web and non-web methods

- Token presentation mechanisms = and key bindings

 

The artifacts for this work are = not intended or expected to be backwards-compatible with OAuth 2.0 and = its extensions. 

 

While this work could be done in = within the OAuth working group, I now believe that it should be done in = a new working group, and that we should try to get that working group up = and running prior to the Vancouver meeting in March.. I think this group should stay here on the TxAuth list, and it=E2=80=99s my = suggestion that the resulting work be called OAuth 3.0. 

 

Why a new group? I think that the = OAuth working group should remain focused on extending, patching, and = adapting OAuth 2.0 to a changing world. I plan to be engaged in both = groups, and I know most of you are as well, but that=E2=80=99s not = universal. Since OAuth 2.0 is so established already, there are a LOT of people = who aren=E2=80=99t going to be interested in something new any time = soon. But on the other hand, there are a number of people for whom OAuth = 2.0 does not work, or is at the very least a poor fit, and we=E2=80=99ll want to bring them in at this early stage. So even = with significant overlap, I think there=E2=80=99s enough disconnect in = the community from both sides that warrants a new group. In addition, I = think this is a big enough piece of work that it=E2=80=99s simply too much for the OAuth working group to be able to focus on. We wouldn=E2=80=99= t be able to get additional meeting time, and OAuth already has trouble = fitting into its two meeting slots as it is.

 

I=E2=80=99ve published a blog = post detailing more of my rationale:

 

https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a= -new-working-group-d6229ba8e36?

 

Please suggest changes to the = proposed charter text above. It=E2=80=99s my hope that we can get the = chartering process started.

 

 =E2=80=94 Justin

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth



= --Apple-Mail=_B8249B99-E5EB-4E22-B020-DE6CA2EF6140-- From nobody Sun Dec 22 19:46:46 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4A712006F for ; Sun, 22 Dec 2019 19:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=parecki-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 srf-k-yoEhwH for ; Sun, 22 Dec 2019 19:46:41 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 0849412000F for ; Sun, 22 Dec 2019 19:46:41 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id z193so14911355iof.1 for ; Sun, 22 Dec 2019 19:46:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W6/1n1doYNLwCv21B0JHSaFYOrbWDf7fD6Gkng1bxzc=; b=R3zGMnTgn++RDHWUkSV1qB773SLYYR9853CqSvlcA2XH3Mv1JY+TFZx9OiNNav8Gs2 oOth3vHp0TuNH+cVHk/wfZ3DYjvv6iTDobPonkwHya+AZxel5o5IVk9iWKViMNo5M5OC 8Uag0VE1iW1vUHN3f2t7jat3uthnIdA5XVpASIUSz+zC+ZSEZlO8KhMll9DQutuU08aI KCGznX1U4qQsYpS7hPoNne1vupEs28iYEO4C5y8WLOsmozxz0W6uxQAu9XqYIGXUtBKs qWTBnt6hr5EqY8RYEb2BaZW3/9sT4vVrUhem5F7C5zisytXNaN8nozjV5v+Bm0gZEE6J 1BjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W6/1n1doYNLwCv21B0JHSaFYOrbWDf7fD6Gkng1bxzc=; b=XpHaTNS8Pslmn9jTWRwyzMIyIviyGrKBO8/4vb3zrLi095OX8t+zdONaU1v+TQdJ8u z0yr+zbieAE1+iRyG9PiuilZC89G+t6vPxhynhoTuVi54hUYwroVuktnkZ4j+Z1F5ktI ZbzNMNWaRl3MUU/eZf4d2gx1KYuyJaiLITBsLa/fvVt+j8ds02rs+8OHkUXCm80aWOfx alNG2Ex2+EzVaPXcIiM+qsuh42wt3e/30duBdfQTQGS7aSTZ4RrvSnr8CO4ewy0lRnGd btFY+13FehcwSnFD+jsCyP8gosTvbVqZ3gZOY2URM2ZliP5Po8Dc/1MwIm88El9s2cyK fPjQ== X-Gm-Message-State: APjAAAUetuFltvzvgARdzZPpNOtHWc/kCrZ+DirTM3hN7choY3EaK7aI PvVkUwjr1iep81u0ZtKbzEtTxu2NcMs= X-Google-Smtp-Source: APXvYqwiYUJDFu1yQPofxE3o9KvkcTM6KJp8l5KXcGIBKtXJgXMt5FxLRHJzAY87pmtqNFpLJGc1GA== X-Received: by 2002:a6b:c804:: with SMTP id y4mr18192156iof.210.1577072799971; Sun, 22 Dec 2019 19:46:39 -0800 (PST) Received: from mail-il1-f180.google.com (mail-il1-f180.google.com. [209.85.166.180]) by smtp.gmail.com with ESMTPSA id 75sm8591380ila.61.2019.12.22.19.46.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Dec 2019 19:46:39 -0800 (PST) Received: by mail-il1-f180.google.com with SMTP id t8so12949113iln.4 for ; Sun, 22 Dec 2019 19:46:38 -0800 (PST) X-Received: by 2002:a92:d183:: with SMTP id z3mr23015079ilz.214.1577072798800; Sun, 22 Dec 2019 19:46:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Parecki Date: Sun, 22 Dec 2019 19:46:28 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Yaron Sheffer Cc: Benjamin Kaduk , Justin Richer , "rdd@cert.org" , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000f522d1059a56df30" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 03:46:44 -0000 --000000000000f522d1059a56df30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I do think authentication should be part of the charter from the outset. Frankly the fact that authentication is intentionally left out of OAuth and has to be bolted on to the side via OpenID Connect is one of the exact reasons people get confused about the whole space to begin with. It's a relatively minor addition to the existing proposed spec to make it useful as a minimum viable authentication solution, and I'd like to see that be addressed at the beginning of this work. I think we can do this in a smart way and that authentication should be included in the charter. Aaron On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer wrote= : > Hi Justin, > > > > I think the charter should mention target use cases. For example, =E2=80= =9Call use > cases supported by OAuth 2 will be supported by the new protocol=E2=80=9D= or =E2=80=9Cthe > protocol will support at least use cases X and Y=E2=80=9D. > > > > And given the importance of OIDC, we could say something like: =E2=80=9CT= he > protocol will allow future extension to support authentication, in an > analogous way to OpenID Connect. However authentication is explicitly not > part of the initial scope.=E2=80=9D > > > > Thanks, > > Yaron > > > > *From: *Txauth on behalf of Justin Richer < > jricher@mit.edu> > *Date: *Saturday, December 21, 2019 at 00:34 > *To: * > *Cc: *"rdd@cert.org" , Benjamin Kaduk > *Subject: *[Txauth] TxAuth Proposed Charter > > > > Hi all, > > > > As discussed in Singapore, no matter what forum TxAuth takes, its work > will require a new charter. With that in mind, I=E2=80=99ve taken a bit o= f time to > put together a proposed charter text for the TxAuth work: > > > > This group is chartered to develop a next-generation transactional > authorization and delegation protocol for HTTP-based APIs and their > clients. These transactions will allow an authorizing party to delegate a > right of access for an API or set of APIs through an authorization server > to a software client acting on behalf of an authorizing party. > > > > The group will deliver a protocol specification detailing how a client ca= n > request and obtain delegated access, how an authorization server can > provide delegated access, how an authorized party can authorize delegated > access, and how that authorized access can be communicated to the resourc= es > being protected. These actions will be connected through an explicit > transaction between the client and authorization server, resulting in an > artifact that will allow the client to undertake the delegated action. > > > > Additionally, the delegation process will allow for: > > - Fine-grained specification of resource access > > - Delegation between multiple users > > - Web, mobile, single-page, and other client applications > > > > The group will define extension points for this protocol to allow for > flexibility in areas including: > > > > - Cryptographic agility for keys, message signatures, and proof of > possession > > - User interaction mechanisms including web and non-web methods > > - Token presentation mechanisms and key bindings > > > > The artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 and its extensions. > > > > While this work could be done in within the OAuth working group, I now > believe that it should be done in a new working group, and that we should > try to get that working group up and running prior to the Vancouver meeti= ng > in March. I think this group should stay here on the TxAuth list, and it= =E2=80=99s > my suggestion that the resulting work be called OAuth 3.0. > > > > Why a new group? I think that the OAuth working group should remain > focused on extending, patching, and adapting OAuth 2.0 to a changing worl= d. > I plan to be engaged in both groups, and I know most of you are as well, > but that=E2=80=99s not universal. Since OAuth 2.0 is so established alrea= dy, there > are a LOT of people who aren=E2=80=99t going to be interested in somethin= g new any > time soon. But on the other hand, there are a number of people for whom > OAuth 2.0 does not work, or is at the very least a poor fit, and we=E2=80= =99ll want > to bring them in at this early stage. So even with significant overlap, I > think there=E2=80=99s enough disconnect in the community from both sides = that > warrants a new group. In addition, I think this is a big enough piece of > work that it=E2=80=99s simply too much for the OAuth working group to be = able to > focus on. We wouldn=E2=80=99t be able to get additional meeting time, and= OAuth > already has trouble fitting into its two meeting slots as it is. > > > > I=E2=80=99ve published a blog post detailing more of my rationale: > > > > > https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-worki= ng-group-d6229ba8e36? > > > > Please suggest changes to the proposed charter text above. It=E2=80=99s m= y hope > that we can get the chartering process started. > > > > =E2=80=94 Justin > > -- Txauth mailing list Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 ---- Aaron Parecki aaronparecki.com @aaronpk --000000000000f522d1059a56df30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do think authentication should be part of the char= ter from the outset. Frankly the fact that authentication is intentionally = left out of OAuth and has to be bolted on to the side via OpenID Connect is= one of the exact reasons people get confused about the whole space to begi= n with.=C2=A0

It&#= 39;s a relatively minor addition to the existing proposed spec to make it u= seful as a minimum viable authentication solution, and I'd like to see = that be addressed at the beginning of this work.
I think we can do this in a smart way and that aut= hentication should be included in the charter.
--
----
Aaron Parecki
<= div>aaronparecki.com<= /a>

--000000000000f522d1059a56df30-- From nobody Sun Dec 22 20:52:57 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D41120074 for ; Sun, 22 Dec 2019 20:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.397 X-Spam-Level: X-Spam-Status: No, score=-14.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 udz6u_yLjztv for ; Sun, 22 Dec 2019 20:52:51 -0800 (PST) Received: from smtp-fw-4101.amazon.com (smtp-fw-4101.amazon.com [72.21.198.25]) (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 0B4B3120025 for ; Sun, 22 Dec 2019 20:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1577076771; x=1608612771; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=W+cdrySqEwIleuPiXmHznwOO3Wn3oSBJyKJ+AN7ZHNM=; b=WVL+T8+6XY5U/FAkoMTiQ06HoRp134ZUe5NWilZDmaAEdk0EiQBnRs9p 6QNQm9dYxbAS+S4TStL31DAwbRb3/JMfICN5WTN5Q8DK9yNGxNbMpkk5i +Ldpy7bfkDRGSODRm677xksCFP/nZFzAuJY2jHA5Q6vNj99JTz7bQ1rWc U=; IronPort-SDR: 1gIOFJrDqb/p8jK12/n1lF5fPevO4YtFDM5MFAzaUz4G1pl/3TRF+g9CVWV8Z/sUFvjjTDrWBU Qhfe5nP3hD2w== X-IronPort-AV: E=Sophos;i="5.69,346,1571702400"; d="scan'208,217";a="9661565" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO email-inbound-relay-1e-27fb8269.us-east-1.amazon.com) ([10.43.8.6]) by smtp-border-fw-out-4101.iad4.amazon.com with ESMTP; 23 Dec 2019 04:52:48 +0000 Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan3.iad.amazon.com [10.40.159.166]) by email-inbound-relay-1e-27fb8269.us-east-1.amazon.com (Postfix) with ESMTPS id DB6F3A1CB7; Mon, 23 Dec 2019 04:52:46 +0000 (UTC) Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 23 Dec 2019 04:52:46 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 23 Dec 2019 04:52:45 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Mon, 23 Dec 2019 04:52:45 +0000 From: "Richard Backman, Annabelle" To: Justin Richer CC: Dick Hardt , Eve Maler , "rdd@cert.org" , "txauth@ietf.org" , "Benjamin Kaduk" Thread-Topic: [Txauth] TxAuth Proposed Charter Thread-Index: AQHVt4W+Cd5+sniY+0u9RUqE6+8fD6fDqwuAgAAMvQD//4lSAIAAjYeAgABdgjyAAFyWAIABI/3hgAFGlACAADdN4Q== Date: Mon, 23 Dec 2019 04:52:45 +0000 Message-ID: <78FA3EB7-C72F-4543-95A8-03123F4E40A1@amazon.com> References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> , <949341AE-C72B-4645-8F20-699F14529FFB@mit.edu> In-Reply-To: <949341AE-C72B-4645-8F20-699F14529FFB@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_78FA3EB7C72F454395A803123F4E40A1amazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 04:52:55 -0000 --_000_78FA3EB7C72F454395A803123F4E40A1amazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgZXhhbXBsZSBkZW1vbnN0cmF0ZXMgYW4gYXJjaGl0ZWN0dXJlIHdoZXJlIHRoZSBUWCBFbmRw b2ludCwgYXV0aGVudGljYXRpb24gc3lzdGVtLCBhbmQgdG9rZW4gaXNzdWVyIGFyZW7igJl0IHNp bXBseSBkaWZmZXJlbnQgbWljcm8gc2VydmljZXMsIHRoZXnigJlyZSBjb21wbGV0ZWx5IGluZGVw ZW5kZW50IHN5c3RlbXMgaW4gZGlmZmVyZW50IHRydXN0IGJvdW5kYXJpZXMsIHBvc3NpYmx5IGhh dmUgZGlmZmVyZW50IGRvbWFpbnMgYW5kIGRpZmZlcmVudCBrZXlzLiBUaGlzIGhhcyBpbXBsaWNh dGlvbnMgZm9yIHByb3RvY29sIGRlc2lnbi4gRm9yIGV4YW1wbGUsIGl0IHdvdWxkIG5vIGxvbmdl ciBiZSBzdWZmaWNpZW50IHRvIGhhdmUgYSBzaW5nbGUgandrc191cmksIGFzIE9BdXRoIDIuMCBo YXMuDQoNCklmIHdlIHdhbnQgdG8gc3VwcG9ydCB0aGlzIGtpbmQgb2Yg4oCcZGVjb21wb3NlZCBB U+KAnSBtb2RlbCwgdGhlbiB3ZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF04oCZcyBzdXBwb3J0ZWQg YnkgdGhlIGNoYXJ0ZXIgYW5kIGtlZXAgaXQgaW4gbWluZCBhcyB3ZSBkZXNpZ24gdGhlIHByb3Rv Y29sLiBXZSBjYW4gYWxzbyBkZWNpZGUgaXQgaXMgb3V0IG9mIHNjb3BlLCBidXQgd2Ugc2hvdWxk IGJlIGludGVudGlvbmFsIGFib3V0IHRoYXQgZGVjaXNpb24uDQoNClRvIG15IG1pbmQsIHRoaXMg cm9sZSBkZWNvbXBvc2l0aW9uIGlzIHRoZSBuZXh0IGxvZ2ljYWwgc3RlcCBhZnRlciB0aGUgY2hh bm5lbCBkZWNvbXBvc2l0aW9uIHRoYXQgVHhBdXRoIGFscmVhZHkgZG9lcy4gSSBzZWUgYSBsb3Qg b2YgcG90ZW50aWFsIGluIGl0IGFuZCB0aGluayB3ZSBzaG91bGQgYXQgbWluaW11bSBhdm9pZCBj bG9zaW5nIHRoZSBkb29yIG9uIGl0Lg0KDQpPbiBEZWMgMjIsIDIwMTksIGF0IDU6MzUgUE0sIEp1 c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4gd3JvdGU6DQoNCu+7vyBJIHRoaW5rIHlvdeKA mXJlIGNvbmZsYXRpbmcgdGhlIHJvbGVzIHRoYXQgZGlmZmVyZW50IGNvbXBvbmVudHMgcGxheSwg aW4gcmVnYXJkIHRvIHRoZSBvdGhlciBjb21wb25lbnRzLCB3aXRoIHRoZSBwb3RlbnRpYWwgZGVw bG95bWVudCBvZiB0aG9zZSBjb21wb25lbnRzLiBUaGUgc3BlYyBuZWVkcyB0byBiZSB3cml0dGVu IGluIHRlcm1zIG9mIHRoZSByb2xlcy4gV2hpbGUgdGhlIHJvbGVzIGRvIG5lZWQgdG8gY29uc2lk ZXIgd2hhdCBwb3RlbnRpYWwgZGVwbG95bWVudHMgbWlnaHQgYmUsIGl04oCZcyBpbXBvcnRhbnQg dGhhdCB3ZSB3cml0ZSB0aGluZ3MgaW4gaW4gdGVybXMgb2YgaG93IHRoZXkgaW50ZXJhY3Qgd2l0 aCBlYWNoIG90aGVyIGFuZCBub3QgaW4gdGVybXMgb2YgaG93IHRoZXkgbWlnaHQgbG9vayB1bmRl ciB0aGUgY292ZXJzLg0KDQpTbyBmcm9tIHRoZSBjbGllbnRzIHBlcnNwZWN0aXZlLCB0aGUgVFgg RW5kcG9pbnQgOmlzOiB0aGUgQVMuIFRoZSBjbGllbnQgZG9lc27igJl0IGNhcmUgdGhhdCBpdOKA mXMgYSDigJxnbG9yaWZpZWQgbWVzc2FnZSBxdWV1ZeKAnSBvciBpZiBpdOKAmXMgYSBtYXNzaXZl IHNlcnZlciBmYXJtLiBUaGUgY2xpZW50IGRvZXNu4oCZdCBjYXJlIGlmIHRoZXJl4oCZcyBhIFRM UyByZXZlcnNlIHByb3h5IG9yIGlmIGl04oCZcyB0YWxraW5nIGRpcmVjdGx5IHRvIHRoZSBhcHBs aWNhdGlvbiBsYXllci4gVGhlIG9ubHkgdGhpbmcgdGhlIGNsaWVudCBjYXJlcyBhYm91dCBpcyBp ZiB0aGUgVFggRW5kcG9pbnQgZG9lcyB0aGUgdGhpbmdzIHRoYXQgYSBUWCBFbmRwb2ludCBpcyBz dXBwb3NlZCB0byBkbywgYW5kIHdlIGRlZmluZSB0aGF0IHRvIGJlIHRoZSBmdW5jdGlvbiBvZiB0 aGUgQVMuDQoNCldoYXTigJlzIGltcG9ydGFudCBpbiB5b3VyIHNjZW5hcmlvIGJlbG93IGlzIHRo YXQgdGhlIGNsaWVudCB3b3VsZCBoYXZlIHRvIHRhbGsgdG8gdGhlIFJTIGZpcnN0IGV2ZXJ5IHRp bWUuIFRoYXTigJlzIG9uZSBvZiB0aGUgcHJvYmxlbXMgdGhhdCBVTUEgaGFzLCBhbmQgSSB0aGlu ayBzb21ldGhpbmcgd2Ugc2hvdWxkIGF2b2lkLiBJIHRoaW5rIFJTLWZpcnN0IGlzIGFuIGludGVy ZXN0aW5nIHBhdHRlcm4gYnV0IEFTLWZpcnN0IG91Z2h0IHRvIGRyaXZlIHRoaXMuDQoNCldpdGgg eW91ciBoeXBvdGhldGljYWwgbGF5b3V0IGJlbG93LCBpdCByZWFsbHkgc291bmRzIGxpa2UgdGhl IFRYIEVuZHBvaW50IGlzIGEgZnVuY3Rpb24gb2YgdGhlIElEUCwgd2hpY2ggaXMgZmluZS4gVGhl IGNsaWVudCBkb2VzbuKAmXQgY2FyZSB0aGF0IGl04oCZcyBkZXBsb3llZCB1c2luZyBzb21lIGV4 dGVybmFsaXplZCBjbG91ZCBzZXJ2aWNlLiBUaGUgb25seSB3ZWlyZCB0aGluZyBnb2luZyBvbiBp cyB0aGUgcHVzaCBmcm9tIHRoZSBBUyBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBjbGllbnQgd291 bGQgbmVlZCB0byByZWdpc3RlciB0aGF0IHdpdGggdGhlIEFTIChvciB0aHJvdWdoIHRoZSBBUyBt b3JlIHNwZWNpZmljYWxseSkgYXMgcGFydCBvZiBpdHMgdHJhbnNhY3Rpb24gcmVxdWVzdC4gVGhp cyB3b3VsZCBiZSBwYXJ0IG9mIGl0cyBpbnRlcmFjdGlvbiBtZWNoYW5pc20sIGJlY2F1c2Ug4oCc aG93IHlvdSBnZXQgbWVzc2FnZXMgYW5kIHVwZGF0ZXMgYmFjayB0byB0aGUgY2xpZW504oCdIGlz IHBhcnQgb2YgdGhlIGludGVyYWN0aW9uIG1vZGVsLg0KDQpTbyBmb3IgYW4gUlMtZmlyc3QgdHJh bnNhY3Rpb24sIHRoZSBjbGllbnQgY2FsbHMgdGhlIFJTOg0KDQpHRVQgL2Zvbw0KDQpUaGUgUlMg cmV0dXJucyBhIHJlc291cmNlIGhhbmRsZSwgYnV0IHRoZSBjbGllbnQgZG9lc27igJl0IGNhcmUg d2hlcmUgdGhhdCBjYW1lIGZyb20uIFRoZSBSUyBjb3VsZCB0YWxrIHRvIHRoZSBBUyB0byBnZXQg aXQuIFByb2JhYmx5IGEgbmV3IGVuZHBvaW50IG9mIHNvbWUga2luZCwgY2FuIHByb2JhYmx5IHVz ZSB0aGUgc2FtZSBraW5kcyBvZiBrZXkgYmluZGluZyB0aGF0IHRoZSBUWCBFbmRwb2ludCBoYXMu IE9yIHRoZSBSUyBjYW4gbWFrZSBvbmUgdXAgdGhhdCB0aGUgVFggRW5kcG9pbnQgY2FuIHJlY29n bml6ZS4gT3IgaXQgY2FsbHMgdGhlIElkUCB0byBnZXQgb25lLiBUaGUgY2xpZW50IGRvZXNu4oCZ dCBjYXJlLCBhbmQgdGhhdOKAmXMgdGhlIGtleSBwb2ludC4NCg0KV1dXLUF1dGhlbnRpY2F0ZSB0 eF9lbmRwb2ludD3igJxodHRwOi8vc2VydmVyLy90eDxodHRwOi8vc2VydmVyJUVGJUJGJUJEL3R4 PuKAnSByZXNvdXJjZTog4oCcYXNkZjEyMzTigJ0NCg0KVGhlIGNsaWVudCBjYWxscyB0aGUgVFgg ZW5kcG9pbnQgbGlrZSBhIG5vcm1hbCB0cmFuc2FjdGlvbjoNCg0KUE9TVCAvdHgNCg0Kew0KICBy ZXNvdXJjZXM6IFsg4oCcYXNkZjEyMzTigJ0gXSwNCiAgaW50ZXJhY3Q6IHsNCiAgICByZWRpcmVj dDogdHJ1ZSwNCiAgICBwdXNoOiDigJxodHRwOi8vY2xpZW50L3B1c2gvOTg3NuKAnQ0KICB9DQp9 DQoNClRoZSBBUyAod2hpY2ggaXMgdG8gc2F5IHRoZSBUWCBFbmRwb2ludCkgdGVsbHMgdGhlIGNs aWVudCB0byBzZW5kIHRoZSB1c2VyIGFnZW50IHRvIHRoZSBJZFANCg0Kew0KICBpbnRlcmFjdF91 cmw6IOKAnGh0dHA6Ly9pZHAvbG9naW7igJ0sDQogIGhhbmRsZTogeyB2YWx1ZTog4oCcaGprbOKA nSwgdHlwZTogYmVhcmVyIH0NCn0NCg0KTm93IHRoZSBjbGllbnQgY291bGQgcG9sbCB0aGUgVFgg RW5kcG9pbnQgYnV0IGl0IGNvdWxkIGFsc28ganVzdCBzaXQgYW5kIHdhaXQgZm9yIGFuIHVwZGF0 ZSB0byBiZSBwdXNoZWQgaW4uDQoNClRoZXJlIGFyZSBwcm9iYWJseSB0aGluZ3MgdGhhdCBuZWVk IHRvIGJlIHRpZWQgdG9nZXRoZXIgZm9yIHRoaXMgdG8gYmUgc2VjdXJlLCBidXQgSSB0aGluayB0 aGUgYmFzaWMgcGF0dGVybiBzdGlsbCBmaXRzLiBJbXBvcnRhbnRseSwgdGhlIGNsaWVudCBkb2Vz buKAmXQgY2FyZSB3aGVyZWJ5IG9mIHRoYXQgc3R1ZmYgY2FtZSBmcm9tIOKAlCBhcyBmYXIgYXMg aXTigJlzIGNvbmNlcm5lZCwgaXTigJlzIHRhbGtpbmcgdG8gdGhlIEFTLg0KDQpSZW1lbWJlciwg dGhlIOKAnEFT4oCdIGlzIGEgbG9naWNhbCBjb25zdHJ1Y3QsIG5vdCBhIHBoeXNpY2FsIG9uZS4g SnVzdCBsaWtlIHRoZSDigJxjbGllbnTigJ0gY291bGQgYmUgYSBjbHVzdGVyIG9mIGFwcGxpY2F0 aW9ucyBhbmQgdGhlIOKAnFJT4oCdIGNvdWxkIGJlIGEgc3VpdGUgb2YgQVBJcyB0aWVkIGJlaGlu ZCBhIGdhdGV3YXkuDQoNCiDigJQgSnVzdGluDQoNCg0KT24gRGVjIDIyLCAyMDE5LCBhdCAxOjA1 IEFNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWls dG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KDQoNCk9uIERlYyAyMSwgMjAxOSwgYXQg NDo0MiBBTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1p dC5lZHU+PiB3cm90ZToNCg0KRXZlbiBpZiB0aGUgY2xpZW50IHN0YXJ0cyBhdCB0aGUgUlMsIHRo ZSBjbGllbnQgc3RpbGwgaGFzIHRvIGdvIHRhbGsgdG8gdGhlIEFTLiBJIGhhdmVu4oCZdCBidWls dCB0aGlzIG91dCwgYnV0IEkgc2VlIGl0IHdvcmtpbmcgc29tZXdoYXQgbGlrZSBVTUEuIEluIFhZ WuKAmXMgdGVybXM6DQoNCg0KMS4gQ2xpZW50IGNhbGxzIHRoZSBSUyB0cnlpbmcgdG8gRG8gQSBU aGluZw0KMi4gUlMgY2FsbHMgdGhlIEFTIHJlcXVlc3RpbmcgYSBSZXNvdXJjZSBIYW5kbGUgKGJl Y2F1c2UgdGhhdOKAmXMgd2hhdCB0aGUgUlMgcmVwcmVzZW50cywgcmVzb3VyY2VzKSDigJQgYXQg bGVhc3QgZ29vZCBlbm91Z2ggdG8gY292ZXIgd2hhdCB0aGUgY2xpZW50IHRyaWVkIHRvIGRvLCBj b3VsZCBiZSBtb3JlDQozLiBSUyBnaXZlcyB0aGUgUmVzb3VyY2UgSGFuZGxlIGFuZCBBUyBUcmFu c2FjdGlvbiBFbmRwb2ludCBiYWNrIHRvIHRoZSBjbGllbnQNCjQuIENsaWVudCBjYWxscyB0aGUg QVMgVHJhbnNhY3Rpb24gRW5kcG9pbnQgdG8gc3RhcnQgYSB0cmFuc2FjdGlvbiwgaW5jbHVkZXMg dGhlIFJlc291cmNlIEhhbmRsZSBhcyBwYXJ0IG9mIGl0cyByZXF1ZXN0IChub3RlOiBkb2VzbuKA mXQgaGF2ZSB0byBiZSB0aGUgd2hvbGUgcmVzb3VyY2Ugc2VjdGlvbiwgY2xpZW50IGNhbiBhZGQg c3R1ZmYpDQo1LiBQcm9jZXNzIGNvbnRpbnVlcyBhcyBub3JtYWwNCg0KSXQgZGVwZW5kcyBvbiB3 aGF0IHlvdSBjb25zaWRlciB0aGUg4oCcQVPigJ0uIENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgaHlw b3RoZXRpY2FsIGFyY2hpdGVjdHVyZToNCg0K4oCiIFRoZSBSUywgY2xpZW50LCBhbmQgdHggZW5k cG9pbnQgYXJlIG9uIHRoZSBwdWJsaWMgSW50ZXJuZXQuDQrigKIgVGhlIHR4IGVuZHBvaW50IHJl dHVybnMgaW50ZXJhY3Rpb24gdXJscyB0aGF0IHBvaW50IHRvIGFuIElkUCB0aGF0IGlzIGluYWNj ZXNzaWJsZSBmcm9tIHRoZSBwdWJsaWMgSW50ZXJuZXQuDQrigKIgVGhlIHVzZXIgYWdlbnQgY2Fu IHJlYWNoIHRoZSBJZFAsIGJ1dCBub25lIG9mIHRoZSBvdGhlciBzeXN0ZW1zIGNhbi4NCuKAoiBX aGVuIHRoZSBVQSBpcyByZWRpcmVjdGVkIHRvIHRoZSBJZFAsIHRoZSBJZFAgY2FsbHMgdGhlIHR4 IGVuZHBvaW50IHN5c3RlbSB0byByZXRyaWV2ZSB0cmFuc2FjdGlvbiBkZXRhaWxzLg0K4oCiIFdo ZW4gYXV0aG9yaXphdGlvbiBpcyBncmFudGVkLCB0aGUgSWRQIHB1c2hlcyBhcnRpZmFjdHMgZGly ZWN0bHkgdG8gYW4gZW5kcG9pbnQgcHJvdmlkZWQgYnkgdGhlIGNsaWVudC4NCg0KSW4gdGhpcyBl eGFtcGxlLCB0aGUgY2xpZW50IG9ubHkgaW50ZXJhY3RzIHdpdGggdGhlIFJTIGFuZCB0aGUgdHgg ZW5kcG9pbnQuIEl0IHNlZW1zIG9kZCB0byBtZSB0byBjb25zaWRlciB0aGUgc3lzdGVtIGhvc3Rp bmcgdGhlIHR4IGVuZHBvaW50IHRvIGJlIHRoZSBBUyAob3IgYXQgbGVhc3QgcGFydCBvZiB0aGUg QVMpLCBhcyBpdHMgYSBnbG9yaWZpZWQgbWVzc2FnZSBxdWV1ZSB3aXRoIGVzc2VudGlhbGx5IG5v IGF1dGhvcml0eSBpbiB0aGlzIGFyY2hpdGVjdHVyZS4NCg0KV2UgY291bGQgZ28gYSBzdGVwIGZ1 cnRoZXIgYW5kIHJlbW92ZSB0aGUgY2xpZW504oCZcyBpbnRlcmFjdGlvbiB3aXRoIHRoZSB0eCBl bmRwb2ludCBieSBoYXZpbmcgdGhlIFJTIHJldHVybiB0aGUgaW50ZXJhY3Rpb24gdXJsIGRpcmVj dGx5ICh5b3XigJlkIG5lZWQgdG8gc2VjdXJlIHRoZSBjbGllbnQgbm9uY2UgaWYgeW91IHdhbnQg dG8gaGlkZSBpdCBmcm9tIHRoZSBSUywgYnV0IHRoYXTigJlzIG5vdCB0aGF0IGhhcmQpLg0KDQpJ cyB0aGUgbWVhbmluZyBvZiDigJxhdXRob3JpemF0aW9uIHNlcnZlcuKAnSAob3IgdGhlIHBocmFz ZSDigJx0aHJvdWdoIGFuIGF1dGhvcml6YXRpb24gc2VydmVy4oCdKSBmbGV4aWJsZSBlbm91Z2gg dG8gYWNjb21tb2RhdGUgdGhlc2UgY2FzZXM/IE9yIGFyZSB0aGV5IGNvbnNpZGVyZWQgb3V0IG9m IHNjb3BlIGZvciBUeEF1dGg/DQoNCiDigJQgSnVzdGluDQoNCg0KQXMgSSBzYWlkLCBtYXliZSBJ 4oCZbSBiZWluZyB0b28gbGl0ZXJhbC4NCg0KW2h0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90LmNv bS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJnR5cGU9emVyb2NvbnRl bnQmZ3VpZD04MTEyN2E5ZC0wNjQxLTQyM2MtYmU3Ny04MTIwNzAyNDExMDNd4ZCnDQpPbiBGcmks IERlYyAyMCwgMjAxOSBhdCA1OjA4IFBNIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlIDxyaWNo YW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4gd3JvdGU6DQpJ4oCZ bSBub3Qgc3VyZSBpZiB0aGlzIGlzIHdoYXQgRXZlIGhhZCBpbiBtaW5kLCBidXQgY29uc2lkZXIg YW4gYXV0b21hdGVkIHN5c3RlbSBpbiBhbiBlbnRlcnByaXNlIGNvbnRleHQgdGhhdCBoYXMgYmVl biBhdXRob3JpemVkIGJ5IGFuIGFkbWluaXN0cmF0b3IuIFRoZSBhdXRvbWF0ZWQgc3lzdGVtIGlz buKAmXQgYWN0aW5nIGFzIG9yIG9uIGJlaGFsZiBvZiB0aGUgYWRtaW5pc3RyYXRvciwgYW5kIHRo ZSBhZG1pbmlzdHJhdG9yIGhhc27igJl0IOKAnGRlbGVnYXRlZCBhY2Nlc3PigJ07IHRoZXnigJl2 ZSBncmFudGVkIGFjY2VzcywganVzdCBhcyB0aGV5IGRvIHdoZW4gdGhleSBhc3NpZ24gcGVybWlz c2lvbnMgdG8gdXNlcnMvZ3JvdXBzL3JvbGVzL2V0Yy4NCk1heWJlIEnigJltIGJlaW5nIHRvbyBs aXRlcmFsLCBidXQg4oCcdGhyb3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlcuKAnSBpbiBwYXJh Z3JhcGggMSBpbXBsaWVzIGEgc3BlY2lmaWMgY29udGV4dC9pbmZvcm1hdGlvbi9yZXF1ZXN0IGZs b3cgdG8gbWUuIEdpdmVuIHRoYXQgb25lIG9mIFR4QXV0aOKAmXMgZmVhdHVyZXMgaXMgZGVjb3Vw bGluZyB0aGUgZGlmZmVyZW50IGNvbW11bmljYXRpb24gY2hhbm5lbHMsIHdlIHNob3VsZCBub3Qg c3VnZ2VzdCB0aGF0IHRoZSBjbGllbnQgb3IgYXV0aG9yaXppbmcgcGFydHkgaXMgZGlyZWN0bHkg aW50ZXJhY3Rpbmcgd2l0aCB0aGUgQVMuDQoNCuKAkw0KQW5uYWJlbGxlIFJpY2hhcmQgQmFja21h bg0KQVdTIElkZW50aXR5DQoNCg0KRnJvbTogVHhhdXRoIDx0eGF1dGgtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGljayBIYXJk dCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4NCkRh dGU6IEZyaWRheSwgRGVjZW1iZXIgMjAsIDIwMTkgYXQgNDoxNCBQTQ0KVG86IEV2ZSBNYWxlciA8 ZXZlQHhtbGdycmwuY29tPG1haWx0bzpldmVAeG1sZ3JybC5jb20+Pg0KQ2M6ICJyZGRAY2VydC5v cmc8bWFpbHRvOnJkZEBjZXJ0Lm9yZz4iIDxyZGRAY2VydC5vcmc8bWFpbHRvOnJkZEBjZXJ0Lm9y Zz4+LCAidHhhdXRoQGlldGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+IiA8dHhhdXRoQGll dGYub3JnPG1haWx0bzp0eGF1dGhAaWV0Zi5vcmc+PiwgSnVzdGluIFJpY2hlciA8anJpY2hlckBt aXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiwgQmVuamFtaW4gS2FkdWsgPGthZHVrQG1p dC5lZHU8bWFpbHRvOmthZHVrQG1pdC5lZHU+Pg0KU3ViamVjdDogUmU6IFtUeGF1dGhdIFR4QXV0 aCBQcm9wb3NlZCBDaGFydGVyDQoNCkV2ZTogZG8geW91IG5vdCB0aGluayB0aGUgc29mdHdhcmUg Y2xpZW50IGlzIGFjdGluZyBvbiBiZWhhbGYgb2Ygc29tZSBwYXJ0eT8gT3IgZG8geW91IHRoaW5r IHRoYXQgc29mdHdhcmUgYWx3YXlzIGlzIGFjdGluZyBvbiBiZWhhbGYgb2Ygc29tZSBwYXJ0eSwg YW5kIHRoZSBtZW50aW9uZWQgcGhyYXNlIGlzIHJlZHVuZGFudD8NCg0KSnVzdGluOiBhIGNvdXBs ZSBxdWVzdGlvbnMNCg0KMS4gV2hhdCBpcyBtZWFudCBieSAiRGVsZWdhdGlvbiBiZXR3ZWVuIG11 bHRpcGxlIHVzZXJzIiA/DQoNCjIuIFdoeSBkbyB5b3UgcmVzdHJpY3QgdGhpcyB0byBIVFRQPw0K DQozLiBXaHkgaXMgYXV0aGVudGljYXRpb24gbm90IGluIHNjb3BlPw0KDQo0LiBXaGVuIHlvdSBz YXkgIm5vdCBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIE9BdXRoIDIuMCBhbmQgaXRzIGV4dGVu c2lvbnMiLCBkbyB5b3UgZXhwZWN0IHRvIGRlZmluZSBhIG5ldyBzdGFuZGFyZCB0byByZXBsYWNl IFJGQyA2NzUwPyBEZXZlbG9wZXJzIHdpbGwgaGF2ZSB0byBoYXZlIGEgbmV3IG1ldGhvZCB0byBj YWxsIEFQSXM/DQoNCg0KT24gRnJpLCBEZWMgMjAsIDIwMTkgYXQgMzoyNyBQTSBFdmUgTWFsZXIg PGV2ZUB4bWxncnJsLmNvbTxtYWlsdG86ZXZlQHhtbGdycmwuY29tPj4gd3JvdGU6DQpSZSDigJx0 byBhIHNvZnR3YXJlIGNsaWVudCBfYWN0aW5nIG9uIGJlaGFsZiBvZiBhbiBhdXRob3JpemluZyBw YXJ0eV/igJ06IFRoZXJlIGlzIGEgd2hvbGUgbG90IG9mIHBoaWxvc29waHkgYmVoaW5kIHdob20g dGhlIGRlbGVnYXRlZCBhY2Nlc3MgaXMgcGVyZm9ybWVkIG9uIGJlaGFsZiBvZiwgdW5sZXNzIHRo ZSBzY2VuYXJpbyBpcyBzaW5nbGUtdXNlciBvciBzb21lICJhY3QgYXMiIHNlbWFudGljIGlzIHNw ZWxsZWQgb3V0IG9uIHRoZSB3aXJlLiBEb2VzIGl0IG5lZWQgdG8gYmUgc3RhdGVkIGhlcmU/IFdo YXQncyB0aGUgY29uc2VxdWVuY2UgaWYgdGhlIGhpZ2hsaWdodGVkIHBocmFzZSB3ZXJlIHJlbW92 ZWQ/DQpFdmUgTWFsZXIgKHNlbnQgZnJvbSBteSBpUGFkKSB8IGNlbGwgKzEgNDI1IDM0NSA2NzU2 DQoNCg0KT24gRGVjIDIwLCAyMDE5LCBhdCA0OjM0IFBNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVy QG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KSGkgYWxsLA0KDQpBcyBk aXNjdXNzZWQgaW4gU2luZ2Fwb3JlLCBubyBtYXR0ZXIgd2hhdCBmb3J1bSBUeEF1dGggdGFrZXMs IGl0cyB3b3JrIHdpbGwgcmVxdWlyZSBhIG5ldyBjaGFydGVyLiBXaXRoIHRoYXQgaW4gbWluZCwg SeKAmXZlIHRha2VuIGEgYml0IG9mIHRpbWUgdG8gcHV0IHRvZ2V0aGVyIGEgcHJvcG9zZWQgY2hh cnRlciB0ZXh0IGZvciB0aGUgVHhBdXRoIHdvcms6DQoNClRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVk IHRvIGRldmVsb3AgYSBuZXh0LWdlbmVyYXRpb24gdHJhbnNhY3Rpb25hbCBhdXRob3JpemF0aW9u IGFuZCBkZWxlZ2F0aW9uIHByb3RvY29sIGZvciBIVFRQLWJhc2VkIEFQSXMgYW5kIHRoZWlyIGNs aWVudHMuIFRoZXNlIHRyYW5zYWN0aW9ucyB3aWxsIGFsbG93IGFuIGF1dGhvcml6aW5nIHBhcnR5 IHRvIGRlbGVnYXRlIGEgcmlnaHQgb2YgYWNjZXNzIGZvciBhbiBBUEkgb3Igc2V0IG9mIEFQSXMg dGhyb3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlciB0byBhIHNvZnR3YXJlIGNsaWVudCBhY3Rp bmcgb24gYmVoYWxmIG9mIGFuIGF1dGhvcml6aW5nIHBhcnR5Lg0KDQpUaGUgZ3JvdXAgd2lsbCBk ZWxpdmVyIGEgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBkZXRhaWxpbmcgaG93IGEgY2xpZW50IGNh biByZXF1ZXN0IGFuZCBvYnRhaW4gZGVsZWdhdGVkIGFjY2VzcywgaG93IGFuIGF1dGhvcml6YXRp b24gc2VydmVyIGNhbiBwcm92aWRlIGRlbGVnYXRlZCBhY2Nlc3MsIGhvdyBhbiBhdXRob3JpemVk IHBhcnR5IGNhbiBhdXRob3JpemUgZGVsZWdhdGVkIGFjY2VzcywgYW5kIGhvdyB0aGF0IGF1dGhv cml6ZWQgYWNjZXNzIGNhbiBiZSBjb21tdW5pY2F0ZWQgdG8gdGhlIHJlc291cmNlcyBiZWluZyBw cm90ZWN0ZWQuIFRoZXNlIGFjdGlvbnMgd2lsbCBiZSBjb25uZWN0ZWQgdGhyb3VnaCBhbiBleHBs aWNpdCB0cmFuc2FjdGlvbiBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIGF1dGhvcml6YXRpb24gc2Vy dmVyLCByZXN1bHRpbmcgaW4gYW4gYXJ0aWZhY3QgdGhhdCB3aWxsIGFsbG93IHRoZSBjbGllbnQg dG8gdW5kZXJ0YWtlIHRoZSBkZWxlZ2F0ZWQgYWN0aW9uLg0KDQpBZGRpdGlvbmFsbHksIHRoZSBk ZWxlZ2F0aW9uIHByb2Nlc3Mgd2lsbCBhbGxvdyBmb3I6DQotIEZpbmUtZ3JhaW5lZCBzcGVjaWZp Y2F0aW9uIG9mIHJlc291cmNlIGFjY2Vzcw0KLSBEZWxlZ2F0aW9uIGJldHdlZW4gbXVsdGlwbGUg dXNlcnMNCi0gV2ViLCBtb2JpbGUsIHNpbmdsZS1wYWdlLCBhbmQgb3RoZXIgY2xpZW50IGFwcGxp Y2F0aW9ucw0KDQpUaGUgZ3JvdXAgd2lsbCBkZWZpbmUgZXh0ZW5zaW9uIHBvaW50cyBmb3IgdGhp cyBwcm90b2NvbCB0byBhbGxvdyBmb3IgZmxleGliaWxpdHkgaW4gYXJlYXMgaW5jbHVkaW5nOg0K DQotIENyeXB0b2dyYXBoaWMgYWdpbGl0eSBmb3Iga2V5cywgbWVzc2FnZSBzaWduYXR1cmVzLCBh bmQgcHJvb2Ygb2YgcG9zc2Vzc2lvbg0KLSBVc2VyIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5j bHVkaW5nIHdlYiBhbmQgbm9uLXdlYiBtZXRob2RzDQotIFRva2VuIHByZXNlbnRhdGlvbiBtZWNo YW5pc21zIGFuZCBrZXkgYmluZGluZ3MNCg0KVGhlIGFydGlmYWN0cyBmb3IgdGhpcyB3b3JrIGFy ZSBub3QgaW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmUgYmFja3dhcmRzLWNvbXBhdGlibGUgd2l0 aCBPQXV0aCAyLjAgYW5kIGl0cyBleHRlbnNpb25zLg0KDQpXaGlsZSB0aGlzIHdvcmsgY291bGQg YmUgZG9uZSBpbiB3aXRoaW4gdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAsIEkgbm93IGJlbGlldmUg dGhhdCBpdCBzaG91bGQgYmUgZG9uZSBpbiBhIG5ldyB3b3JraW5nIGdyb3VwLCBhbmQgdGhhdCB3 ZSBzaG91bGQgdHJ5IHRvIGdldCB0aGF0IHdvcmtpbmcgZ3JvdXAgdXAgYW5kIHJ1bm5pbmcgcHJp b3IgdG8gdGhlIFZhbmNvdXZlciBtZWV0aW5nIGluIE1hcmNoLi4gSSB0aGluayB0aGlzIGdyb3Vw IHNob3VsZCBzdGF5IGhlcmUgb24gdGhlIFR4QXV0aCBsaXN0LCBhbmQgaXTigJlzIG15IHN1Z2dl c3Rpb24gdGhhdCB0aGUgcmVzdWx0aW5nIHdvcmsgYmUgY2FsbGVkIE9BdXRoIDMuMC4NCg0KV2h5 IGEgbmV3IGdyb3VwPyBJIHRoaW5rIHRoYXQgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAgc2hvdWxk IHJlbWFpbiBmb2N1c2VkIG9uIGV4dGVuZGluZywgcGF0Y2hpbmcsIGFuZCBhZGFwdGluZyBPQXV0 aCAyLjAgdG8gYSBjaGFuZ2luZyB3b3JsZC4gSSBwbGFuIHRvIGJlIGVuZ2FnZWQgaW4gYm90aCBn cm91cHMsIGFuZCBJIGtub3cgbW9zdCBvZiB5b3UgYXJlIGFzIHdlbGwsIGJ1dCB0aGF04oCZcyBu b3QgdW5pdmVyc2FsLiBTaW5jZSBPQXV0aCAyLjAgaXMgc28gZXN0YWJsaXNoZWQgYWxyZWFkeSwg dGhlcmUgYXJlIGEgTE9UIG9mIHBlb3BsZSB3aG8gYXJlbuKAmXQgZ29pbmcgdG8gYmUgaW50ZXJl c3RlZCBpbiBzb21ldGhpbmcgbmV3IGFueSB0aW1lIHNvb24uIEJ1dCBvbiB0aGUgb3RoZXIgaGFu ZCwgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHBlb3BsZSBmb3Igd2hvbSBPQXV0aCAyLjAgZG9lcyBu b3Qgd29yaywgb3IgaXMgYXQgdGhlIHZlcnkgbGVhc3QgYSBwb29yIGZpdCwgYW5kIHdl4oCZbGwg d2FudCB0byBicmluZyB0aGVtIGluIGF0IHRoaXMgZWFybHkgc3RhZ2UuIFNvIGV2ZW4gd2l0aCBz aWduaWZpY2FudCBvdmVybGFwLCBJIHRoaW5rIHRoZXJl4oCZcyBlbm91Z2ggZGlzY29ubmVjdCBp biB0aGUgY29tbXVuaXR5IGZyb20gYm90aCBzaWRlcyB0aGF0IHdhcnJhbnRzIGEgbmV3IGdyb3Vw LiBJbiBhZGRpdGlvbiwgSSB0aGluayB0aGlzIGlzIGEgYmlnIGVub3VnaCBwaWVjZSBvZiB3b3Jr IHRoYXQgaXTigJlzIHNpbXBseSB0b28gbXVjaCBmb3IgdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAg dG8gYmUgYWJsZSB0byBmb2N1cyBvbi4gV2Ugd291bGRu4oCZdCBiZSBhYmxlIHRvIGdldCBhZGRp dGlvbmFsIG1lZXRpbmcgdGltZSwgYW5kIE9BdXRoIGFscmVhZHkgaGFzIHRyb3VibGUgZml0dGlu ZyBpbnRvIGl0cyB0d28gbWVldGluZyBzbG90cyBhcyBpdCBpcy4NCg0KSeKAmXZlIHB1Ymxpc2hl ZCBhIGJsb2cgcG9zdCBkZXRhaWxpbmcgbW9yZSBvZiBteSByYXRpb25hbGU6DQoNCmh0dHBzOi8v bWVkaXVtLmNvbS9AanVzdGluc2VjdXJpdHkvdGhlLWNhc2UtZm9yLW9hdXRoLTMtMC13aHktYS1u ZXctd29ya2luZy1ncm91cC1kNjIyOWJhOGUzNj8NCg0KUGxlYXNlIHN1Z2dlc3QgY2hhbmdlcyB0 byB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0IGFib3ZlLiBJdOKAmXMgbXkgaG9wZSB0aGF0IHdl IGNhbiBnZXQgdGhlIGNoYXJ0ZXJpbmcgcHJvY2VzcyBzdGFydGVkLg0KDQog4oCUIEp1c3Rpbg0K LS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRoQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCi0t DQpUeGF1dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQoNCg0K --_000_78FA3EB7C72F454395A803123F4E40A1amazoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAw KTsiPk15IGV4YW1wbGUgZGVtb25zdHJhdGVzIGFuIGFyY2hpdGVjdHVyZSB3aGVyZSB0aGUgVFgg RW5kcG9pbnQsIGF1dGhlbnRpY2F0aW9uIHN5c3RlbSwgYW5kIHRva2VuIGlzc3VlciBhcmVu4oCZ dCBzaW1wbHkgZGlmZmVyZW50IG1pY3JvIHNlcnZpY2VzLCB0aGV54oCZcmUgY29tcGxldGVseSBp bmRlcGVuZGVudCBzeXN0ZW1zIGluIGRpZmZlcmVudA0KIHRydXN0IGJvdW5kYXJpZXMsIHBvc3Np Ymx5IGhhdmUgZGlmZmVyZW50IGRvbWFpbnMgYW5kIGRpZmZlcmVudCBrZXlzLiBUaGlzIGhhcyBp bXBsaWNhdGlvbnMgZm9yIHByb3RvY29sIGRlc2lnbi4gRm9yIGV4YW1wbGUsIGl0IHdvdWxkIG5v IGxvbmdlciBiZSBzdWZmaWNpZW50IHRvIGhhdmUgYSBzaW5nbGUgandrc191cmksIGFzIE9BdXRo IDIuMCBoYXMuPC9zcGFuPg0KPGRpdj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Ij48YnI+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0K PGRpdj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7Ij5JZiB3ZSB3YW50IHRvIHN1cHBvcnQgdGhpcyBraW5kIG9mIOKAnGRlY29tcG9z ZWQgQVPigJ0gbW9kZWwsIHRoZW4gd2UgbmVlZCB0byBtYWtlIHN1cmUgdGhhdOKAmXMgc3VwcG9y dGVkIGJ5IHRoZSBjaGFydGVyIGFuZCBrZWVwIGl0IGluIG1pbmQgYXMgd2UgZGVzaWduIHRoZSBw cm90b2NvbC4gV2UgY2FuIGFsc28gZGVjaWRlIGl0IGlzIG91dA0KIG9mIHNjb3BlLCBidXQgd2Ug c2hvdWxkIGJlIGludGVudGlvbmFsIGFib3V0IHRoYXQgZGVjaXNpb24uPGJyPg0KPC9zcGFuPjwv Zm9udD4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+VG8gbXkg bWluZCwgdGhpcyByb2xlIGRlY29tcG9zaXRpb24gaXMgdGhlIG5leHQgbG9naWNhbCBzdGVwIGFm dGVyIHRoZSBjaGFubmVsIGRlY29tcG9zaXRpb24gdGhhdCBUeEF1dGggYWxyZWFkeSBkb2VzLiBJ IHNlZSBhIGxvdCBvZiBwb3RlbnRpYWwgaW4gaXQgYW5kIHRoaW5rIHdlIHNob3VsZCBhdCBtaW5p bXVtIGF2b2lkIGNsb3NpbmcgdGhlIGRvb3Igb24gaXQuPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48 YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5PbiBEZWMgMjIsIDIwMTksIGF0IDU6MzUgUE0s IEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDsgd3JvdGU6PGJyPg0KPGJyPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGly PSJsdHIiPu+7vyBJIHRoaW5rIHlvdeKAmXJlIGNvbmZsYXRpbmcgdGhlIDxpIGNsYXNzPSIiPnJv bGVzPC9pPiZuYnNwO3RoYXQgZGlmZmVyZW50IGNvbXBvbmVudHMgcGxheSwgaW4gcmVnYXJkIHRv IHRoZSBvdGhlciBjb21wb25lbnRzLCB3aXRoIHRoZSBwb3RlbnRpYWwgZGVwbG95bWVudCBvZiB0 aG9zZSBjb21wb25lbnRzLiBUaGUgc3BlYyBuZWVkcyB0byBiZSB3cml0dGVuIGluIHRlcm1zIG9m IHRoZSByb2xlcy4gV2hpbGUgdGhlIHJvbGVzIGRvDQogbmVlZCB0byBjb25zaWRlciB3aGF0IHBv dGVudGlhbCBkZXBsb3ltZW50cyBtaWdodCBiZSwgaXTigJlzIGltcG9ydGFudCB0aGF0IHdlIHdy aXRlIHRoaW5ncyBpbiBpbiB0ZXJtcyBvZiBob3cgdGhleSBpbnRlcmFjdCB3aXRoIGVhY2ggb3Ro ZXIgYW5kIG5vdCBpbiB0ZXJtcyBvZiBob3cgdGhleSBtaWdodCBsb29rIHVuZGVyIHRoZSBjb3Zl cnMuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5T byBmcm9tIHRoZSBjbGllbnRzIHBlcnNwZWN0aXZlLCB0aGUgVFggRW5kcG9pbnQgOmlzOiB0aGUg QVMuIFRoZSBjbGllbnQgZG9lc27igJl0IGNhcmUgdGhhdCBpdOKAmXMgYSDigJxnbG9yaWZpZWQg bWVzc2FnZSBxdWV1ZeKAnSBvciBpZiBpdOKAmXMgYSBtYXNzaXZlIHNlcnZlciBmYXJtLiBUaGUg Y2xpZW50IGRvZXNu4oCZdCBjYXJlIGlmIHRoZXJl4oCZcyBhIFRMUyByZXZlcnNlIHByb3h5IG9y IGlmIGl04oCZcyB0YWxraW5nIGRpcmVjdGx5IHRvDQogdGhlIGFwcGxpY2F0aW9uIGxheWVyLiBU aGUgb25seSB0aGluZyB0aGUgY2xpZW50IGNhcmVzIGFib3V0IGlzIGlmIHRoZSBUWCBFbmRwb2lu dCBkb2VzIHRoZSB0aGluZ3MgdGhhdCBhIFRYIEVuZHBvaW50IGlzIHN1cHBvc2VkIHRvIGRvLCBh bmQgd2UgZGVmaW5lIHRoYXQgdG8gYmUgdGhlIGZ1bmN0aW9uIG9mIHRoZSBBUy4mbmJzcDs8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldo YXTigJlzIGltcG9ydGFudCBpbiB5b3VyIHNjZW5hcmlvIGJlbG93IGlzIHRoYXQgdGhlIGNsaWVu dCB3b3VsZCBoYXZlIHRvIHRhbGsgdG8gdGhlIFJTIGZpcnN0IGV2ZXJ5IHRpbWUuIFRoYXTigJlz IG9uZSBvZiB0aGUgcHJvYmxlbXMgdGhhdCBVTUEgaGFzLCBhbmQgSSB0aGluayBzb21ldGhpbmcg d2Ugc2hvdWxkIGF2b2lkLiBJIHRoaW5rIFJTLWZpcnN0IGlzIGFuIGludGVyZXN0aW5nIHBhdHRl cm4gYnV0IEFTLWZpcnN0IG91Z2h0DQogdG8gZHJpdmUgdGhpcy4mbmJzcDs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldpdGggeW91ciBo eXBvdGhldGljYWwgbGF5b3V0IGJlbG93LCBpdCByZWFsbHkgc291bmRzIGxpa2UgdGhlIFRYIEVu ZHBvaW50IGlzIGEgZnVuY3Rpb24gb2YgdGhlIElEUCwgd2hpY2ggaXMgZmluZS4gVGhlIGNsaWVu dCBkb2VzbuKAmXQgY2FyZSB0aGF0IGl04oCZcyBkZXBsb3llZCB1c2luZyBzb21lIGV4dGVybmFs aXplZCBjbG91ZCBzZXJ2aWNlLiBUaGUgb25seSB3ZWlyZCB0aGluZyBnb2luZyBvbiBpcyB0aGUg cHVzaCBmcm9tDQogdGhlIEFTIGJhY2sgdG8gdGhlIGNsaWVudC4gVGhlIGNsaWVudCB3b3VsZCBu ZWVkIHRvIHJlZ2lzdGVyIHRoYXQgd2l0aCB0aGUgQVMgKG9yIHRocm91Z2ggdGhlIEFTIG1vcmUg c3BlY2lmaWNhbGx5KSBhcyBwYXJ0IG9mIGl0cyB0cmFuc2FjdGlvbiByZXF1ZXN0LiBUaGlzIHdv dWxkIGJlIHBhcnQgb2YgaXRzIGludGVyYWN0aW9uIG1lY2hhbmlzbSwgYmVjYXVzZSDigJxob3cg eW91IGdldCBtZXNzYWdlcyBhbmQgdXBkYXRlcyBiYWNrIHRvIHRoZSBjbGllbnTigJ0NCiBpcyBw YXJ0IG9mIHRoZSBpbnRlcmFjdGlvbiBtb2RlbC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNvIGZvciBhbiBSUy1maXJzdCB0 cmFuc2FjdGlvbiwgdGhlIGNsaWVudCBjYWxscyB0aGUgUlM6PC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5HRVQgL2ZvbzwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIFJTIHJl dHVybnMgYSByZXNvdXJjZSBoYW5kbGUsIGJ1dCB0aGUgY2xpZW50IGRvZXNu4oCZdCBjYXJlIHdo ZXJlIHRoYXQgY2FtZSBmcm9tLiBUaGUgUlMgY291bGQgdGFsayB0byB0aGUgQVMgdG8gZ2V0IGl0 LiBQcm9iYWJseSBhIG5ldyBlbmRwb2ludCBvZiBzb21lIGtpbmQsIGNhbiBwcm9iYWJseSB1c2Ug dGhlIHNhbWUga2luZHMgb2Yga2V5IGJpbmRpbmcgdGhhdCB0aGUgVFggRW5kcG9pbnQgaGFzLiBP ciB0aGUgUlMNCiBjYW4gbWFrZSBvbmUgdXAgdGhhdCB0aGUgVFggRW5kcG9pbnQgY2FuIHJlY29n bml6ZS4gT3IgaXQgY2FsbHMgdGhlIElkUCB0byBnZXQgb25lLiBUaGUgY2xpZW50IGRvZXNu4oCZ dCBjYXJlLCBhbmQgdGhhdOKAmXMgdGhlIGtleSBwb2ludC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldXVy1BdXRoZW50aWNh dGUgdHhfZW5kcG9pbnQ94oCcPGEgaHJlZj0iaHR0cDovL3NlcnZlciVFRiVCRiVCRC90eCIgY2xh c3M9IiI+aHR0cDovL3NlcnZlci8vdHg8L2E+4oCdIHJlc291cmNlOiDigJxhc2RmMTIzNOKAnTwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ VGhlIGNsaWVudCBjYWxscyB0aGUgVFggZW5kcG9pbnQgbGlrZSBhIG5vcm1hbCB0cmFuc2FjdGlv bjo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlBPU1QgL3R4PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj57PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyByZXNvdXJjZXM6IFsg 4oCcYXNkZjEyMzTigJ0gXSw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7IGludGVyYWN0OiB7 PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgcmVkaXJlY3Q6IHRydWUsPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgcHVzaDog4oCcPGEgaHJlZj0iaHR0cDovL2Ns aWVudC9wdXNoLzk4NzYiIGNsYXNzPSIiPmh0dHA6Ly9jbGllbnQvcHVzaC85ODc2PC9hPuKAnTwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgfTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj59PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUg QVMgKHdoaWNoIGlzIHRvIHNheSB0aGUgVFggRW5kcG9pbnQpIHRlbGxzIHRoZSBjbGllbnQgdG8g c2VuZCB0aGUgdXNlciBhZ2VudCB0byB0aGUgSWRQPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj57PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOyBpbnRlcmFjdF91cmw6IOKAnDxhIGhyZWY9Imh0dHA6Ly9pZHAvbG9naW4iIGNsYXNzPSIi Pmh0dHA6Ly9pZHAvbG9naW48L2E+4oCdLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgaGFu ZGxlOiB7IHZhbHVlOiDigJxoamts4oCdLCB0eXBlOiBiZWFyZXIgfTwvZGl2Pg0KPGRpdiBjbGFz cz0iIj59PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5Ob3cgdGhlIGNsaWVudCBjb3VsZCBwb2xsIHRoZSBUWCBFbmRwb2ludCBidXQgaXQg Y291bGQgYWxzbyBqdXN0IHNpdCBhbmQgd2FpdCBmb3IgYW4gdXBkYXRlIHRvIGJlIHB1c2hlZCBp bi4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPlRoZXJlIGFyZSBwcm9iYWJseSB0aGluZ3MgdGhhdCBuZWVkIHRvIGJlIHRpZWQg dG9nZXRoZXIgZm9yIHRoaXMgdG8gYmUgc2VjdXJlLCBidXQgSSB0aGluayB0aGUgYmFzaWMgcGF0 dGVybiBzdGlsbCBmaXRzLiBJbXBvcnRhbnRseSwgdGhlIGNsaWVudCBkb2VzbuKAmXQgY2FyZSB3 aGVyZWJ5IG9mIHRoYXQgc3R1ZmYgY2FtZSBmcm9tIOKAlCBhcyBmYXIgYXMgaXTigJlzIGNvbmNl cm5lZCwgaXTigJlzIHRhbGtpbmcgdG8gdGhlIEFTLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmVtZW1iZXIsIHRoZSDigJxB U+KAnSBpcyBhIGxvZ2ljYWwgY29uc3RydWN0LCBub3QgYSBwaHlzaWNhbCBvbmUuIEp1c3QgbGlr ZSB0aGUg4oCcY2xpZW504oCdIGNvdWxkIGJlIGEgY2x1c3RlciBvZiBhcHBsaWNhdGlvbnMgYW5k IHRoZSDigJxSU+KAnSBjb3VsZCBiZSBhIHN1aXRlIG9mIEFQSXMgdGllZCBiZWhpbmQgYSBnYXRl d2F5LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+Jm5ic3A74oCUIEp1c3RpbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBEZWMgMjIsIDIwMTksIGF0 IDE6MDUgQU0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86 cmljaGFubmFAYW1hem9uLmNvbSIgY2xhc3M9IiI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRp diBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5P biBEZWMgMjEsIDIwMTksIGF0IDQ6NDIgQU0sIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpqcmljaGVyQG1pdC5lZHUiIGNsYXNzPSIiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdy b3RlOjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPkV2ZW4gaWYgdGhlIGNsaWVudCBzdGFydHMgYXQgdGhlIFJTLCB0 aGUgY2xpZW50IHN0aWxsIGhhcyB0byBnbyB0YWxrIHRvIHRoZSBBUy4gSSBoYXZlbuKAmXQgYnVp bHQgdGhpcyBvdXQsIGJ1dCBJIHNlZSBpdCB3b3JraW5nIHNvbWV3aGF0IGxpa2UgVU1BLiBJbiBY WVrigJlzIHRlcm1zOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjEuIENs aWVudCBjYWxscyB0aGUgUlMgdHJ5aW5nIHRvIERvIEEgVGhpbmc8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+Mi4gUlMgY2FsbHMgdGhlIEFTIHJlcXVlc3RpbmcgYSBSZXNvdXJjZSBIYW5kbGUgKGJlY2F1 c2UgdGhhdOKAmXMgd2hhdCB0aGUgUlMgcmVwcmVzZW50cywgcmVzb3VyY2VzKSDigJQgYXQgbGVh c3QgZ29vZCBlbm91Z2ggdG8gY292ZXIgd2hhdCB0aGUgY2xpZW50IHRyaWVkIHRvIGRvLCBjb3Vs ZCBiZSBtb3JlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjMuIFJTIGdpdmVzIHRoZSBSZXNvdXJjZSBI YW5kbGUgYW5kIEFTIFRyYW5zYWN0aW9uIEVuZHBvaW50IGJhY2sgdG8gdGhlIGNsaWVudDwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj40LiBDbGllbnQgY2FsbHMgdGhlIEFTIFRyYW5zYWN0aW9uIEVuZHBv aW50IHRvIHN0YXJ0IGEgdHJhbnNhY3Rpb24sIGluY2x1ZGVzIHRoZSBSZXNvdXJjZSBIYW5kbGUg YXMgcGFydCBvZiBpdHMgcmVxdWVzdCAobm90ZTogZG9lc27igJl0IGhhdmUgdG8gYmUgdGhlIHdo b2xlIHJlc291cmNlIHNlY3Rpb24sIGNsaWVudCBjYW4gYWRkIHN0dWZmKTwvZGl2Pg0KPGRpdiBj bGFzcz0iIj41LiBQcm9jZXNzIGNvbnRpbnVlcyBhcyBub3JtYWw8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5JdCBkZXBlbmRzIG9uIHdoYXQgeW91IGNvbnNpZGVyIHRoZSDigJxBU+KA nS4gQ29uc2lkZXIgdGhlIGZvbGxvd2luZyBoeXBvdGhldGljYWwgYXJjaGl0ZWN0dXJlOjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCi IFRoZSBSUywgY2xpZW50LCBhbmQgdHggZW5kcG9pbnQgYXJlIG9uIHRoZSBwdWJsaWMgSW50ZXJu ZXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAoiBUaGUgdHggZW5kcG9pbnQgcmV0dXJucyBpbnRl cmFjdGlvbiB1cmxzIHRoYXQgcG9pbnQgdG8gYW4gSWRQIHRoYXQgaXMgaW5hY2Nlc3NpYmxlIGZy b20gdGhlIHB1YmxpYyBJbnRlcm5ldC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCiIFRoZSB1c2Vy IGFnZW50IGNhbiByZWFjaCB0aGUgSWRQLCBidXQgbm9uZSBvZiB0aGUgb3RoZXIgc3lzdGVtcyBj YW4uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAoiBXaGVuIHRoZSBVQSBpcyByZWRpcmVjdGVkIHRv IHRoZSBJZFAsIHRoZSBJZFAgY2FsbHMgdGhlIHR4IGVuZHBvaW50IHN5c3RlbSB0byByZXRyaWV2 ZSB0cmFuc2FjdGlvbiBkZXRhaWxzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igKIgV2hlbiBhdXRo b3JpemF0aW9uIGlzIGdyYW50ZWQsIHRoZSBJZFAgcHVzaGVzIGFydGlmYWN0cyBkaXJlY3RseSB0 byBhbiBlbmRwb2ludCBwcm92aWRlZCBieSB0aGUgY2xpZW50LjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4gdGhpcyBleGFtcGxlLCB0 aGUgY2xpZW50IG9ubHkgaW50ZXJhY3RzIHdpdGggdGhlIFJTIGFuZCB0aGUgdHggZW5kcG9pbnQu IEl0IHNlZW1zIG9kZCB0byBtZSB0byBjb25zaWRlciB0aGUgc3lzdGVtIGhvc3RpbmcgdGhlIHR4 IGVuZHBvaW50IHRvIGJlIHRoZSBBUyAob3IgYXQgbGVhc3QgcGFydCBvZiB0aGUgQVMpLCBhcyBp dHMgYSBnbG9yaWZpZWQgbWVzc2FnZSBxdWV1ZSB3aXRoIGVzc2VudGlhbGx5IG5vIGF1dGhvcml0 eQ0KIGluIHRoaXMgYXJjaGl0ZWN0dXJlLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2UgY291bGQgZ28gYSBzdGVwIGZ1cnRo ZXIgYW5kIHJlbW92ZSB0aGUgY2xpZW504oCZcyBpbnRlcmFjdGlvbiB3aXRoIHRoZSB0eCBlbmRw b2ludCBieSBoYXZpbmcgdGhlIFJTIHJldHVybiB0aGUgaW50ZXJhY3Rpb24gdXJsIGRpcmVjdGx5 ICh5b3XigJlkIG5lZWQgdG8gc2VjdXJlIHRoZSBjbGllbnQgbm9uY2UgaWYgeW91IHdhbnQgdG8g aGlkZSBpdCBmcm9tIHRoZSBSUywgYnV0IHRoYXTigJlzIG5vdCB0aGF0IGhhcmQpLjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXMgdGhl IG1lYW5pbmcgb2Yg4oCcYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJ0gKG9yIHRoZSBwaHJhc2Ug4oCc dGhyb3VnaCBhbiBhdXRob3JpemF0aW9uIHNlcnZlcuKAnSkgZmxleGlibGUgZW5vdWdoIHRvIGFj Y29tbW9kYXRlIHRoZXNlIGNhc2VzPyBPciBhcmUgdGhleSBjb25zaWRlcmVkIG91dCBvZiBzY29w ZSBmb3IgVHhBdXRoPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDvigJQgSnVzdGluPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BcyBJIHNhaWQsIG1heWJlIEnigJltIGJl aW5nIHRvbyBsaXRlcmFsLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgaHNwYWNlPSJz dHJlYWstcHQtbWFyayIgc3R5bGU9Im1heC1oZWlnaHQ6MXB4IiBjbGFzcz0iIj48aW1nIGFsdD0i IiBzdHlsZT0id2lkdGg6MHB4O21heC1oZWlnaHQ6MHB4O292ZXJmbG93OmhpZGRlbiIgc3JjPSJo dHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RFQm5i V0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD04MTEyN2E5ZC0wNjQx LTQyM2MtYmU3Ny04MTIwNzAyNDExMDMiIGNsYXNzPSIiIGRhdGEtdW5pcXVlLWlkZW50aWZpZXI9 IiI+PGZvbnQgY29sb3I9IiNmZmZmZmYiIHNpemU9IjEiIGNsYXNzPSIiPuGQpzwvZm9udD48L2Rp dj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFp bF9hdHRyIj5PbiBGcmksIERlYyAyMCwgMjAxOSBhdCA1OjA4IFBNIFJpY2hhcmQgQmFja21hbiwg QW5uYWJlbGxlICZsdDs8YSBocmVmPSJtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbSIgY2xhc3M9 IiI+cmljaGFubmFAYW1hem9uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmct bGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFp bC1tXzI4MzY0NjI1NTA1NTQ4MzcwODhXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SeKAmW0gbm90IHN1cmUgaWYgdGhpcyBpcyB3aGF0IEV2ZSBoYWQgaW4gbWluZCwgYnV0IGNv bnNpZGVyIGFuIGF1dG9tYXRlZCBzeXN0ZW0gaW4gYW4gZW50ZXJwcmlzZSBjb250ZXh0IHRoYXQg aGFzIGJlZW4gYXV0aG9yaXplZCBieSBhbiBhZG1pbmlzdHJhdG9yLiBUaGUgYXV0b21hdGVkIHN5 c3RlbSBpc27igJl0IGFjdGluZyBhcyBvciBvbiBiZWhhbGYgb2YgdGhlIGFkbWluaXN0cmF0b3Is IGFuZCB0aGUgYWRtaW5pc3RyYXRvcg0KIGhhc27igJl0IOKAnGRlbGVnYXRlZCBhY2Nlc3PigJ07 IHRoZXnigJl2ZSA8aSBjbGFzcz0iIj5ncmFudGVkPC9pPiBhY2Nlc3MsIGp1c3QgYXMgdGhleSBk byB3aGVuIHRoZXkgYXNzaWduIHBlcm1pc3Npb25zIHRvIHVzZXJzL2dyb3Vwcy9yb2xlcy9ldGMu PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk1heWJlIEnigJltIGJlaW5nIHRvbyBsaXRlcmFsLCBidXQg4oCcdGhyb3VnaCBhbiBhdXRo b3JpemF0aW9uIHNlcnZlcuKAnSBpbiBwYXJhZ3JhcGggMSBpbXBsaWVzIGEgc3BlY2lmaWMgY29u dGV4dC9pbmZvcm1hdGlvbi9yZXF1ZXN0IGZsb3cgdG8gbWUuIEdpdmVuIHRoYXQgb25lIG9mIFR4 QXV0aOKAmXMgZmVhdHVyZXMgaXMgZGVjb3VwbGluZyB0aGUgZGlmZmVyZW50IGNvbW11bmljYXRp b24gY2hhbm5lbHMsIHdlIHNob3VsZA0KIG5vdCBzdWdnZXN0IHRoYXQgdGhlIGNsaWVudCBvciBh dXRob3JpemluZyBwYXJ0eSBpcyBkaXJlY3RseSBpbnRlcmFjdGluZyB3aXRoIHRoZSBBUy48dSBj bGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1 IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPGRpdiBjbGFzcz0iIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTJwdCIgY2xhc3M9 IiI+4oCTJm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0IiBjbGFzcz0i Ij5Bbm5hYmVsbGUgUmljaGFyZCBCYWNrbWFuPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwv dT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMnB0IiBjbGFzcz0iIj5BV1MgSWRlbnRpdHk8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+ PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1IGNsYXNzPSIi PjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUg Y2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXItcmlnaHQ6bm9uZTtib3JkZXItYm90dG9tOm5vbmU7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXIt dG9wOjFwdCBzb2xpZCByZ2IoMTgxLDE5NiwyMjMpO3BhZGRpbmc6M3B0IDBpbiAwaW4iIGNsYXNz PSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTJwdDsiIGNsYXNzPSIiPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMnB0OyIgY2xhc3M9IiI+VHhhdXRoICZsdDs8YSBocmVmPSJtYWlsdG86dHhhdXRo LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj50eGF1dGgtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJt YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5kaWNr LmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+RGF0ZTog PC9iPkZyaWRheSwgRGVjZW1iZXIgMjAsIDIwMTkgYXQgNDoxNCBQTTxiciBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPlRvOiA8L2I+RXZlIE1hbGVyICZsdDs8YSBocmVmPSJtYWlsdG86ZXZlQHhtbGdy cmwuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+ZXZlQHhtbGdycmwuY29tPC9hPiZndDs8 YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5DYzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpy ZGRAY2VydC5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5yZGRAY2VydC5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmRkQGNlcnQub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+cmRkQGNlcnQub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzp0eGF1dGhA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj50eGF1dGhAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+dHhhdXRoQGlldGYub3JnPC9hPiZndDssDQogSnVzdGluIFJpY2hlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmpy aWNoZXJAbWl0LmVkdTwvYT4mZ3Q7LCBCZW5qYW1pbiBLYWR1ayAmbHQ7PGEgaHJlZj0ibWFpbHRv OmthZHVrQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5rYWR1a0BtaXQuZWR1PC9h PiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OiA8L2I+UmU6IFtUeGF1dGhd IFR4QXV0aCBQcm9wb3NlZCBDaGFydGVyPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXZlOiBkbyB5 b3Ugbm90IHRoaW5rIHRoZSBzb2Z0d2FyZSBjbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFsZiBvZiBz b21lIHBhcnR5PyBPciBkbyB5b3UgdGhpbmsgdGhhdCBzb2Z0d2FyZSBhbHdheXMgaXMgYWN0aW5n IG9uIGJlaGFsZiBvZiBzb21lIHBhcnR5LCBhbmQgdGhlIG1lbnRpb25lZCBwaHJhc2UgaXMgcmVk dW5kYW50Pw0KPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8ZGl2IGNsYXNz PSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNz PSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5KdXN0aW46IGEgY291cGxlIHF1ZXN0aW9uczx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48 L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUg Y2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBXaGF0IGlzIG1lYW50IGJ5ICZxdW90O0Rl bGVnYXRpb24gYmV0d2VlbiBtdWx0aXBsZSB1c2VycyZxdW90OyA/PHUgY2xhc3M9IiI+PC91Pjx1 IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIFdoeSBkbyB5b3UgcmVz dHJpY3QgdGhpcyB0byBIVFRQPzx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+ PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBXaHkgaXMgYXV0aGVudGljYXRpb24gbm90IGluIHNjb3Bl Pzx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNsYXNz PSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij40LiBXaGVuIHlvdSBzYXkgJnF1b3Q7bm90IGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggT0F1 dGggMi4wIGFuZCBpdHMgZXh0ZW5zaW9ucyZxdW90OywgZG8geW91IGV4cGVjdCB0byBkZWZpbmUg YSBuZXcgc3RhbmRhcmQgdG8gcmVwbGFjZSBSRkMgNjc1MD8gRGV2ZWxvcGVycyB3aWxsIGhhdmUg dG8gaGF2ZSBhIG5ldyBtZXRob2QgdG8gY2FsbCBBUElzPzx1IGNsYXNzPSIiPjwvdT48dSBjbGFz cz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvcD4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBEZWMgMjAs IDIwMTkgYXQgMzoyNyBQTSBFdmUgTWFsZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpldmVAeG1sZ3Jy bC5jb20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5ldmVAeG1sZ3JybC5jb208L2E+Jmd0OyB3 cm90ZTo8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlci10b3A6bm9uZTtib3JkZXItcmlnaHQ6bm9uZTtib3JkZXItYm90 dG9tOm5vbmU7Ym9yZGVyLWxlZnQ6MXB0IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZzow aW4gMGluIDBpbiA2cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTJwdCI+UmUg4oCcPHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHdoaXRlOyBi YWNrZ3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGluaXRpYWw7IGJhY2tncm91bmQtcmVwZWF0OiBp bml0aWFsIGluaXRpYWw7IiBjbGFzcz0iIj50byBhIHNvZnR3YXJlIGNsaWVudCBfYWN0aW5nIG9u IGJlaGFsZiBvZiBhbiBhdXRob3JpemluZyBwYXJ0eV/igJ06IFRoZXJlIGlzIGEgd2hvbGUNCiBs b3Qgb2YgcGhpbG9zb3BoeSBiZWhpbmQgd2hvbSB0aGUgZGVsZWdhdGVkIGFjY2VzcyBpcyBwZXJm b3JtZWQgb24gYmVoYWxmIG9mLCB1bmxlc3MgdGhlIHNjZW5hcmlvIGlzIHNpbmdsZS11c2VyIG9y IHNvbWUgJnF1b3Q7YWN0IGFzJnF1b3Q7IHNlbWFudGljIGlzIHNwZWxsZWQgb3V0IG9uIHRoZSB3 aXJlLiBEb2VzIGl0IG5lZWQgdG8gYmUgc3RhdGVkIGhlcmU/IFdoYXQncyB0aGUgY29uc2VxdWVu Y2UgaWYgdGhlIGhpZ2hsaWdodGVkIHBocmFzZSB3ZXJlIHJlbW92ZWQ/Jm5ic3A7PC9zcGFuPjx1 IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEz cHQiIGNsYXNzPSIiPkV2ZSBNYWxlciAoc2VudCBmcm9tIG15IGlQYWQpIHwmbmJzcDtjZWxsICYj NDM7MSA0MjUgMzQ1IDY3NTY8L3NwYW4+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0i Ij48L3U+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NXB0O21hcmdpbi1ib3R0 b206NXB0IiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEycHQiPk9uIERlYyAyMCwgMjAxOSwgYXQgNDozNCBQTSwgSnVzdGluIFJpY2hlciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi PmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0i Ij48L3U+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1cHQ7bWFyZ2luLWJvdHRvbTo1cHQiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCwgPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIi PjwvdT48L3A+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9 IiI+PC91PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBkaXNjdXNzZWQgaW4gU2luZ2Fwb3JlLCBubyBtYXR0 ZXIgd2hhdCBmb3J1bSBUeEF1dGggdGFrZXMsIGl0cyB3b3JrIHdpbGwgcmVxdWlyZSBhIG5ldyBj aGFydGVyLiBXaXRoIHRoYXQgaW4gbWluZCwgSeKAmXZlIHRha2VuIGEgYml0IG9mIHRpbWUgdG8g cHV0IHRvZ2V0aGVyIGEgcHJvcG9zZWQgY2hhcnRlciB0ZXh0IGZvciB0aGUgVHhBdXRoIHdvcms6 PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9 IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwcHQ7 bWFyZ2luLXJpZ2h0OjBpbiIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBhIG5leHQtZ2VuZXJh dGlvbiB0cmFuc2FjdGlvbmFsIGF1dGhvcml6YXRpb24gYW5kIGRlbGVnYXRpb24gcHJvdG9jb2wg Zm9yIEhUVFAtYmFzZWQgQVBJcyBhbmQgdGhlaXIgY2xpZW50cy4gVGhlc2UgdHJhbnNhY3Rpb25z IHdpbGwgYWxsb3cgYW4gYXV0aG9yaXppbmcgcGFydHkgdG8gZGVsZWdhdGUgYSByaWdodCBvZiBh Y2Nlc3MgZm9yIGFuIEFQSQ0KIG9yIHNldCBvZiBBUElzIHRocm91Z2ggYW4gYXV0aG9yaXphdGlv biBzZXJ2ZXIgdG8gYSBzb2Z0d2FyZSBjbGllbnQgYWN0aW5nIG9uIGJlaGFsZiBvZiBhbiBhdXRo b3JpemluZyBwYXJ0eS4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1IGNsYXNzPSIi PjwvdT4mbmJzcDs8dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGdyb3VwIHdpbGwgZGVsaXZlciBhIHByb3RvY29sIHNw ZWNpZmljYXRpb24gZGV0YWlsaW5nIGhvdyBhIGNsaWVudCBjYW4gcmVxdWVzdCBhbmQgb2J0YWlu IGRlbGVnYXRlZCBhY2Nlc3MsIGhvdyBhbiBhdXRob3JpemF0aW9uIHNlcnZlciBjYW4gcHJvdmlk ZSBkZWxlZ2F0ZWQgYWNjZXNzLCBob3cgYW4gYXV0aG9yaXplZCBwYXJ0eSBjYW4gYXV0aG9yaXpl IGRlbGVnYXRlZCBhY2Nlc3MsIGFuZCBob3cgdGhhdA0KIGF1dGhvcml6ZWQgYWNjZXNzIGNhbiBi ZSBjb21tdW5pY2F0ZWQgdG8gdGhlIHJlc291cmNlcyBiZWluZyBwcm90ZWN0ZWQuIFRoZXNlIGFj dGlvbnMgd2lsbCBiZSBjb25uZWN0ZWQgdGhyb3VnaCBhbiBleHBsaWNpdCB0cmFuc2FjdGlvbiBi ZXR3ZWVuIHRoZSBjbGllbnQgYW5kIGF1dGhvcml6YXRpb24gc2VydmVyLCByZXN1bHRpbmcgaW4g YW4gYXJ0aWZhY3QgdGhhdCB3aWxsIGFsbG93IHRoZSBjbGllbnQgdG8gdW5kZXJ0YWtlIHRoZSBk ZWxlZ2F0ZWQNCiBhY3Rpb24uJm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFz cz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFkZGl0aW9uYWxseSwgdGhlIGRlbGVnYXRpb24gcHJv Y2VzcyB3aWxsIGFsbG93IGZvcjo8dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gRmluZS1ncmFp bmVkIHNwZWNpZmljYXRpb24gb2YgcmVzb3VyY2UgYWNjZXNzPHUgY2xhc3M9IiI+PC91Pjx1IGNs YXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tIERlbGVnYXRpb24gYmV0d2VlbiBtdWx0aXBsZSB1c2Vyczx1IGNsYXNzPSIiPjwvdT48 dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LSBXZWIsIG1vYmlsZSwgc2luZ2xlLXBhZ2UsIGFuZCBvdGhlciBjbGllbnQgYXBw bGljYXRpb25zPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7 PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBncm91cCB3aWxsIGRlZmluZSBleHRlbnNpb24gcG9pbnRzIGZvciB0aGlz IHByb3RvY29sIHRvIGFsbG93IGZvciBmbGV4aWJpbGl0eSBpbiBhcmVhcyBpbmNsdWRpbmc6PHUg Y2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g Q3J5cHRvZ3JhcGhpYyBhZ2lsaXR5IGZvciBrZXlzLCBtZXNzYWdlIHNpZ25hdHVyZXMsIGFuZCBw cm9vZiBvZiBwb3NzZXNzaW9uJm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFVzZXIg aW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFuZCBub24td2ViIG1ldGhvZHM8 dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVG9rZW4gcHJlc2VudGF0aW9uIG1lY2hhbmlzbXMg YW5kIGtleSBiaW5kaW5nczx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91 PiZuYnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGUgYXJ0aWZhY3RzIGZvciB0aGlzIHdvcmsgYXJlIG5vdCBpbnRl bmRlZCBvciBleHBlY3RlZCB0byBiZSBiYWNrd2FyZHMtY29tcGF0aWJsZSB3aXRoIE9BdXRoIDIu MCBhbmQgaXRzIGV4dGVuc2lvbnMuJm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwv dT48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIHRoaXMgd29y ayBjb3VsZCBiZSBkb25lIGluIHdpdGhpbiB0aGUgT0F1dGggd29ya2luZyBncm91cCwgSSBub3cg YmVsaWV2ZSB0aGF0IGl0IHNob3VsZCBiZSBkb25lIGluIGEgbmV3IHdvcmtpbmcgZ3JvdXAsIGFu ZCB0aGF0IHdlIHNob3VsZCB0cnkgdG8gZ2V0IHRoYXQgd29ya2luZyBncm91cCB1cCBhbmQgcnVu bmluZyBwcmlvciB0byB0aGUgVmFuY291dmVyIG1lZXRpbmcgaW4gTWFyY2guLiBJIHRoaW5rDQog dGhpcyBncm91cCBzaG91bGQgc3RheSBoZXJlIG9uIHRoZSBUeEF1dGggbGlzdCwgYW5kIGl04oCZ cyBteSBzdWdnZXN0aW9uIHRoYXQgdGhlIHJlc3VsdGluZyB3b3JrIGJlIGNhbGxlZCBPQXV0aCAz LjAuJm5ic3A7PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7 PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldoeSBhIG5ldyBncm91cD8gSSB0aGluayB0aGF0IHRoZSBPQXV0aCB3b3JraW5n IGdyb3VwIHNob3VsZCByZW1haW4gZm9jdXNlZCBvbiBleHRlbmRpbmcsIHBhdGNoaW5nLCBhbmQg YWRhcHRpbmcgT0F1dGggMi4wIHRvIGEgY2hhbmdpbmcgd29ybGQuIEkgcGxhbiB0byBiZSBlbmdh Z2VkIGluIGJvdGggZ3JvdXBzLCBhbmQgSSBrbm93IG1vc3Qgb2YgeW91IGFyZSBhcyB3ZWxsLCBi dXQgdGhhdOKAmXMgbm90IHVuaXZlcnNhbC4NCiBTaW5jZSBPQXV0aCAyLjAgaXMgc28gZXN0YWJs aXNoZWQgYWxyZWFkeSwgdGhlcmUgYXJlIGEgTE9UIG9mIHBlb3BsZSB3aG8gYXJlbuKAmXQgZ29p bmcgdG8gYmUgaW50ZXJlc3RlZCBpbiBzb21ldGhpbmcgbmV3IGFueSB0aW1lIHNvb24uIEJ1dCBv biB0aGUgb3RoZXIgaGFuZCwgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHBlb3BsZSBmb3Igd2hvbSBP QXV0aCAyLjAgZG9lcyBub3Qgd29yaywgb3IgaXMgYXQgdGhlIHZlcnkgbGVhc3QgYSBwb29yIGZp dCwNCiBhbmQgd2XigJlsbCB3YW50IHRvIGJyaW5nIHRoZW0gaW4gYXQgdGhpcyBlYXJseSBzdGFn ZS4gU28gZXZlbiB3aXRoIHNpZ25pZmljYW50IG92ZXJsYXAsIEkgdGhpbmsgdGhlcmXigJlzIGVu b3VnaCBkaXNjb25uZWN0IGluIHRoZSBjb21tdW5pdHkgZnJvbSBib3RoIHNpZGVzIHRoYXQgd2Fy cmFudHMgYSBuZXcgZ3JvdXAuIEluIGFkZGl0aW9uLCBJIHRoaW5rIHRoaXMgaXMgYSBiaWcgZW5v dWdoIHBpZWNlIG9mIHdvcmsgdGhhdCBpdOKAmXMgc2ltcGx5IHRvbw0KIG11Y2ggZm9yIHRoZSBP QXV0aCB3b3JraW5nIGdyb3VwIHRvIGJlIGFibGUgdG8gZm9jdXMgb24uIFdlIHdvdWxkbuKAmXQg YmUgYWJsZSB0byBnZXQgYWRkaXRpb25hbCBtZWV0aW5nIHRpbWUsIGFuZCBPQXV0aCBhbHJlYWR5 IGhhcyB0cm91YmxlIGZpdHRpbmcgaW50byBpdHMgdHdvIG1lZXRpbmcgc2xvdHMgYXMgaXQgaXMu PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dSBjbGFzcz0iIj48L3U+Jm5ic3A7PHUgY2xhc3M9 IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PknigJl2ZSBwdWJsaXNoZWQgYSBibG9nIHBvc3QgZGV0YWlsaW5nIG1vcmUgb2YgbXkgcmF0aW9u YWxlOjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91PiZuYnNwOzx1IGNs YXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBocmVmPSJodHRwczovL21lZGl1bS5jb20vQGp1c3RpbnNlY3VyaXR5L3RoZS1jYXNl LWZvci1vYXV0aC0zLTAtd2h5LWEtbmV3LXdvcmtpbmctZ3JvdXAtZDYyMjliYThlMzY/IiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly9tZWRpdW0uY29tL0BqdXN0aW5zZWN1cml0eS90 aGUtY2FzZS1mb3Itb2F1dGgtMy0wLXdoeS1hLW5ldy13b3JraW5nLWdyb3VwLWQ2MjI5YmE4ZTM2 PzwvYT48dSBjbGFzcz0iIj48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1IGNsYXNzPSIiPjwvdT4mbmJzcDs8dSBj bGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UGxlYXNlIHN1Z2dlc3QgY2hhbmdlcyB0byB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0 IGFib3ZlLiBJdOKAmXMgbXkgaG9wZSB0aGF0IHdlIGNhbiBnZXQgdGhlIGNoYXJ0ZXJpbmcgcHJv Y2VzcyBzdGFydGVkLjx1IGNsYXNzPSIiPjwvdT48dSBjbGFzcz0iIj48L3U+PC9wPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHUgY2xhc3M9IiI+PC91PiZu YnNwOzx1IGNsYXNzPSIiPjwvdT48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDvigJQgSnVzdGluPHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIi PjwvdT48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxiciBjbGFzcz0iIj4N ClR4YXV0aCBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86VHhhdXRo QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+VHhhdXRoQGlldGYub3JnPC9hPjxi ciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdHhhdXRoIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+PHUgY2xhc3M9IiI+PC91Pjx1IGNsYXNzPSIiPjwv dT48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LS0gPGJyIGNsYXNzPSIiPg0KVHhhdXRoIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxh IGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5U eGF1dGhAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT48dSBjbGFzcz0i Ij48L3U+PHUgY2xhc3M9IiI+PC91PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_78FA3EB7C72F454395A803123F4E40A1amazoncom_-- From nobody Mon Dec 23 13:51:46 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D91120131 for ; Mon, 23 Dec 2019 13:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 ap5RQb5c8vkt for ; Mon, 23 Dec 2019 13:51:42 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 37BB712011A for ; Mon, 23 Dec 2019 13:51:42 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBNLpbia030967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Dec 2019 16:51:38 -0500 From: Justin Richer Message-Id: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_9A0C0222-7BCC-4968-A9D3-AF2E08961457" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 23 Dec 2019 16:51:37 -0500 In-Reply-To: Cc: Yaron Sheffer , Benjamin Kaduk , "rdd@cert.org" , txauth@ietf.org To: Aaron Parecki References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 21:51:45 -0000 --Apple-Mail=_9A0C0222-7BCC-4968-A9D3-AF2E08961457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m fine with it being in charter but I do think it should be a = clearly separate layer, much like OIDC/Facebook Connect/GitHub Login/etc = are with OAuth today. In all of these the authorization is first, and I = think that=E2=80=99s the right pattern. So if we do take it on we=E2=80=99= ll just need to be careful how it=E2=80=99s structured in with = everything else. Otherwise, I think the authentication side can quickly = overwhelm and drag down the authorization side. Good news: A lot of the additional stuff in OIDC is there to patch holes = in core OAuth in a common fashion, and we=E2=80=99ll at least be in a = position to not have to do that again.=20 =E2=80=94 Justin > On Dec 22, 2019, at 10:46 PM, Aaron Parecki wrote: >=20 > I do think authentication should be part of the charter from the = outset. Frankly the fact that authentication is intentionally left out = of OAuth and has to be bolted on to the side via OpenID Connect is one = of the exact reasons people get confused about the whole space to begin = with.=20 >=20 > It's a relatively minor addition to the existing proposed spec to make = it useful as a minimum viable authentication solution, and I'd like to = see that be addressed at the beginning of this work. >=20 > I think we can do this in a smart way and that authentication should = be included in the charter. >=20 > Aaron >=20 >=20 >=20 >=20 > On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer > wrote: > Hi Justin, >=20 > =20 >=20 > I think the charter should mention target use cases. For example, = =E2=80=9Call use cases supported by OAuth 2 will be supported by the new = protocol=E2=80=9D or =E2=80=9Cthe protocol will support at least use = cases X and Y=E2=80=9D. >=20 > =20 >=20 > And given the importance of OIDC, we could say something like: =E2=80=9C= The protocol will allow future extension to support authentication, in = an analogous way to OpenID Connect. However authentication is explicitly = not part of the initial scope.=E2=80=9D >=20 > =20 >=20 > Thanks, >=20 > Yaron >=20 > =20 >=20 > From: Txauth > on behalf of Justin Richer = > > Date: Saturday, December 21, 2019 at 00:34 > To: > > Cc: "rdd@cert.org " >, Benjamin Kaduk > > Subject: [Txauth] TxAuth Proposed Charter >=20 > =20 >=20 > Hi all, >=20 > =20 >=20 > As discussed in Singapore, no matter what forum TxAuth takes, its work = will require a new charter. With that in mind, I=E2=80=99ve taken a bit = of time to put together a proposed charter text for the TxAuth work: >=20 > =20 >=20 > This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 >=20 > =20 >=20 > The group will deliver a protocol specification detailing how a client = can request and obtain delegated access, how an authorization server can = provide delegated access, how an authorized party can authorize = delegated access, and how that authorized access can be communicated to = the resources being protected. These actions will be connected through = an explicit transaction between the client and authorization server, = resulting in an artifact that will allow the client to undertake the = delegated action.=20 >=20 > =20 >=20 > Additionally, the delegation process will allow for: >=20 > - Fine-grained specification of resource access >=20 > - Delegation between multiple users >=20 > - Web, mobile, single-page, and other client applications >=20 > =20 >=20 > The group will define extension points for this protocol to allow for = flexibility in areas including: >=20 > =20 >=20 > - Cryptographic agility for keys, message signatures, and proof of = possession=20 >=20 > - User interaction mechanisms including web and non-web methods >=20 > - Token presentation mechanisms and key bindings >=20 > =20 >=20 > The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >=20 > =20 >=20 > While this work could be done in within the OAuth working group, I now = believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >=20 > =20 >=20 > Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing = world. I plan to be engaged in both groups, and I know most of you are = as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >=20 > =20 >=20 > I=E2=80=99ve published a blog post detailing more of my rationale: >=20 > =20 >=20 > = https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? = > =20 >=20 > Please suggest changes to the proposed charter text above. It=E2=80=99s = my hope that we can get the chartering process started. >=20 > =20 >=20 > =E2=80=94 Justin >=20 > -- Txauth mailing list Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth = --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = > --=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 --Apple-Mail=_9A0C0222-7BCC-4968-A9D3-AF2E08961457 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m fine with it being in charter but I do think it should be a clearly = separate layer, much like OIDC/Facebook Connect/GitHub Login/etc are = with OAuth today. In all of these the authorization is first, and I = think that=E2=80=99s the right pattern. So if we do take it on we=E2=80=99= ll just need to be careful how it=E2=80=99s structured in with = everything else. Otherwise, I think the authentication side can quickly = overwhelm and drag down the authorization side.

Good news: A lot of the additional = stuff in OIDC is there to patch holes in core OAuth in a common fashion, = and we=E2=80=99ll at least be in a position to not have to do that = again. 

 =E2=80=94 Justin

On Dec = 22, 2019, at 10:46 PM, Aaron Parecki <aaron@parecki.com> = wrote:

I do think = authentication should be part of the charter from the outset. Frankly = the fact that authentication is intentionally left out of OAuth and has = to be bolted on to the side via OpenID Connect is one of the exact = reasons people get confused about the whole space to begin = with. 

It's a relatively minor = addition to the existing proposed spec to make it useful as a minimum = viable authentication solution, and I'd like to see that be addressed at = the beginning of this work.

I think we can do this in = a smart way and that authentication should be included in the = charter.

Aaron




On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

Hi Justin,

 

I think the charter should mention target use cases. = For example, =E2=80=9Call use cases supported by OAuth 2 will be = supported by the new protocol=E2=80=9D or =E2=80=9Cthe protocol will = support at least use cases X and Y=E2=80=9D.

 

And given the importance of = OIDC, we could say something like: =E2=80=9CThe protocol will allow = future extension to support authentication, in an analogous way to = OpenID Connect. However authentication is explicitly not part of the = initial scope.=E2=80=9D

 

Thanks,

         =        Yaron

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer = <jricher@mit.edu>
Date: = Saturday, December 21, 2019 at 00:34
To: = <txauth@ietf.org>
Cc: = "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>
Subject: = [Txauth] TxAuth Proposed Charter

 

Hi= all,

 

As = discussed in Singapore, no matter what forum TxAuth takes, its work will = require a new charter. With that in mind, I=E2=80=99ve taken a bit of = time to put together a proposed charter text for the TxAuth work:

 

This group is chartered to develop a = next-generation transactional authorization and delegation protocol for = HTTP-based APIs and their clients. These transactions will allow an = authorizing party to delegate a right of access for an API or set of = APIs through an authorization server to a software client acting on = behalf of an authorizing party. 

 

The group will deliver a protocol specification = detailing how a client can request and obtain delegated access, how an = authorization server can provide delegated access, how an authorized = party can authorize delegated access, and how that authorized access can = be communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action. 

 

Additionally, the delegation process will allow = for:

- Fine-grained specification of resource access

- Delegation between multiple users

- Web, mobile, single-page, and other client = applications

 

The = group will define extension points for this protocol to allow for = flexibility in areas including:

 

- Cryptographic agility for keys, message = signatures, and proof of possession 

- User = interaction mechanisms including web and non-web methods

- Token presentation mechanisms and key bindings

 

The = artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions. 

 

While = this work could be done in within the OAuth working group, I now believe = that it should be done in a new working group, and that we should try to = get that working group up and running prior to the Vancouver meeting in = March. I think this group should stay here on the TxAuth list, and = it=E2=80=99s my suggestion that the resulting work be called OAuth = 3.0. 

 

Why a = new group? I think that the OAuth working group should remain focused on = extending, patching, and adapting OAuth 2.0 to a changing world. I plan = to be engaged in both groups, and I know most of you are as well, but = that=E2=80=99s not universal. Since OAuth 2.0 is so established already, = there are a LOT of people who aren=E2=80=99t going to be interested in = something new any time soon. But on the other hand, there are a number = of people for whom OAuth 2.0 does not work, or is at the very least a = poor fit, and we=E2=80=99ll want to bring them in at this early stage. = So even with significant overlap, I think there=E2=80=99s enough = disconnect in the community from both sides that warrants a new group. = In addition, I think this is a big enough piece of work that it=E2=80=99s = simply too much for the OAuth working group to be able to focus on. We = wouldn=E2=80=99t be able to get additional meeting time, and OAuth = already has trouble fitting into its two meeting slots as it is.

 

I=E2=80=99= ve published a blog post detailing more of my rationale:

 

https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a= -new-working-group-d6229ba8e36?

 

Please suggest changes to the proposed charter text = above. It=E2=80=99s my hope that we can get the chartering process = started.

 

 =E2=80= =94 Justin

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
----
Aaron Parecki
aaronparecki.com
@aaronpk


= --Apple-Mail=_9A0C0222-7BCC-4968-A9D3-AF2E08961457-- From nobody Mon Dec 23 13:57:38 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D747012006D for ; Mon, 23 Dec 2019 13:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 NtMQznLGpicA for ; Mon, 23 Dec 2019 13:57:33 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9182D12011A for ; Mon, 23 Dec 2019 13:57:32 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBNLvRFe032312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Dec 2019 16:57:27 -0500 From: Justin Richer Message-Id: <1FD41975-3CB5-48B6-88D5-6DB7511742CA@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_533DC25D-610D-4EB1-92C9-5AC6AC3D9E53" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 23 Dec 2019 16:57:26 -0500 In-Reply-To: <78FA3EB7-C72F-4543-95A8-03123F4E40A1@amazon.com> Cc: Dick Hardt , Eve Maler , "rdd@cert.org" , "txauth@ietf.org" , Benjamin Kaduk To: "Richard Backman, Annabelle" References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> <949341AE-C72B-4645-8F20-699F14529FFB@mit.edu> <78FA3EB7-C72F-4543-95A8-03123F4E40A1@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 21:57:37 -0000 --Apple-Mail=_533DC25D-610D-4EB1-92C9-5AC6AC3D9E53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So the thing is, I don=E2=80=99t think you need a single JWKS URI = anymore anyway. You=E2=80=99d have one associated with the TxEndpoint, = if you=E2=80=99ve got signed tokens that you need to validate = separately. And if you=E2=80=99re doing signed user assertions, you=E2=80=99= d have a different one identified in the assertion (either directly or = via an issuer-discovery mechanism). Ultimately the client is going to = care about one and the RS about another so it=E2=80=99s fine that = they=E2=80=99re different. We get to define what that looks like.=20 On the surface I=E2=80=99m OK with a decomposed AS, to some extent, but = only if there are very, very clear boundaries about what the individual = roles are. And the more roles we make, the more we have to define what = the communication points are in between them. Maybe =E2=80=9CAS=E2=80=9D = is too all-encompassing of a role now, but I=E2=80=99m not yet convinced = that=E2=80=99s true in practice, and I do want someone to be able to = deploy this by having all the =E2=80=9Cserver=E2=80=9D side = functionalities running out of a single, simple box. That might be a = case of that single box needing to play multiple roles, and that=E2=80=99s= OK, but we need to be clear on what kinds of optimizations are = allowable in cases like that. I do think there=E2=80=99s precedent in asking this question though, = since between OAuth 1 and 2 we split the =E2=80=9Cserver=E2=80=9D into = =E2=80=9CAS and RS=E2=80=9D. OAuth 2 famously didn=E2=80=99t define a = connection point between them until much later (JWT and Introspection), = but that pattern seems to have mostly worked. =E2=80=94 Justin > On Dec 22, 2019, at 11:52 PM, Richard Backman, Annabelle = wrote: >=20 > My example demonstrates an architecture where the TX Endpoint, = authentication system, and token issuer aren=E2=80=99t simply different = micro services, they=E2=80=99re completely independent systems in = different trust boundaries, possibly have different domains and = different keys. This has implications for protocol design. For example, = it would no longer be sufficient to have a single jwks_uri, as OAuth 2.0 = has. >=20 > If we want to support this kind of =E2=80=9Cdecomposed AS=E2=80=9D = model, then we need to make sure that=E2=80=99s supported by the charter = and keep it in mind as we design the protocol. We can also decide it is = out of scope, but we should be intentional about that decision. >=20 > To my mind, this role decomposition is the next logical step after the = channel decomposition that TxAuth already does. I see a lot of potential = in it and think we should at minimum avoid closing the door on it. >=20 >> On Dec 22, 2019, at 5:35 PM, Justin Richer wrote: >>=20 >> =EF=BB=BF I think you=E2=80=99re conflating the roles that different = components play, in regard to the other components, with the potential = deployment of those components. The spec needs to be written in terms of = the roles. While the roles do need to consider what potential = deployments might be, it=E2=80=99s important that we write things in in = terms of how they interact with each other and not in terms of how they = might look under the covers. >>=20 >> So from the clients perspective, the TX Endpoint :is: the AS. The = client doesn=E2=80=99t care that it=E2=80=99s a =E2=80=9Cglorified = message queue=E2=80=9D or if it=E2=80=99s a massive server farm. The = client doesn=E2=80=99t care if there=E2=80=99s a TLS reverse proxy or if = it=E2=80=99s talking directly to the application layer. The only thing = the client cares about is if the TX Endpoint does the things that a TX = Endpoint is supposed to do, and we define that to be the function of the = AS.=20 >>=20 >> What=E2=80=99s important in your scenario below is that the client = would have to talk to the RS first every time. That=E2=80=99s one of the = problems that UMA has, and I think something we should avoid. I think = RS-first is an interesting pattern but AS-first ought to drive this.=20 >>=20 >> With your hypothetical layout below, it really sounds like the TX = Endpoint is a function of the IDP, which is fine. The client doesn=E2=80=99= t care that it=E2=80=99s deployed using some externalized cloud service. = The only weird thing going on is the push from the AS back to the = client. The client would need to register that with the AS (or through = the AS more specifically) as part of its transaction request. This would = be part of its interaction mechanism, because =E2=80=9Chow you get = messages and updates back to the client=E2=80=9D is part of the = interaction model.=20 >>=20 >> So for an RS-first transaction, the client calls the RS: >>=20 >> GET /foo >>=20 >> The RS returns a resource handle, but the client doesn=E2=80=99t care = where that came from. The RS could talk to the AS to get it. Probably a = new endpoint of some kind, can probably use the same kinds of key = binding that the TX Endpoint has. Or the RS can make one up that the TX = Endpoint can recognize. Or it calls the IdP to get one. The client = doesn=E2=80=99t care, and that=E2=80=99s the key point.=20 >>=20 >> WWW-Authenticate tx_endpoint=3D=E2=80=9Chttp://server//tx = =E2=80=9D resource: =E2=80=9Casdf1234=E2=80=9D >>=20 >> The client calls the TX endpoint like a normal transaction: >>=20 >> POST /tx >>=20 >> { >> resources: [ =E2=80=9Casdf1234=E2=80=9D ], >> interact: { >> redirect: true, >> push: =E2=80=9Chttp://client/push/9876 = =E2=80=9D >> } >> } >>=20 >> The AS (which is to say the TX Endpoint) tells the client to send the = user agent to the IdP >>=20 >> { >> interact_url: =E2=80=9Chttp://idp/login =E2=80=9D, >> handle: { value: =E2=80=9Chjkl=E2=80=9D, type: bearer } >> } >>=20 >> Now the client could poll the TX Endpoint but it could also just sit = and wait for an update to be pushed in.=20 >>=20 >> There are probably things that need to be tied together for this to = be secure, but I think the basic pattern still fits. Importantly, the = client doesn=E2=80=99t care whereby of that stuff came from =E2=80=94 as = far as it=E2=80=99s concerned, it=E2=80=99s talking to the AS.=20 >>=20 >> Remember, the =E2=80=9CAS=E2=80=9D is a logical construct, not a = physical one. Just like the =E2=80=9Cclient=E2=80=9D could be a cluster = of applications and the =E2=80=9CRS=E2=80=9D could be a suite of APIs = tied behind a gateway. >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>> On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle = > wrote: >>>=20 >>>=20 >>>> On Dec 21, 2019, at 4:42 AM, Justin Richer > wrote: >>>=20 >>>> Even if the client starts at the RS, the client still has to go = talk to the AS. I haven=E2=80=99t built this out, but I see it working = somewhat like UMA. In XYZ=E2=80=99s terms: >>>>=20 >>>>=20 >>>> 1. Client calls the RS trying to Do A Thing >>>> 2. RS calls the AS requesting a Resource Handle (because that=E2=80=99= s what the RS represents, resources) =E2=80=94 at least good enough to = cover what the client tried to do, could be more >>>> 3. RS gives the Resource Handle and AS Transaction Endpoint back to = the client >>>> 4. Client calls the AS Transaction Endpoint to start a transaction, = includes the Resource Handle as part of its request (note: doesn=E2=80=99t= have to be the whole resource section, client can add stuff) >>>> 5. Process continues as normal >>>=20 >>> It depends on what you consider the =E2=80=9CAS=E2=80=9D. Consider = the following hypothetical architecture: >>>=20 >>> =E2=80=A2 The RS, client, and tx endpoint are on the public = Internet. >>> =E2=80=A2 The tx endpoint returns interaction urls that point to an = IdP that is inaccessible from the public Internet. >>> =E2=80=A2 The user agent can reach the IdP, but none of the other = systems can. >>> =E2=80=A2 When the UA is redirected to the IdP, the IdP calls the tx = endpoint system to retrieve transaction details. >>> =E2=80=A2 When authorization is granted, the IdP pushes artifacts = directly to an endpoint provided by the client. >>>=20 >>> In this example, the client only interacts with the RS and the tx = endpoint. It seems odd to me to consider the system hosting the tx = endpoint to be the AS (or at least part of the AS), as its a glorified = message queue with essentially no authority in this architecture.=20 >>>=20 >>> We could go a step further and remove the client=E2=80=99s = interaction with the tx endpoint by having the RS return the interaction = url directly (you=E2=80=99d need to secure the client nonce if you want = to hide it from the RS, but that=E2=80=99s not that hard). >>>=20 >>> Is the meaning of =E2=80=9Cauthorization server=E2=80=9D (or the = phrase =E2=80=9Cthrough an authorization server=E2=80=9D) flexible = enough to accommodate these cases? Or are they considered out of scope = for TxAuth? >>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>>=20 >>>>> As I said, maybe I=E2=80=99m being too literal. >>>>>=20 >>>>>> =E1=90=A7 >>>>>> On Fri, Dec 20, 2019 at 5:08 PM Richard Backman, Annabelle = > wrote: >>>>>> I=E2=80=99m not sure if this is what Eve had in mind, but = consider an automated system in an enterprise context that has been = authorized by an administrator. The automated system isn=E2=80=99t = acting as or on behalf of the administrator, and the administrator = hasn=E2=80=99t =E2=80=9Cdelegated access=E2=80=9D; they=E2=80=99ve = granted access, just as they do when they assign permissions to = users/groups/roles/etc. >>>>>>=20 >>>>>> Maybe I=E2=80=99m being too literal, but =E2=80=9Cthrough an = authorization server=E2=80=9D in paragraph 1 implies a specific = context/information/request flow to me. Given that one of TxAuth=E2=80=99s= features is decoupling the different communication channels, we should = not suggest that the client or authorizing party is directly interacting = with the AS. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =E2=80=93=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> From: Txauth > on behalf of Dick Hardt = > >>>>>> Date: Friday, December 20, 2019 at 4:14 PM >>>>>> To: Eve Maler > >>>>>> Cc: "rdd@cert.org " >, "txauth@ietf.org " = >, Justin Richer = >, Benjamin Kaduk = > >>>>>> Subject: Re: [Txauth] TxAuth Proposed Charter >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Eve: do you not think the software client is acting on behalf of = some party? Or do you think that software always is acting on behalf of = some party, and the mentioned phrase is redundant? >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Justin: a couple questions >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> 1. What is meant by "Delegation between multiple users" ? >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> 2. Why do you restrict this to HTTP? >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> 3. Why is authentication not in scope? >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> 4. When you say "not backwards compatible with OAuth 2.0 and its = extensions", do you expect to define a new standard to replace RFC 6750? = Developers will have to have a new method to call APIs? >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Fri, Dec 20, 2019 at 3:27 PM Eve Maler > wrote: >>>>>>=20 >>>>>> Re =E2=80=9Cto a software client _acting on behalf of an = authorizing party_=E2=80=9D: There is a whole lot of philosophy behind = whom the delegated access is performed on behalf of, unless the scenario = is single-user or some "act as" semantic is spelled out on the wire. = Does it need to be stated here? What's the consequence if the = highlighted phrase were removed?=20 >>>>>>=20 >>>>>> Eve Maler (sent from my iPad) | cell +1 425 345 6756 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Dec 20, 2019, at 4:34 PM, Justin Richer > wrote: >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> As discussed in Singapore, no matter what forum TxAuth takes, its = work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of time to put together a proposed charter text for the TxAuth work: >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> This group is chartered to develop a next-generation = transactional authorization and delegation protocol for HTTP-based APIs = and their clients. These transactions will allow an authorizing party to = delegate a right of access for an API or set of APIs through an = authorization server to a software client acting on behalf of an = authorizing party.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> The group will deliver a protocol specification detailing how a = client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Additionally, the delegation process will allow for: >>>>>>=20 >>>>>> - Fine-grained specification of resource access >>>>>>=20 >>>>>> - Delegation between multiple users >>>>>>=20 >>>>>> - Web, mobile, single-page, and other client applications >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> - Cryptographic agility for keys, message signatures, and proof = of possession=20 >>>>>>=20 >>>>>> - User interaction mechanisms including web and non-web methods >>>>>>=20 >>>>>> - Token presentation mechanisms and key bindings >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> While this work could be done in within the OAuth working group, = I now believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March.. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Why a new group? I think that the OAuth working group should = remain focused on extending, patching, and adapting OAuth 2.0 to a = changing world. I plan to be engaged in both groups, and I know most of = you are as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> I=E2=80=99ve published a blog post detailing more of my = rationale: >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> = https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? = >>>>>> =20 >>>>>>=20 >>>>>> Please suggest changes to the proposed charter text above. It=E2=80= =99s my hope that we can get the chartering process started. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>> --=20 >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>> --=20 >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 --Apple-Mail=_533DC25D-610D-4EB1-92C9-5AC6AC3D9E53 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 So = the thing is, I don=E2=80=99t think you need a single JWKS URI anymore = anyway. You=E2=80=99d have one associated with the TxEndpoint, if = you=E2=80=99ve got signed tokens that you need to validate separately. = And if you=E2=80=99re doing signed user assertions, you=E2=80=99d have a = different one identified in the assertion (either directly or via an = issuer-discovery mechanism). Ultimately the client is going to care = about one and the RS about another so it=E2=80=99s fine that they=E2=80=99= re different. We get to define what that looks like. 

On the surface I=E2=80=99m= OK with a decomposed AS, to some extent, but only if there are very, = very clear boundaries about what the individual roles are. And the more = roles we make, the more we have to define what the communication points = are in between them. Maybe =E2=80=9CAS=E2=80=9D is too all-encompassing = of a role now, but I=E2=80=99m not yet convinced that=E2=80=99s true in = practice, and I do want someone to be able to deploy this by having all = the =E2=80=9Cserver=E2=80=9D side functionalities running out of a = single, simple box. That might be a case of that single box needing to = play multiple roles, and that=E2=80=99s OK, but we need to be clear on = what kinds of optimizations are allowable in cases like that.

I do think there=E2=80=99s= precedent in asking this question though, since between OAuth 1 and 2 = we split the =E2=80=9Cserver=E2=80=9D into =E2=80=9CAS and RS=E2=80=9D. = OAuth 2 famously didn=E2=80=99t define a connection point between them = until much later (JWT and Introspection), but that pattern seems to have = mostly worked.

 =E2=80=94 Justin

On Dec = 22, 2019, at 11:52 PM, Richard Backman, Annabelle <richanna@amazon.com>= wrote:

My example = demonstrates an architecture where the TX Endpoint, authentication = system, and token issuer aren=E2=80=99t simply different micro services, = they=E2=80=99re completely independent systems in different trust boundaries, possibly have different domains and different keys. = This has implications for protocol design. For example, it would no = longer be sufficient to have a single jwks_uri, as OAuth 2.0 has.

If we want to support this kind of =E2=80=9Cdecomposed = AS=E2=80=9D model, then we need to make sure that=E2=80=99s supported by = the charter and keep it in mind as we design the protocol. We can also = decide it is out of scope, but we should be intentional about that decision.

To my mind, this role decomposition is the = next logical step after the channel decomposition that TxAuth already = does. I see a lot of potential in it and think we should at minimum = avoid closing the door on it.

On Dec 22, 2019, at 5:35 PM, Justin = Richer <jricher@mit.edu> wrote:

=EF=BB=BF I think you=E2=80=99re conflating = the roles that different components play, in = regard to the other components, with the potential deployment of those = components. The spec needs to be written in terms of the roles. While = the roles do need to consider what potential deployments might be, it=E2=80=99s = important that we write things in in terms of how they interact with = each other and not in terms of how they might look under the covers.

So from the clients perspective, the TX Endpoint :is: = the AS. The client doesn=E2=80=99t care that it=E2=80=99s a =E2=80=9Cglori= fied message queue=E2=80=9D or if it=E2=80=99s a massive server farm. = The client doesn=E2=80=99t care if there=E2=80=99s a TLS reverse proxy = or if it=E2=80=99s talking directly to the application layer. The only thing the client cares about is if the = TX Endpoint does the things that a TX Endpoint is supposed to do, and we = define that to be the function of the AS. 

What=E2=80=99s important in your scenario below is that = the client would have to talk to the RS first every time. That=E2=80=99s = one of the problems that UMA has, and I think something we should avoid. = I think RS-first is an interesting pattern but AS-first ought to drive this. 

With your hypothetical layout below, it really sounds = like the TX Endpoint is a function of the IDP, which is fine. The client = doesn=E2=80=99t care that it=E2=80=99s deployed using some externalized = cloud service. The only weird thing going on is the push from the AS back to the client. The client would need to register that with = the AS (or through the AS more specifically) as part of its transaction = request. This would be part of its interaction mechanism, because =E2=80=9C= how you get messages and updates back to the client=E2=80=9D is part of the interaction model. 

So for an RS-first transaction, the client calls the = RS:

GET /foo

The RS returns a resource handle, but the client = doesn=E2=80=99t care where that came from. The RS could talk to the AS = to get it. Probably a new endpoint of some kind, can probably use the = same kinds of key binding that the TX Endpoint has. Or the RS can make one up that the TX Endpoint can recognize. Or it calls the IdP = to get one. The client doesn=E2=80=99t care, and that=E2=80=99s the key = point. 

WWW-Authenticate tx_endpoint=3D=E2=80=9Chttp://server//tx=E2=80=9D= resource: =E2=80=9Casdf1234=E2=80=9D

The client calls the TX endpoint like a normal = transaction:

POST /tx

{
  resources: [ =E2=80=9Casdf1234=E2=80=9D ],
  interact: {
    redirect: true,
    push: =E2=80=9Chttp://client/push/9876=E2=80=9D
  }
}

The AS (which is to say the TX Endpoint) tells the = client to send the user agent to the IdP

{
  interact_url: =E2=80=9Chttp://idp/login=E2=80=9D,
  handle: { value: =E2=80=9Chjkl=E2=80=9D, type: = bearer }
}

Now the client could poll the TX Endpoint but it could = also just sit and wait for an update to be pushed in. 

There are probably things that need to be tied together = for this to be secure, but I think the basic pattern still fits. = Importantly, the client doesn=E2=80=99t care whereby of that stuff came = from =E2=80=94 as far as it=E2=80=99s concerned, it=E2=80=99s talking to = the AS. 

Remember, the =E2=80=9CAS=E2=80=9D is a logical = construct, not a physical one. Just like the =E2=80=9Cclient=E2=80=9D = could be a cluster of applications and the =E2=80=9CRS=E2=80=9D could be = a suite of APIs tied behind a gateway.

 =E2=80=94 Justin


On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle = <richanna@amazon.com> wrote:


On Dec 21, 2019, at 4:42 AM, Justin = Richer <jricher@mit.edu> wrote:

Even if the client starts at the RS, the client still = has to go talk to the AS. I haven=E2=80=99t built this out, but I see it = working somewhat like UMA. In XYZ=E2=80=99s terms:


1. Client calls the RS trying to Do A Thing
2. RS calls the AS requesting a Resource Handle (because = that=E2=80=99s what the RS represents, resources) =E2=80=94 at least = good enough to cover what the client tried to do, could be more
3. RS gives the Resource Handle and AS Transaction = Endpoint back to the client
4. Client calls the AS Transaction Endpoint to start a = transaction, includes the Resource Handle as part of its request (note: = doesn=E2=80=99t have to be the whole resource section, client can add = stuff)
5. Process continues as normal

It depends on what you consider the =E2=80=9CAS=E2=80=9D. = Consider the following hypothetical architecture:

=E2=80=A2 The RS, client, and tx endpoint are on the = public Internet.
=E2=80=A2 The tx endpoint returns interaction urls that = point to an IdP that is inaccessible from the public Internet.
=E2=80=A2 The user agent can reach the IdP, but none of = the other systems can.
=E2=80=A2 When the UA is redirected to the IdP, the IdP = calls the tx endpoint system to retrieve transaction details.
=E2=80=A2 When authorization is granted, the IdP pushes = artifacts directly to an endpoint provided by the client.

In this example, the client only interacts with the RS = and the tx endpoint. It seems odd to me to consider the system hosting = the tx endpoint to be the AS (or at least part of the AS), as its a = glorified message queue with essentially no authority in this architecture. 

We could go a step further and remove the client=E2=80=99s= interaction with the tx endpoint by having the RS return the = interaction url directly (you=E2=80=99d need to secure the client nonce = if you want to hide it from the RS, but that=E2=80=99s not that = hard).

Is the meaning of =E2=80=9Cauthorization server=E2=80=9D = (or the phrase =E2=80=9Cthrough an authorization server=E2=80=9D) = flexible enough to accommodate these cases? Or are they considered out = of scope for TxAuth?

 =E2=80=94 Justin


As I said, maybe I=E2=80=99m being too literal.

3D""=E1=90=A7
On Fri, Dec 20, 2019 at 5:08 PM = Richard Backman, Annabelle <richanna@amazon.com> wrote:

I=E2=80=99m not sure if this is what Eve had in = mind, but consider an automated system in an enterprise context that has = been authorized by an administrator. The automated system isn=E2=80=99t = acting as or on behalf of the administrator, and the administrator hasn=E2=80=99t =E2=80=9Cdelegated access=E2=80=9D; they=E2=80=99ve granted access, just as they do when they assign = permissions to users/groups/roles/etc.

Maybe I=E2=80=99m being too = literal, but =E2=80=9Cthrough an authorization server=E2=80=9D in = paragraph 1 implies a specific context/information/request flow to me. = Given that one of TxAuth=E2=80=99s features is decoupling the different = communication channels, we should not suggest that the client or authorizing party is directly = interacting with the AS.

 

=E2=80=93 

Annabelle Richard Backman

AWS Identity

 

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
Date: Friday, December 20, 2019 at 4:14 PM
To: Eve Maler <eve@xmlgrrl.com>
Cc: "rdd@cert.org" <rdd@cert.org>, "txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: [Txauth] TxAuth Proposed Charter

 

Eve: do you not think the = software client is acting on behalf of some party? Or do you think that = software always is acting on behalf of some party, and the mentioned = phrase is redundant?

 

Justin: a couple questions

 

1. What is meant by "Delegation = between multiple users" ?

 

2. Why do you restrict this to = HTTP?

 

3. Why is authentication not in = scope?

 

4. When you say "not backwards = compatible with OAuth 2.0 and its extensions", do you expect to define a = new standard to replace RFC 6750? Developers will have to have a new = method to call APIs?

 

 

On Fri, Dec 20, 2019 at 3:27 PM = Eve Maler <eve@xmlgrrl.com> wrote:

Re = =E2=80=9Cto a = software client _acting on behalf of an authorizing party_=E2=80=9D: = There is a whole lot of philosophy behind whom the delegated access is performed on = behalf of, unless the scenario is single-user or some "act as" semantic = is spelled out on the wire. Does it need to be stated here? What's the = consequence if the highlighted phrase were removed? 

Eve Maler (sent from my iPad) | cell +1 425 345 = 6756



On Dec 20, 2019, at = 4:34 PM, Justin Richer <jricher@mit.edu> wrote:

Hi all,

 

As discussed in Singapore, no = matter what forum TxAuth takes, its work will require a new charter. = With that in mind, I=E2=80=99ve taken a bit of time to put together a = proposed charter text for the TxAuth work:

 

This group is chartered to = develop a next-generation transactional authorization and delegation = protocol for HTTP-based APIs and their clients. These transactions will = allow an authorizing party to delegate a right of access for an API or set of APIs through an authorization server to a software client = acting on behalf of an authorizing party. 

 

The group will deliver a protocol = specification detailing how a client can request and obtain delegated = access, how an authorization server can provide delegated access, how an = authorized party can authorize delegated access, and how that authorized access can be communicated to the resources being protected. = These actions will be connected through an explicit transaction between = the client and authorization server, resulting in an artifact that will = allow the client to undertake the delegated action. 

 

Additionally, the delegation = process will allow for:

- Fine-grained specification of = resource access

- Delegation between multiple = users

- Web, mobile, single-page, and = other client applications

 

The group will define extension = points for this protocol to allow for flexibility in areas including:

 

- Cryptographic agility for keys, = message signatures, and proof of possession 

- User interaction mechanisms = including web and non-web methods

- Token presentation mechanisms = and key bindings

 

The artifacts for this work are = not intended or expected to be backwards-compatible with OAuth 2.0 and = its extensions. 

 

While this work could be done in = within the OAuth working group, I now believe that it should be done in = a new working group, and that we should try to get that working group up = and running prior to the Vancouver meeting in March.. I think this group should stay here on the TxAuth list, and it=E2=80=99s my = suggestion that the resulting work be called OAuth 3.0. 

 

Why a new group? I think that the = OAuth working group should remain focused on extending, patching, and = adapting OAuth 2.0 to a changing world. I plan to be engaged in both = groups, and I know most of you are as well, but that=E2=80=99s not = universal. Since OAuth 2.0 is so established already, there are a LOT of people = who aren=E2=80=99t going to be interested in something new any time = soon. But on the other hand, there are a number of people for whom OAuth = 2.0 does not work, or is at the very least a poor fit, and we=E2=80=99ll want to bring them in at this early stage. So even = with significant overlap, I think there=E2=80=99s enough disconnect in = the community from both sides that warrants a new group. In addition, I = think this is a big enough piece of work that it=E2=80=99s simply too much for the OAuth working group to be able to focus on. We wouldn=E2=80=99= t be able to get additional meeting time, and OAuth already has trouble = fitting into its two meeting slots as it is.

 

I=E2=80=99ve published a blog = post detailing more of my rationale:

 

https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a= -new-working-group-d6229ba8e36?

 

Please suggest changes to the = proposed charter text above. It=E2=80=99s my hope that we can get the = chartering process started.

 

 =E2=80=94 Justin

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth




= --Apple-Mail=_533DC25D-610D-4EB1-92C9-5AC6AC3D9E53-- From nobody Mon Dec 23 15:22:56 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BD0120D1E for ; Mon, 23 Dec 2019 15:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.399 X-Spam-Level: X-Spam-Status: No, score=-14.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 y4bYe5WGnoa8 for ; Mon, 23 Dec 2019 15:22:52 -0800 (PST) Received: from smtp-fw-9101.amazon.com (smtp-fw-9101.amazon.com [207.171.184.25]) (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 E77EB12002F for ; Mon, 23 Dec 2019 15:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1577143372; x=1608679372; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Q20zUsRUhg97ke19337vkfS2LvFFXQPT2mcE22RZGwY=; b=YlSow5XQBLbtm6XUPITSdzvTAeLIMsGxX8GV1qzQDB/YIDLGaT53H8lZ zEhuvsTjxcrlNi/VwdkU3SmE7wG/7daBtnUrts9+RPgR1CWj9/6/9jUux h6aeJd6LGwp/+w0WgQR2qEB1yUGh7KcyZZU4TK8Mu5df5eE8GXHQgqyvM w=; IronPort-SDR: 7BF+qH/+0TW7NGF0e5PivXmkbK2oDK0Rs3nHTmlj3/JQY84prODAC+ieF+Bbx0x/zCGcPgO5eM H87jlEHaai5A== X-IronPort-AV: E=Sophos;i="5.69,349,1571702400"; d="scan'208,217";a="6876137" Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-2c-397e131e.us-west-2.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-9101.sea19.amazon.com with ESMTP; 23 Dec 2019 23:22:41 +0000 Received: from EX13MTAUWC001.ant.amazon.com (pdx4-ws-svc-p6-lb7-vlan3.pdx.amazon.com [10.170.41.166]) by email-inbound-relay-2c-397e131e.us-west-2.amazon.com (Postfix) with ESMTPS id 46B37A220D; Mon, 23 Dec 2019 23:22:40 +0000 (UTC) Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 23 Dec 2019 23:22:39 +0000 Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC004.ant.amazon.com (10.43.162.101) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 23 Dec 2019 23:22:39 +0000 Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Mon, 23 Dec 2019 23:22:39 +0000 From: "Richard Backman, Annabelle" To: Justin Richer CC: Dick Hardt , Eve Maler , "rdd@cert.org" , "txauth@ietf.org" , "Benjamin Kaduk" Thread-Topic: [Txauth] TxAuth Proposed Charter Thread-Index: AQHVt4W+Cd5+sniY+0u9RUqE6+8fD6fDqwuAgAAMvQD//4lSAIAAjYeAgABdgjyAAFyWAIABI/3hgAFGlACAADdN4YABHkoA//+RsQA= Date: Mon, 23 Dec 2019 23:22:39 +0000 Message-ID: <684F4469-031B-4AB9-8B53-A87597AE012E@amazon.com> References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> <949341AE-C72B-4645-8F20-699F14529FFB@mit.edu> <78FA3EB7-C72F-4543-95A8-03123F4E40A1@amazon.com> <1FD41975-3CB5-48B6-88D5-6DB7511742CA@mit.edu> In-Reply-To: <1FD41975-3CB5-48B6-88D5-6DB7511742CA@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.43.160.155] Content-Type: multipart/alternative; boundary="_000_684F4469031B4AB98B53A87597AE012Eamazoncom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2019 23:22:55 -0000 --_000_684F4469031B4AB98B53A87597AE012Eamazoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHBvaW50IGlzLCBJIG1pZ2h0IHdhbnQgbXkgdG9rZW5zIHRvIGJlIHNpZ25lZCB1c2luZyBr ZXlzIHRoYXQgbXkgVFggRW5kcG9pbnQgZG9lcyBub3QgaGF2ZSBhY2Nlc3MgdG8uIEUuZy4sIG15 IHRva2VuIGlzc3VlciBzaWducyB0b2tlbnMgd2l0aCBrZXkgQSBhbmQgbXkgVFggRW5kcG9pbnQg c2lnbnMgSFRUUCByZXNwb25zZSBtZXNzYWdlcyB3aXRoIGtleSBCLCBuZWl0aGVyIHN5c3RlbSBo YXMgYWNjZXNzIHRvIHRoZSBvdGhlciBrZXksIGFuZCB0b2tlbnMgc2lnbmVkIGJ5IGtleSBCIGFy ZSByZWplY3RlZCBieSBSU2VzLiBUaGlzIHJlcXVpcmVzIHRoZSB3b3JraW5nIGdyb3VwIHRvIHVu ZGVyc3RhbmQgdGhhdCB0cnVzdCBib3VuZGFyaWVzIG1heSBleGlzdCBiZXR3ZWVuIHRoZSBkaWZm ZXJlbnQgY29tcG9uZW50cyBpbXBsZW1lbnRpbmcgcG9ydGlvbnMgb2Yg4oCcQVPigJ0gYmVoYXZp b3IuIElmIHRoaXMgaXNu4oCZdCB1bmRlcnN0b29kLCB0aGVuIGlmL3doZW4gSSBicmluZyB1cCB0 aGlzIHVzZSBjYXNlLCBJ4oCZbSBnb2luZyB0byBiZSB0b2xkIOKAnHRoZXJlIGFyZSBubyB0cnVz dCBib3VuZGFyaWVzIHdpdGhpbiBhbiBBUywgc28gd2hhdCB5b3XigJlyZSBkZXNjcmliaW5nIGlz buKAmXQgYW4gQVMgYW55bW9yZSwgYW5kIG5vdCBpbiBzY29wZSBwZXIgdGhlIGNoYXJ0ZXIu4oCd DQoNCknigJltIHNlbnNpdGl2ZSB0byB0aGUgZGVzaXJlIHRvIG5vdCBvdmVyY29tcGxpY2F0ZSB0 aGluZ3MuIFRoZSBzY2VuYXJpbyBJ4oCZbSBkZXNjcmliaW5nIGlzIHVudXN1YWwsIGFuZCBwcm9i YWJseSBub3Qgd2hhdCB3ZSBzaG91bGQgb3B0aW1pemUgdGhlIHByb3RvY29sIGZvciAodGhvdWdo IHRoYXQgY291bGQgYWx3YXlzIGNoYW5nZSkuIEJ1dCB3ZeKAmXJlIHRhbGtpbmcgYWJvdXQgY2hh cnRlciwgbm90IHByb3RvY29sLiBUaGUgY2hhcnRlciBjYW4gYmUgYXMgZGV0YWlsZWQgYW5kIG51 YW5jZWQgYXMgaXQgbmVlZHMgdG8gYmUgdG8gcHJvcGVybHkgZGVzY3JpYmUgd2hhdCB3ZSBhcmUg c2V0dGluZyBvdXQgdG8gYWNjb21wbGlzaC4NCg0K4oCTDQpBbm5hYmVsbGUgUmljaGFyZCBCYWNr bWFuDQpBV1MgSWRlbnRpdHkNCg0KDQpGcm9tOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5l ZHU+DQpEYXRlOiBNb25kYXksIERlY2VtYmVyIDIzLCAyMDE5IGF0IDE6NTcgUE0NClRvOiAiUmlj aGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUiIDxyaWNoYW5uYUBhbWF6b24uY29tPg0KQ2M6IERpY2sg SGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPiwgRXZlIE1hbGVyIDxldmVAeG1sZ3JybC5jb20+ LCAicmRkQGNlcnQub3JnIiA8cmRkQGNlcnQub3JnPiwgInR4YXV0aEBpZXRmLm9yZyIgPHR4YXV0 aEBpZXRmLm9yZz4sIEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1Pg0KU3ViamVjdDogUmU6 IFtUeGF1dGhdIFR4QXV0aCBQcm9wb3NlZCBDaGFydGVyDQoNClNvIHRoZSB0aGluZyBpcywgSSBk b27igJl0IHRoaW5rIHlvdSBuZWVkIGEgc2luZ2xlIEpXS1MgVVJJIGFueW1vcmUgYW55d2F5LiBZ b3XigJlkIGhhdmUgb25lIGFzc29jaWF0ZWQgd2l0aCB0aGUgVHhFbmRwb2ludCwgaWYgeW914oCZ dmUgZ290IHNpZ25lZCB0b2tlbnMgdGhhdCB5b3UgbmVlZCB0byB2YWxpZGF0ZSBzZXBhcmF0ZWx5 LiBBbmQgaWYgeW914oCZcmUgZG9pbmcgc2lnbmVkIHVzZXIgYXNzZXJ0aW9ucywgeW914oCZZCBo YXZlIGEgZGlmZmVyZW50IG9uZSBpZGVudGlmaWVkIGluIHRoZSBhc3NlcnRpb24gKGVpdGhlciBk aXJlY3RseSBvciB2aWEgYW4gaXNzdWVyLWRpc2NvdmVyeSBtZWNoYW5pc20pLiBVbHRpbWF0ZWx5 IHRoZSBjbGllbnQgaXMgZ29pbmcgdG8gY2FyZSBhYm91dCBvbmUgYW5kIHRoZSBSUyBhYm91dCBh bm90aGVyIHNvIGl04oCZcyBmaW5lIHRoYXQgdGhleeKAmXJlIGRpZmZlcmVudC4gV2UgZ2V0IHRv IGRlZmluZSB3aGF0IHRoYXQgbG9va3MgbGlrZS4NCg0KT24gdGhlIHN1cmZhY2UgSeKAmW0gT0sg d2l0aCBhIGRlY29tcG9zZWQgQVMsIHRvIHNvbWUgZXh0ZW50LCBidXQgb25seSBpZiB0aGVyZSBh cmUgdmVyeSwgdmVyeSBjbGVhciBib3VuZGFyaWVzIGFib3V0IHdoYXQgdGhlIGluZGl2aWR1YWwg cm9sZXMgYXJlLiBBbmQgdGhlIG1vcmUgcm9sZXMgd2UgbWFrZSwgdGhlIG1vcmUgd2UgaGF2ZSB0 byBkZWZpbmUgd2hhdCB0aGUgY29tbXVuaWNhdGlvbiBwb2ludHMgYXJlIGluIGJldHdlZW4gdGhl bS4gTWF5YmUg4oCcQVPigJ0gaXMgdG9vIGFsbC1lbmNvbXBhc3Npbmcgb2YgYSByb2xlIG5vdywg YnV0IEnigJltIG5vdCB5ZXQgY29udmluY2VkIHRoYXTigJlzIHRydWUgaW4gcHJhY3RpY2UsIGFu ZCBJIGRvIHdhbnQgc29tZW9uZSB0byBiZSBhYmxlIHRvIGRlcGxveSB0aGlzIGJ5IGhhdmluZyBh bGwgdGhlIOKAnHNlcnZlcuKAnSBzaWRlIGZ1bmN0aW9uYWxpdGllcyBydW5uaW5nIG91dCBvZiBh IHNpbmdsZSwgc2ltcGxlIGJveC4gVGhhdCBtaWdodCBiZSBhIGNhc2Ugb2YgdGhhdCBzaW5nbGUg Ym94IG5lZWRpbmcgdG8gcGxheSBtdWx0aXBsZSByb2xlcywgYW5kIHRoYXTigJlzIE9LLCBidXQg d2UgbmVlZCB0byBiZSBjbGVhciBvbiB3aGF0IGtpbmRzIG9mIG9wdGltaXphdGlvbnMgYXJlIGFs bG93YWJsZSBpbiBjYXNlcyBsaWtlIHRoYXQuDQoNCkkgZG8gdGhpbmsgdGhlcmXigJlzIHByZWNl ZGVudCBpbiBhc2tpbmcgdGhpcyBxdWVzdGlvbiB0aG91Z2gsIHNpbmNlIGJldHdlZW4gT0F1dGgg MSBhbmQgMiB3ZSBzcGxpdCB0aGUg4oCcc2VydmVy4oCdIGludG8g4oCcQVMgYW5kIFJT4oCdLiBP QXV0aCAyIGZhbW91c2x5IGRpZG7igJl0IGRlZmluZSBhIGNvbm5lY3Rpb24gcG9pbnQgYmV0d2Vl biB0aGVtIHVudGlsIG11Y2ggbGF0ZXIgKEpXVCBhbmQgSW50cm9zcGVjdGlvbiksIGJ1dCB0aGF0 IHBhdHRlcm4gc2VlbXMgdG8gaGF2ZSBtb3N0bHkgd29ya2VkLg0KDQog4oCUIEp1c3Rpbg0KDQoN Ck9uIERlYyAyMiwgMjAxOSwgYXQgMTE6NTIgUE0sIFJpY2hhcmQgQmFja21hbiwgQW5uYWJlbGxl IDxyaWNoYW5uYUBhbWF6b24uY29tPG1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tPj4gd3JvdGU6 DQoNCk15IGV4YW1wbGUgZGVtb25zdHJhdGVzIGFuIGFyY2hpdGVjdHVyZSB3aGVyZSB0aGUgVFgg RW5kcG9pbnQsIGF1dGhlbnRpY2F0aW9uIHN5c3RlbSwgYW5kIHRva2VuIGlzc3VlciBhcmVu4oCZ dCBzaW1wbHkgZGlmZmVyZW50IG1pY3JvIHNlcnZpY2VzLCB0aGV54oCZcmUgY29tcGxldGVseSBp bmRlcGVuZGVudCBzeXN0ZW1zIGluIGRpZmZlcmVudCB0cnVzdCBib3VuZGFyaWVzLCBwb3NzaWJs eSBoYXZlIGRpZmZlcmVudCBkb21haW5zIGFuZCBkaWZmZXJlbnQga2V5cy4gVGhpcyBoYXMgaW1w bGljYXRpb25zIGZvciBwcm90b2NvbCBkZXNpZ24uIEZvciBleGFtcGxlLCBpdCB3b3VsZCBubyBs b25nZXIgYmUgc3VmZmljaWVudCB0byBoYXZlIGEgc2luZ2xlIGp3a3NfdXJpLCBhcyBPQXV0aCAy LjAgaGFzLg0KDQoNCklmIHdlIHdhbnQgdG8gc3VwcG9ydCB0aGlzIGtpbmQgb2Yg4oCcZGVjb21w b3NlZCBBU+KAnSBtb2RlbCwgdGhlbiB3ZSBuZWVkIHRvIG1ha2Ugc3VyZSB0aGF04oCZcyBzdXBw b3J0ZWQgYnkgdGhlIGNoYXJ0ZXIgYW5kIGtlZXAgaXQgaW4gbWluZCBhcyB3ZSBkZXNpZ24gdGhl IHByb3RvY29sLiBXZSBjYW4gYWxzbyBkZWNpZGUgaXQgaXMgb3V0IG9mIHNjb3BlLCBidXQgd2Ug c2hvdWxkIGJlIGludGVudGlvbmFsIGFib3V0IHRoYXQgZGVjaXNpb24uDQoNCg0KVG8gbXkgbWlu ZCwgdGhpcyByb2xlIGRlY29tcG9zaXRpb24gaXMgdGhlIG5leHQgbG9naWNhbCBzdGVwIGFmdGVy IHRoZSBjaGFubmVsIGRlY29tcG9zaXRpb24gdGhhdCBUeEF1dGggYWxyZWFkeSBkb2VzLiBJIHNl ZSBhIGxvdCBvZiBwb3RlbnRpYWwgaW4gaXQgYW5kIHRoaW5rIHdlIHNob3VsZCBhdCBtaW5pbXVt IGF2b2lkIGNsb3NpbmcgdGhlIGRvb3Igb24gaXQuDQoNCg0KT24gRGVjIDIyLCAyMDE5LCBhdCA1 OjM1IFBNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0 LmVkdT4+IHdyb3RlOg0KSSB0aGluayB5b3XigJlyZSBjb25mbGF0aW5nIHRoZSByb2xlcyB0aGF0 IGRpZmZlcmVudCBjb21wb25lbnRzIHBsYXksIGluIHJlZ2FyZCB0byB0aGUgb3RoZXIgY29tcG9u ZW50cywgd2l0aCB0aGUgcG90ZW50aWFsIGRlcGxveW1lbnQgb2YgdGhvc2UgY29tcG9uZW50cy4g VGhlIHNwZWMgbmVlZHMgdG8gYmUgd3JpdHRlbiBpbiB0ZXJtcyBvZiB0aGUgcm9sZXMuIFdoaWxl IHRoZSByb2xlcyBkbyBuZWVkIHRvIGNvbnNpZGVyIHdoYXQgcG90ZW50aWFsIGRlcGxveW1lbnRz IG1pZ2h0IGJlLCBpdOKAmXMgaW1wb3J0YW50IHRoYXQgd2Ugd3JpdGUgdGhpbmdzIGluIGluIHRl cm1zIG9mIGhvdyB0aGV5IGludGVyYWN0IHdpdGggZWFjaCBvdGhlciBhbmQgbm90IGluIHRlcm1z IG9mIGhvdyB0aGV5IG1pZ2h0IGxvb2sgdW5kZXIgdGhlIGNvdmVycy4NCg0KU28gZnJvbSB0aGUg Y2xpZW50cyBwZXJzcGVjdGl2ZSwgdGhlIFRYIEVuZHBvaW50IDppczogdGhlIEFTLiBUaGUgY2xp ZW50IGRvZXNu4oCZdCBjYXJlIHRoYXQgaXTigJlzIGEg4oCcZ2xvcmlmaWVkIG1lc3NhZ2UgcXVl dWXigJ0gb3IgaWYgaXTigJlzIGEgbWFzc2l2ZSBzZXJ2ZXIgZmFybS4gVGhlIGNsaWVudCBkb2Vz buKAmXQgY2FyZSBpZiB0aGVyZeKAmXMgYSBUTFMgcmV2ZXJzZSBwcm94eSBvciBpZiBpdOKAmXMg dGFsa2luZyBkaXJlY3RseSB0byB0aGUgYXBwbGljYXRpb24gbGF5ZXIuIFRoZSBvbmx5IHRoaW5n IHRoZSBjbGllbnQgY2FyZXMgYWJvdXQgaXMgaWYgdGhlIFRYIEVuZHBvaW50IGRvZXMgdGhlIHRo aW5ncyB0aGF0IGEgVFggRW5kcG9pbnQgaXMgc3VwcG9zZWQgdG8gZG8sIGFuZCB3ZSBkZWZpbmUg dGhhdCB0byBiZSB0aGUgZnVuY3Rpb24gb2YgdGhlIEFTLg0KDQpXaGF04oCZcyBpbXBvcnRhbnQg aW4geW91ciBzY2VuYXJpbyBiZWxvdyBpcyB0aGF0IHRoZSBjbGllbnQgd291bGQgaGF2ZSB0byB0 YWxrIHRvIHRoZSBSUyBmaXJzdCBldmVyeSB0aW1lLiBUaGF04oCZcyBvbmUgb2YgdGhlIHByb2Js ZW1zIHRoYXQgVU1BIGhhcywgYW5kIEkgdGhpbmsgc29tZXRoaW5nIHdlIHNob3VsZCBhdm9pZC4g SSB0aGluayBSUy1maXJzdCBpcyBhbiBpbnRlcmVzdGluZyBwYXR0ZXJuIGJ1dCBBUy1maXJzdCBv dWdodCB0byBkcml2ZSB0aGlzLg0KDQpXaXRoIHlvdXIgaHlwb3RoZXRpY2FsIGxheW91dCBiZWxv dywgaXQgcmVhbGx5IHNvdW5kcyBsaWtlIHRoZSBUWCBFbmRwb2ludCBpcyBhIGZ1bmN0aW9uIG9m IHRoZSBJRFAsIHdoaWNoIGlzIGZpbmUuIFRoZSBjbGllbnQgZG9lc27igJl0IGNhcmUgdGhhdCBp dOKAmXMgZGVwbG95ZWQgdXNpbmcgc29tZSBleHRlcm5hbGl6ZWQgY2xvdWQgc2VydmljZS4gVGhl IG9ubHkgd2VpcmQgdGhpbmcgZ29pbmcgb24gaXMgdGhlIHB1c2ggZnJvbSB0aGUgQVMgYmFjayB0 byB0aGUgY2xpZW50LiBUaGUgY2xpZW50IHdvdWxkIG5lZWQgdG8gcmVnaXN0ZXIgdGhhdCB3aXRo IHRoZSBBUyAob3IgdGhyb3VnaCB0aGUgQVMgbW9yZSBzcGVjaWZpY2FsbHkpIGFzIHBhcnQgb2Yg aXRzIHRyYW5zYWN0aW9uIHJlcXVlc3QuIFRoaXMgd291bGQgYmUgcGFydCBvZiBpdHMgaW50ZXJh Y3Rpb24gbWVjaGFuaXNtLCBiZWNhdXNlIOKAnGhvdyB5b3UgZ2V0IG1lc3NhZ2VzIGFuZCB1cGRh dGVzIGJhY2sgdG8gdGhlIGNsaWVudOKAnSBpcyBwYXJ0IG9mIHRoZSBpbnRlcmFjdGlvbiBtb2Rl bC4NCg0KU28gZm9yIGFuIFJTLWZpcnN0IHRyYW5zYWN0aW9uLCB0aGUgY2xpZW50IGNhbGxzIHRo ZSBSUzoNCg0KR0VUIC9mb28NCg0KVGhlIFJTIHJldHVybnMgYSByZXNvdXJjZSBoYW5kbGUsIGJ1 dCB0aGUgY2xpZW50IGRvZXNu4oCZdCBjYXJlIHdoZXJlIHRoYXQgY2FtZSBmcm9tLiBUaGUgUlMg Y291bGQgdGFsayB0byB0aGUgQVMgdG8gZ2V0IGl0LiBQcm9iYWJseSBhIG5ldyBlbmRwb2ludCBv ZiBzb21lIGtpbmQsIGNhbiBwcm9iYWJseSB1c2UgdGhlIHNhbWUga2luZHMgb2Yga2V5IGJpbmRp bmcgdGhhdCB0aGUgVFggRW5kcG9pbnQgaGFzLiBPciB0aGUgUlMgY2FuIG1ha2Ugb25lIHVwIHRo YXQgdGhlIFRYIEVuZHBvaW50IGNhbiByZWNvZ25pemUuIE9yIGl0IGNhbGxzIHRoZSBJZFAgdG8g Z2V0IG9uZS4gVGhlIGNsaWVudCBkb2VzbuKAmXQgY2FyZSwgYW5kIHRoYXTigJlzIHRoZSBrZXkg cG9pbnQuDQoNCldXVy1BdXRoZW50aWNhdGUgdHhfZW5kcG9pbnQ94oCcaHR0cDovL3NlcnZlci8v dHg8aHR0cDovL3NlcnZlciVFRiVCRiVCRC90eD7igJ0gcmVzb3VyY2U6IOKAnGFzZGYxMjM04oCd DQoNClRoZSBjbGllbnQgY2FsbHMgdGhlIFRYIGVuZHBvaW50IGxpa2UgYSBub3JtYWwgdHJhbnNh Y3Rpb246DQoNClBPU1QgL3R4DQoNCnsNCiAgcmVzb3VyY2VzOiBbIOKAnGFzZGYxMjM04oCdIF0s DQogIGludGVyYWN0OiB7DQogICAgcmVkaXJlY3Q6IHRydWUsDQogICAgcHVzaDog4oCcaHR0cDov L2NsaWVudC9wdXNoLzk4NzbigJ0NCiAgfQ0KfQ0KDQpUaGUgQVMgKHdoaWNoIGlzIHRvIHNheSB0 aGUgVFggRW5kcG9pbnQpIHRlbGxzIHRoZSBjbGllbnQgdG8gc2VuZCB0aGUgdXNlciBhZ2VudCB0 byB0aGUgSWRQDQoNCnsNCiAgaW50ZXJhY3RfdXJsOiDigJxodHRwOi8vaWRwL2xvZ2lu4oCdLA0K ICBoYW5kbGU6IHsgdmFsdWU6IOKAnGhqa2zigJ0sIHR5cGU6IGJlYXJlciB9DQp9DQoNCk5vdyB0 aGUgY2xpZW50IGNvdWxkIHBvbGwgdGhlIFRYIEVuZHBvaW50IGJ1dCBpdCBjb3VsZCBhbHNvIGp1 c3Qgc2l0IGFuZCB3YWl0IGZvciBhbiB1cGRhdGUgdG8gYmUgcHVzaGVkIGluLg0KDQpUaGVyZSBh cmUgcHJvYmFibHkgdGhpbmdzIHRoYXQgbmVlZCB0byBiZSB0aWVkIHRvZ2V0aGVyIGZvciB0aGlz IHRvIGJlIHNlY3VyZSwgYnV0IEkgdGhpbmsgdGhlIGJhc2ljIHBhdHRlcm4gc3RpbGwgZml0cy4g SW1wb3J0YW50bHksIHRoZSBjbGllbnQgZG9lc27igJl0IGNhcmUgd2hlcmVieSBvZiB0aGF0IHN0 dWZmIGNhbWUgZnJvbSDigJQgYXMgZmFyIGFzIGl04oCZcyBjb25jZXJuZWQsIGl04oCZcyB0YWxr aW5nIHRvIHRoZSBBUy4NCg0KUmVtZW1iZXIsIHRoZSDigJxBU+KAnSBpcyBhIGxvZ2ljYWwgY29u c3RydWN0LCBub3QgYSBwaHlzaWNhbCBvbmUuIEp1c3QgbGlrZSB0aGUg4oCcY2xpZW504oCdIGNv dWxkIGJlIGEgY2x1c3RlciBvZiBhcHBsaWNhdGlvbnMgYW5kIHRoZSDigJxSU+KAnSBjb3VsZCBi ZSBhIHN1aXRlIG9mIEFQSXMgdGllZCBiZWhpbmQgYSBnYXRld2F5Lg0KDQog4oCUIEp1c3Rpbg0K DQoNCg0KT24gRGVjIDIyLCAyMDE5LCBhdCAxOjA1IEFNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFi ZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86cmljaGFubmFAYW1hem9uLmNvbT4+IHdy b3RlOg0KDQoNCk9uIERlYyAyMSwgMjAxOSwgYXQgNDo0MiBBTSwgSnVzdGluIFJpY2hlciA8anJp Y2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCg0KRXZlbiBpZiB0 aGUgY2xpZW50IHN0YXJ0cyBhdCB0aGUgUlMsIHRoZSBjbGllbnQgc3RpbGwgaGFzIHRvIGdvIHRh bGsgdG8gdGhlIEFTLiBJIGhhdmVu4oCZdCBidWlsdCB0aGlzIG91dCwgYnV0IEkgc2VlIGl0IHdv cmtpbmcgc29tZXdoYXQgbGlrZSBVTUEuIEluIFhZWuKAmXMgdGVybXM6DQoNCg0KMS4gQ2xpZW50 IGNhbGxzIHRoZSBSUyB0cnlpbmcgdG8gRG8gQSBUaGluZw0KMi4gUlMgY2FsbHMgdGhlIEFTIHJl cXVlc3RpbmcgYSBSZXNvdXJjZSBIYW5kbGUgKGJlY2F1c2UgdGhhdOKAmXMgd2hhdCB0aGUgUlMg cmVwcmVzZW50cywgcmVzb3VyY2VzKSDigJQgYXQgbGVhc3QgZ29vZCBlbm91Z2ggdG8gY292ZXIg d2hhdCB0aGUgY2xpZW50IHRyaWVkIHRvIGRvLCBjb3VsZCBiZSBtb3JlDQozLiBSUyBnaXZlcyB0 aGUgUmVzb3VyY2UgSGFuZGxlIGFuZCBBUyBUcmFuc2FjdGlvbiBFbmRwb2ludCBiYWNrIHRvIHRo ZSBjbGllbnQNCjQuIENsaWVudCBjYWxscyB0aGUgQVMgVHJhbnNhY3Rpb24gRW5kcG9pbnQgdG8g c3RhcnQgYSB0cmFuc2FjdGlvbiwgaW5jbHVkZXMgdGhlIFJlc291cmNlIEhhbmRsZSBhcyBwYXJ0 IG9mIGl0cyByZXF1ZXN0IChub3RlOiBkb2VzbuKAmXQgaGF2ZSB0byBiZSB0aGUgd2hvbGUgcmVz b3VyY2Ugc2VjdGlvbiwgY2xpZW50IGNhbiBhZGQgc3R1ZmYpDQo1LiBQcm9jZXNzIGNvbnRpbnVl cyBhcyBub3JtYWwNCg0KSXQgZGVwZW5kcyBvbiB3aGF0IHlvdSBjb25zaWRlciB0aGUg4oCcQVPi gJ0uIENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgaHlwb3RoZXRpY2FsIGFyY2hpdGVjdHVyZToNCg0K 4oCiIFRoZSBSUywgY2xpZW50LCBhbmQgdHggZW5kcG9pbnQgYXJlIG9uIHRoZSBwdWJsaWMgSW50 ZXJuZXQuDQrigKIgVGhlIHR4IGVuZHBvaW50IHJldHVybnMgaW50ZXJhY3Rpb24gdXJscyB0aGF0 IHBvaW50IHRvIGFuIElkUCB0aGF0IGlzIGluYWNjZXNzaWJsZSBmcm9tIHRoZSBwdWJsaWMgSW50 ZXJuZXQuDQrigKIgVGhlIHVzZXIgYWdlbnQgY2FuIHJlYWNoIHRoZSBJZFAsIGJ1dCBub25lIG9m IHRoZSBvdGhlciBzeXN0ZW1zIGNhbi4NCuKAoiBXaGVuIHRoZSBVQSBpcyByZWRpcmVjdGVkIHRv IHRoZSBJZFAsIHRoZSBJZFAgY2FsbHMgdGhlIHR4IGVuZHBvaW50IHN5c3RlbSB0byByZXRyaWV2 ZSB0cmFuc2FjdGlvbiBkZXRhaWxzLg0K4oCiIFdoZW4gYXV0aG9yaXphdGlvbiBpcyBncmFudGVk LCB0aGUgSWRQIHB1c2hlcyBhcnRpZmFjdHMgZGlyZWN0bHkgdG8gYW4gZW5kcG9pbnQgcHJvdmlk ZWQgYnkgdGhlIGNsaWVudC4NCg0KSW4gdGhpcyBleGFtcGxlLCB0aGUgY2xpZW50IG9ubHkgaW50 ZXJhY3RzIHdpdGggdGhlIFJTIGFuZCB0aGUgdHggZW5kcG9pbnQuIEl0IHNlZW1zIG9kZCB0byBt ZSB0byBjb25zaWRlciB0aGUgc3lzdGVtIGhvc3RpbmcgdGhlIHR4IGVuZHBvaW50IHRvIGJlIHRo ZSBBUyAob3IgYXQgbGVhc3QgcGFydCBvZiB0aGUgQVMpLCBhcyBpdHMgYSBnbG9yaWZpZWQgbWVz c2FnZSBxdWV1ZSB3aXRoIGVzc2VudGlhbGx5IG5vIGF1dGhvcml0eSBpbiB0aGlzIGFyY2hpdGVj dHVyZS4NCg0KV2UgY291bGQgZ28gYSBzdGVwIGZ1cnRoZXIgYW5kIHJlbW92ZSB0aGUgY2xpZW50 4oCZcyBpbnRlcmFjdGlvbiB3aXRoIHRoZSB0eCBlbmRwb2ludCBieSBoYXZpbmcgdGhlIFJTIHJl dHVybiB0aGUgaW50ZXJhY3Rpb24gdXJsIGRpcmVjdGx5ICh5b3XigJlkIG5lZWQgdG8gc2VjdXJl IHRoZSBjbGllbnQgbm9uY2UgaWYgeW91IHdhbnQgdG8gaGlkZSBpdCBmcm9tIHRoZSBSUywgYnV0 IHRoYXTigJlzIG5vdCB0aGF0IGhhcmQpLg0KDQpJcyB0aGUgbWVhbmluZyBvZiDigJxhdXRob3Jp emF0aW9uIHNlcnZlcuKAnSAob3IgdGhlIHBocmFzZSDigJx0aHJvdWdoIGFuIGF1dGhvcml6YXRp b24gc2VydmVy4oCdKSBmbGV4aWJsZSBlbm91Z2ggdG8gYWNjb21tb2RhdGUgdGhlc2UgY2FzZXM/ IE9yIGFyZSB0aGV5IGNvbnNpZGVyZWQgb3V0IG9mIHNjb3BlIGZvciBUeEF1dGg/DQoNCiDigJQg SnVzdGluDQoNCg0KDQpBcyBJIHNhaWQsIG1heWJlIEnigJltIGJlaW5nIHRvbyBsaXRlcmFsLg0K DQoNCltodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhK a2RFQm5iV0ZwYkM1amIyMCUzRCZ0eXBlPXplcm9jb250ZW50Jmd1aWQ9ODExMjdhOWQtMDY0MS00 MjNjLWJlNzctODEyMDcwMjQxMTAzXeGQpw0KT24gRnJpLCBEZWMgMjAsIDIwMTkgYXQgNTowOCBQ TSBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSA8cmljaGFubmFAYW1hem9uLmNvbTxtYWlsdG86 cmljaGFubmFAYW1hem9uLmNvbT4+IHdyb3RlOg0KSeKAmW0gbm90IHN1cmUgaWYgdGhpcyBpcyB3 aGF0IEV2ZSBoYWQgaW4gbWluZCwgYnV0IGNvbnNpZGVyIGFuIGF1dG9tYXRlZCBzeXN0ZW0gaW4g YW4gZW50ZXJwcmlzZSBjb250ZXh0IHRoYXQgaGFzIGJlZW4gYXV0aG9yaXplZCBieSBhbiBhZG1p bmlzdHJhdG9yLiBUaGUgYXV0b21hdGVkIHN5c3RlbSBpc27igJl0IGFjdGluZyBhcyBvciBvbiBi ZWhhbGYgb2YgdGhlIGFkbWluaXN0cmF0b3IsIGFuZCB0aGUgYWRtaW5pc3RyYXRvciBoYXNu4oCZ dCDigJxkZWxlZ2F0ZWQgYWNjZXNz4oCdOyB0aGV54oCZdmUgZ3JhbnRlZCBhY2Nlc3MsIGp1c3Qg YXMgdGhleSBkbyB3aGVuIHRoZXkgYXNzaWduIHBlcm1pc3Npb25zIHRvIHVzZXJzL2dyb3Vwcy9y b2xlcy9ldGMuDQpNYXliZSBJ4oCZbSBiZWluZyB0b28gbGl0ZXJhbCwgYnV0IOKAnHRocm91Z2gg YW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJ0gaW4gcGFyYWdyYXBoIDEgaW1wbGllcyBhIHNwZWNp ZmljIGNvbnRleHQvaW5mb3JtYXRpb24vcmVxdWVzdCBmbG93IHRvIG1lLiBHaXZlbiB0aGF0IG9u ZSBvZiBUeEF1dGjigJlzIGZlYXR1cmVzIGlzIGRlY291cGxpbmcgdGhlIGRpZmZlcmVudCBjb21t dW5pY2F0aW9uIGNoYW5uZWxzLCB3ZSBzaG91bGQgbm90IHN1Z2dlc3QgdGhhdCB0aGUgY2xpZW50 IG9yIGF1dGhvcml6aW5nIHBhcnR5IGlzIGRpcmVjdGx5IGludGVyYWN0aW5nIHdpdGggdGhlIEFT Lg0KDQrigJMNCkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW4NCkFXUyBJZGVudGl0eQ0KDQoNCkZy b206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aC1ib3VuY2Vz QGlldGYub3JnPj4gb24gYmVoYWxmIG9mIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29t PG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4+DQpEYXRlOiBGcmlkYXksIERlY2VtYmVyIDIw LCAyMDE5IGF0IDQ6MTQgUE0NClRvOiBFdmUgTWFsZXIgPGV2ZUB4bWxncnJsLmNvbTxtYWlsdG86 ZXZlQHhtbGdycmwuY29tPj4NCkNjOiAicmRkQGNlcnQub3JnPG1haWx0bzpyZGRAY2VydC5vcmc+ IiA8cmRkQGNlcnQub3JnPG1haWx0bzpyZGRAY2VydC5vcmc+PiwgInR4YXV0aEBpZXRmLm9yZzxt YWlsdG86dHhhdXRoQGlldGYub3JnPiIgPHR4YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGll dGYub3JnPj4sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBt aXQuZWR1Pj4sIEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1PG1haWx0bzprYWR1a0BtaXQu ZWR1Pj4NClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBUeEF1dGggUHJvcG9zZWQgQ2hhcnRlcg0KDQpF dmU6IGRvIHlvdSBub3QgdGhpbmsgdGhlIHNvZnR3YXJlIGNsaWVudCBpcyBhY3Rpbmcgb24gYmVo YWxmIG9mIHNvbWUgcGFydHk/IE9yIGRvIHlvdSB0aGluayB0aGF0IHNvZnR3YXJlIGFsd2F5cyBp cyBhY3Rpbmcgb24gYmVoYWxmIG9mIHNvbWUgcGFydHksIGFuZCB0aGUgbWVudGlvbmVkIHBocmFz ZSBpcyByZWR1bmRhbnQ/DQoNCkp1c3RpbjogYSBjb3VwbGUgcXVlc3Rpb25zDQoNCjEuIFdoYXQg aXMgbWVhbnQgYnkgIkRlbGVnYXRpb24gYmV0d2VlbiBtdWx0aXBsZSB1c2VycyIgPw0KDQoyLiBX aHkgZG8geW91IHJlc3RyaWN0IHRoaXMgdG8gSFRUUD8NCg0KMy4gV2h5IGlzIGF1dGhlbnRpY2F0 aW9uIG5vdCBpbiBzY29wZT8NCg0KNC4gV2hlbiB5b3Ugc2F5ICJub3QgYmFja3dhcmRzIGNvbXBh dGlibGUgd2l0aCBPQXV0aCAyLjAgYW5kIGl0cyBleHRlbnNpb25zIiwgZG8geW91IGV4cGVjdCB0 byBkZWZpbmUgYSBuZXcgc3RhbmRhcmQgdG8gcmVwbGFjZSBSRkMgNjc1MD8gRGV2ZWxvcGVycyB3 aWxsIGhhdmUgdG8gaGF2ZSBhIG5ldyBtZXRob2QgdG8gY2FsbCBBUElzPw0KDQoNCk9uIEZyaSwg RGVjIDIwLCAyMDE5IGF0IDM6MjcgUE0gRXZlIE1hbGVyIDxldmVAeG1sZ3JybC5jb208bWFpbHRv OmV2ZUB4bWxncnJsLmNvbT4+IHdyb3RlOg0KUmUg4oCcdG8gYSBzb2Z0d2FyZSBjbGllbnQgX2Fj dGluZyBvbiBiZWhhbGYgb2YgYW4gYXV0aG9yaXppbmcgcGFydHlf4oCdOiBUaGVyZSBpcyBhIHdo b2xlIGxvdCBvZiBwaGlsb3NvcGh5IGJlaGluZCB3aG9tIHRoZSBkZWxlZ2F0ZWQgYWNjZXNzIGlz IHBlcmZvcm1lZCBvbiBiZWhhbGYgb2YsIHVubGVzcyB0aGUgc2NlbmFyaW8gaXMgc2luZ2xlLXVz ZXIgb3Igc29tZSAiYWN0IGFzIiBzZW1hbnRpYyBpcyBzcGVsbGVkIG91dCBvbiB0aGUgd2lyZS4g RG9lcyBpdCBuZWVkIHRvIGJlIHN0YXRlZCBoZXJlPyBXaGF0J3MgdGhlIGNvbnNlcXVlbmNlIGlm IHRoZSBoaWdobGlnaHRlZCBwaHJhc2Ugd2VyZSByZW1vdmVkPw0KRXZlIE1hbGVyIChzZW50IGZy b20gbXkgaVBhZCkgfCBjZWxsICsxIDQyNSAzNDUgNjc1Ng0KDQpPbiBEZWMgMjAsIDIwMTksIGF0 IDQ6MzQgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBt aXQuZWR1Pj4gd3JvdGU6DQpIaSBhbGwsDQoNCkFzIGRpc2N1c3NlZCBpbiBTaW5nYXBvcmUsIG5v IG1hdHRlciB3aGF0IGZvcnVtIFR4QXV0aCB0YWtlcywgaXRzIHdvcmsgd2lsbCByZXF1aXJlIGEg bmV3IGNoYXJ0ZXIuIFdpdGggdGhhdCBpbiBtaW5kLCBJ4oCZdmUgdGFrZW4gYSBiaXQgb2YgdGlt ZSB0byBwdXQgdG9nZXRoZXIgYSBwcm9wb3NlZCBjaGFydGVyIHRleHQgZm9yIHRoZSBUeEF1dGgg d29yazoNCg0KVGhpcyBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBhIG5leHQtZ2VuZXJh dGlvbiB0cmFuc2FjdGlvbmFsIGF1dGhvcml6YXRpb24gYW5kIGRlbGVnYXRpb24gcHJvdG9jb2wg Zm9yIEhUVFAtYmFzZWQgQVBJcyBhbmQgdGhlaXIgY2xpZW50cy4gVGhlc2UgdHJhbnNhY3Rpb25z IHdpbGwgYWxsb3cgYW4gYXV0aG9yaXppbmcgcGFydHkgdG8gZGVsZWdhdGUgYSByaWdodCBvZiBh Y2Nlc3MgZm9yIGFuIEFQSSBvciBzZXQgb2YgQVBJcyB0aHJvdWdoIGFuIGF1dGhvcml6YXRpb24g c2VydmVyIHRvIGEgc29mdHdhcmUgY2xpZW50IGFjdGluZyBvbiBiZWhhbGYgb2YgYW4gYXV0aG9y aXppbmcgcGFydHkuDQoNClRoZSBncm91cCB3aWxsIGRlbGl2ZXIgYSBwcm90b2NvbCBzcGVjaWZp Y2F0aW9uIGRldGFpbGluZyBob3cgYSBjbGllbnQgY2FuIHJlcXVlc3QgYW5kIG9idGFpbiBkZWxl Z2F0ZWQgYWNjZXNzLCBob3cgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgY2FuIHByb3ZpZGUgZGVs ZWdhdGVkIGFjY2VzcywgaG93IGFuIGF1dGhvcml6ZWQgcGFydHkgY2FuIGF1dGhvcml6ZSBkZWxl Z2F0ZWQgYWNjZXNzLCBhbmQgaG93IHRoYXQgYXV0aG9yaXplZCBhY2Nlc3MgY2FuIGJlIGNvbW11 bmljYXRlZCB0byB0aGUgcmVzb3VyY2VzIGJlaW5nIHByb3RlY3RlZC4gVGhlc2UgYWN0aW9ucyB3 aWxsIGJlIGNvbm5lY3RlZCB0aHJvdWdoIGFuIGV4cGxpY2l0IHRyYW5zYWN0aW9uIGJldHdlZW4g dGhlIGNsaWVudCBhbmQgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHJlc3VsdGluZyBpbiBhbiBhcnRp ZmFjdCB0aGF0IHdpbGwgYWxsb3cgdGhlIGNsaWVudCB0byB1bmRlcnRha2UgdGhlIGRlbGVnYXRl ZCBhY3Rpb24uDQoNCkFkZGl0aW9uYWxseSwgdGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGFs bG93IGZvcjoNCi0gRmluZS1ncmFpbmVkIHNwZWNpZmljYXRpb24gb2YgcmVzb3VyY2UgYWNjZXNz DQotIERlbGVnYXRpb24gYmV0d2VlbiBtdWx0aXBsZSB1c2Vycw0KLSBXZWIsIG1vYmlsZSwgc2lu Z2xlLXBhZ2UsIGFuZCBvdGhlciBjbGllbnQgYXBwbGljYXRpb25zDQoNClRoZSBncm91cCB3aWxs IGRlZmluZSBleHRlbnNpb24gcG9pbnRzIGZvciB0aGlzIHByb3RvY29sIHRvIGFsbG93IGZvciBm bGV4aWJpbGl0eSBpbiBhcmVhcyBpbmNsdWRpbmc6DQoNCi0gQ3J5cHRvZ3JhcGhpYyBhZ2lsaXR5 IGZvciBrZXlzLCBtZXNzYWdlIHNpZ25hdHVyZXMsIGFuZCBwcm9vZiBvZiBwb3NzZXNzaW9uDQot IFVzZXIgaW50ZXJhY3Rpb24gbWVjaGFuaXNtcyBpbmNsdWRpbmcgd2ViIGFuZCBub24td2ViIG1l dGhvZHMNCi0gVG9rZW4gcHJlc2VudGF0aW9uIG1lY2hhbmlzbXMgYW5kIGtleSBiaW5kaW5ncw0K DQpUaGUgYXJ0aWZhY3RzIGZvciB0aGlzIHdvcmsgYXJlIG5vdCBpbnRlbmRlZCBvciBleHBlY3Rl ZCB0byBiZSBiYWNrd2FyZHMtY29tcGF0aWJsZSB3aXRoIE9BdXRoIDIuMCBhbmQgaXRzIGV4dGVu c2lvbnMuDQoNCldoaWxlIHRoaXMgd29yayBjb3VsZCBiZSBkb25lIGluIHdpdGhpbiB0aGUgT0F1 dGggd29ya2luZyBncm91cCwgSSBub3cgYmVsaWV2ZSB0aGF0IGl0IHNob3VsZCBiZSBkb25lIGlu IGEgbmV3IHdvcmtpbmcgZ3JvdXAsIGFuZCB0aGF0IHdlIHNob3VsZCB0cnkgdG8gZ2V0IHRoYXQg d29ya2luZyBncm91cCB1cCBhbmQgcnVubmluZyBwcmlvciB0byB0aGUgVmFuY291dmVyIG1lZXRp bmcgaW4gTWFyY2guLiBJIHRoaW5rIHRoaXMgZ3JvdXAgc2hvdWxkIHN0YXkgaGVyZSBvbiB0aGUg VHhBdXRoIGxpc3QsIGFuZCBpdOKAmXMgbXkgc3VnZ2VzdGlvbiB0aGF0IHRoZSByZXN1bHRpbmcg d29yayBiZSBjYWxsZWQgT0F1dGggMy4wLg0KDQpXaHkgYSBuZXcgZ3JvdXA/IEkgdGhpbmsgdGhh dCB0aGUgT0F1dGggd29ya2luZyBncm91cCBzaG91bGQgcmVtYWluIGZvY3VzZWQgb24gZXh0ZW5k aW5nLCBwYXRjaGluZywgYW5kIGFkYXB0aW5nIE9BdXRoIDIuMCB0byBhIGNoYW5naW5nIHdvcmxk LiBJIHBsYW4gdG8gYmUgZW5nYWdlZCBpbiBib3RoIGdyb3VwcywgYW5kIEkga25vdyBtb3N0IG9m IHlvdSBhcmUgYXMgd2VsbCwgYnV0IHRoYXTigJlzIG5vdCB1bml2ZXJzYWwuIFNpbmNlIE9BdXRo IDIuMCBpcyBzbyBlc3RhYmxpc2hlZCBhbHJlYWR5LCB0aGVyZSBhcmUgYSBMT1Qgb2YgcGVvcGxl IHdobyBhcmVu4oCZdCBnb2luZyB0byBiZSBpbnRlcmVzdGVkIGluIHNvbWV0aGluZyBuZXcgYW55 IHRpbWUgc29vbi4gQnV0IG9uIHRoZSBvdGhlciBoYW5kLCB0aGVyZSBhcmUgYSBudW1iZXIgb2Yg cGVvcGxlIGZvciB3aG9tIE9BdXRoIDIuMCBkb2VzIG5vdCB3b3JrLCBvciBpcyBhdCB0aGUgdmVy eSBsZWFzdCBhIHBvb3IgZml0LCBhbmQgd2XigJlsbCB3YW50IHRvIGJyaW5nIHRoZW0gaW4gYXQg dGhpcyBlYXJseSBzdGFnZS4gU28gZXZlbiB3aXRoIHNpZ25pZmljYW50IG92ZXJsYXAsIEkgdGhp bmsgdGhlcmXigJlzIGVub3VnaCBkaXNjb25uZWN0IGluIHRoZSBjb21tdW5pdHkgZnJvbSBib3Ro IHNpZGVzIHRoYXQgd2FycmFudHMgYSBuZXcgZ3JvdXAuIEluIGFkZGl0aW9uLCBJIHRoaW5rIHRo aXMgaXMgYSBiaWcgZW5vdWdoIHBpZWNlIG9mIHdvcmsgdGhhdCBpdOKAmXMgc2ltcGx5IHRvbyBt dWNoIGZvciB0aGUgT0F1dGggd29ya2luZyBncm91cCB0byBiZSBhYmxlIHRvIGZvY3VzIG9uLiBX ZSB3b3VsZG7igJl0IGJlIGFibGUgdG8gZ2V0IGFkZGl0aW9uYWwgbWVldGluZyB0aW1lLCBhbmQg T0F1dGggYWxyZWFkeSBoYXMgdHJvdWJsZSBmaXR0aW5nIGludG8gaXRzIHR3byBtZWV0aW5nIHNs b3RzIGFzIGl0IGlzLg0KDQpJ4oCZdmUgcHVibGlzaGVkIGEgYmxvZyBwb3N0IGRldGFpbGluZyBt b3JlIG9mIG15IHJhdGlvbmFsZToNCg0KaHR0cHM6Ly9tZWRpdW0uY29tL0BqdXN0aW5zZWN1cml0 eS90aGUtY2FzZS1mb3Itb2F1dGgtMy0wLXdoeS1hLW5ldy13b3JraW5nLWdyb3VwLWQ2MjI5YmE4 ZTM2Pw0KDQpQbGVhc2Ugc3VnZ2VzdCBjaGFuZ2VzIHRvIHRoZSBwcm9wb3NlZCBjaGFydGVyIHRl eHQgYWJvdmUuIEl04oCZcyBteSBob3BlIHRoYXQgd2UgY2FuIGdldCB0aGUgY2hhcnRlcmluZyBw cm9jZXNzIHN0YXJ0ZWQuDQoNCiDigJQgSnVzdGluDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlzdA0K VHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4 YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgNCg0KDQoNCg== --_000_684F4469031B4AB98B53A87597AE012Eamazoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <00F75942F7F9CA47B92FA8B078794D39@amazon.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2Ut MToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJy aTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJFdXBoZW1pYSBVQ0FTIjsNCglwYW5vc2UtMToyIDEx IDUgMyA0IDEgMiAyIDEgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IHBvaW50IGlzLCBJIG1pZ2h0IHdhbnQgbXkgdG9rZW5zIHRvIGJlIHNpZ25lZCB1c2luZyBrZXlz IHRoYXQgbXkgVFggRW5kcG9pbnQgZG9lcyBub3QgaGF2ZSBhY2Nlc3MgdG8uIEUuZy4sIG15IHRv a2VuIGlzc3VlciBzaWducyB0b2tlbnMgd2l0aCBrZXkgQSBhbmQgbXkgVFggRW5kcG9pbnQgc2ln bnMgSFRUUCByZXNwb25zZSBtZXNzYWdlcyB3aXRoIGtleSBCLCBuZWl0aGVyIHN5c3RlbSBoYXMg YWNjZXNzDQogdG8gdGhlIG90aGVyIGtleSwgYW5kIHRva2VucyBzaWduZWQgYnkga2V5IEIgYXJl IHJlamVjdGVkIGJ5IFJTZXMuIFRoaXMgcmVxdWlyZXMgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gdW5k ZXJzdGFuZCB0aGF0IHRydXN0IGJvdW5kYXJpZXMgbWF5IGV4aXN0IGJldHdlZW4gdGhlIGRpZmZl cmVudCBjb21wb25lbnRzIGltcGxlbWVudGluZyBwb3J0aW9ucyBvZiDigJxBU+KAnSBiZWhhdmlv ci4gSWYgdGhpcyBpc27igJl0IHVuZGVyc3Rvb2QsIHRoZW4gaWYvd2hlbg0KIEkgYnJpbmcgdXAg dGhpcyB1c2UgY2FzZSwgSeKAmW0gZ29pbmcgdG8gYmUgdG9sZCDigJx0aGVyZSBhcmUgbm8gdHJ1 c3QgYm91bmRhcmllcyB3aXRoaW4gYW4gQVMsIHNvIHdoYXQgeW914oCZcmUgZGVzY3JpYmluZyBp c27igJl0IGFuIEFTIGFueW1vcmUsIGFuZCBub3QgaW4gc2NvcGUgcGVyIHRoZSBjaGFydGVyLuKA nTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBzZW5zaXRpdmUgdG8gdGhlIGRlc2lyZSB0 byBub3Qgb3ZlcmNvbXBsaWNhdGUgdGhpbmdzLiBUaGUgc2NlbmFyaW8gSeKAmW0gZGVzY3JpYmlu ZyBpcyB1bnVzdWFsLCBhbmQgcHJvYmFibHkgbm90IHdoYXQgd2Ugc2hvdWxkIG9wdGltaXplIHRo ZSBwcm90b2NvbCBmb3IgKHRob3VnaCB0aGF0IGNvdWxkIGFsd2F5cyBjaGFuZ2UpLiBCdXQgd2Xi gJlyZSB0YWxraW5nIGFib3V0DQo8aT5jaGFydGVyPC9pPiwgbm90IDxpPnByb3RvY29sPC9pPi4g VGhlIGNoYXJ0ZXIgY2FuIGJlIGFzIGRldGFpbGVkIGFuZCBudWFuY2VkIGFzIGl0IG5lZWRzIHRv IGJlIHRvIHByb3Blcmx5IGRlc2NyaWJlIHdoYXQgd2UgYXJlIHNldHRpbmcgb3V0IHRvIGFjY29t cGxpc2guPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+4oCTJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJk IEJhY2ttYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QVdTIElkZW50aXR5PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0 LmVkdSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBEZWNlbWJlciAyMywgMjAxOSBhdCAx OjU3IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSZx dW90OyAmbHQ7cmljaGFubmFAYW1hem9uLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPkRpY2sgSGFy ZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0OywgRXZlIE1hbGVyICZsdDtldmVAeG1sZ3Jy bC5jb20mZ3Q7LCAmcXVvdDtyZGRAY2VydC5vcmcmcXVvdDsgJmx0O3JkZEBjZXJ0Lm9yZyZndDss ICZxdW90O3R4YXV0aEBpZXRmLm9yZyZxdW90OyAmbHQ7dHhhdXRoQGlldGYub3JnJmd0OywgQmVu amFtaW4gS2FkdWsgJmx0O2thZHVrQG1pdC5lZHUmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl OiBbVHhhdXRoXSBUeEF1dGggUHJvcG9zZWQgQ2hhcnRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB0aGUgdGhpbmcgaXMsIEkgZG9u4oCZ dCB0aGluayB5b3UgbmVlZCBhIHNpbmdsZSBKV0tTIFVSSSBhbnltb3JlIGFueXdheS4gWW914oCZ ZCBoYXZlIG9uZSBhc3NvY2lhdGVkIHdpdGggdGhlIFR4RW5kcG9pbnQsIGlmIHlvdeKAmXZlIGdv dCBzaWduZWQgdG9rZW5zIHRoYXQgeW91IG5lZWQgdG8gdmFsaWRhdGUgc2VwYXJhdGVseS4gQW5k IGlmIHlvdeKAmXJlIGRvaW5nIHNpZ25lZCB1c2VyIGFzc2VydGlvbnMsIHlvdeKAmWQNCiBoYXZl IGEgZGlmZmVyZW50IG9uZSBpZGVudGlmaWVkIGluIHRoZSBhc3NlcnRpb24gKGVpdGhlciBkaXJl Y3RseSBvciB2aWEgYW4gaXNzdWVyLWRpc2NvdmVyeSBtZWNoYW5pc20pLiBVbHRpbWF0ZWx5IHRo ZSBjbGllbnQgaXMgZ29pbmcgdG8gY2FyZSBhYm91dCBvbmUgYW5kIHRoZSBSUyBhYm91dCBhbm90 aGVyIHNvIGl04oCZcyBmaW5lIHRoYXQgdGhleeKAmXJlIGRpZmZlcmVudC4gV2UgZ2V0IHRvIGRl ZmluZSB3aGF0IHRoYXQgbG9va3MgbGlrZS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gdGhlIHN1cmZhY2UgSeKAmW0gT0sgd2l0aCBhIGRl Y29tcG9zZWQgQVMsIHRvIHNvbWUgZXh0ZW50LCBidXQgb25seSBpZiB0aGVyZSBhcmUgdmVyeSwg dmVyeSBjbGVhciBib3VuZGFyaWVzIGFib3V0IHdoYXQgdGhlIGluZGl2aWR1YWwgcm9sZXMgYXJl LiBBbmQgdGhlIG1vcmUgcm9sZXMgd2UgbWFrZSwgdGhlIG1vcmUgd2UgaGF2ZSB0byBkZWZpbmUg d2hhdCB0aGUgY29tbXVuaWNhdGlvbiBwb2ludHMgYXJlDQogaW4gYmV0d2VlbiB0aGVtLiBNYXli ZSDigJxBU+KAnSBpcyB0b28gYWxsLWVuY29tcGFzc2luZyBvZiBhIHJvbGUgbm93LCBidXQgSeKA mW0gbm90IHlldCBjb252aW5jZWQgdGhhdOKAmXMgdHJ1ZSBpbiBwcmFjdGljZSwgYW5kIEkgZG8g d2FudCBzb21lb25lIHRvIGJlIGFibGUgdG8gZGVwbG95IHRoaXMgYnkgaGF2aW5nIGFsbCB0aGUg 4oCcc2VydmVy4oCdIHNpZGUgZnVuY3Rpb25hbGl0aWVzIHJ1bm5pbmcgb3V0IG9mIGEgc2luZ2xl LCBzaW1wbGUgYm94LiBUaGF0DQogbWlnaHQgYmUgYSBjYXNlIG9mIHRoYXQgc2luZ2xlIGJveCBu ZWVkaW5nIHRvIHBsYXkgbXVsdGlwbGUgcm9sZXMsIGFuZCB0aGF04oCZcyBPSywgYnV0IHdlIG5l ZWQgdG8gYmUgY2xlYXIgb24gd2hhdCBraW5kcyBvZiBvcHRpbWl6YXRpb25zIGFyZSBhbGxvd2Fi bGUgaW4gY2FzZXMgbGlrZSB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIHRoaW5rIHRoZXJl4oCZcyBwcmVjZWRlbnQgaW4gYXNr aW5nIHRoaXMgcXVlc3Rpb24gdGhvdWdoLCBzaW5jZSBiZXR3ZWVuIE9BdXRoIDEgYW5kIDIgd2Ug c3BsaXQgdGhlIOKAnHNlcnZlcuKAnSBpbnRvIOKAnEFTIGFuZCBSU+KAnS4gT0F1dGggMiBmYW1v dXNseSBkaWRu4oCZdCBkZWZpbmUgYSBjb25uZWN0aW9uIHBvaW50IGJldHdlZW4gdGhlbSB1bnRp bCBtdWNoIGxhdGVyIChKV1QgYW5kIEludHJvc3BlY3Rpb24pLCBidXQNCiB0aGF0IHBhdHRlcm4g c2VlbXMgdG8gaGF2ZSBtb3N0bHkgd29ya2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDvigJQgSnVzdGluPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBEZWMgMjIsIDIwMTksIGF0IDExOjUy IFBNLCBSaWNoYXJkIEJhY2ttYW4sIEFubmFiZWxsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJpY2hh bm5hQGFtYXpvbi5jb20iPnJpY2hhbm5hQGFtYXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IGV4YW1wbGUgZGVtb25z dHJhdGVzIGFuIGFyY2hpdGVjdHVyZSB3aGVyZSB0aGUgVFggRW5kcG9pbnQsIGF1dGhlbnRpY2F0 aW9uIHN5c3RlbSwgYW5kIHRva2VuIGlzc3VlciBhcmVu4oCZdCBzaW1wbHkgZGlmZmVyZW50IG1p Y3JvIHNlcnZpY2VzLCB0aGV54oCZcmUgY29tcGxldGVseSBpbmRlcGVuZGVudCBzeXN0ZW1zIGlu IGRpZmZlcmVudCB0cnVzdCBib3VuZGFyaWVzLCBwb3NzaWJseSBoYXZlIGRpZmZlcmVudA0KIGRv bWFpbnMgYW5kIGRpZmZlcmVudCBrZXlzLiBUaGlzIGhhcyBpbXBsaWNhdGlvbnMgZm9yIHByb3Rv Y29sIGRlc2lnbi4gRm9yIGV4YW1wbGUsIGl0IHdvdWxkIG5vIGxvbmdlciBiZSBzdWZmaWNpZW50 IHRvIGhhdmUgYSBzaW5nbGUgandrc191cmksIGFzIE9BdXRoIDIuMCBoYXMuDQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIHdhbnQgdG8g c3VwcG9ydCB0aGlzIGtpbmQgb2Yg4oCcZGVjb21wb3NlZCBBU+KAnSBtb2RlbCwgdGhlbiB3ZSBu ZWVkIHRvIG1ha2Ugc3VyZSB0aGF04oCZcyBzdXBwb3J0ZWQgYnkgdGhlIGNoYXJ0ZXIgYW5kIGtl ZXAgaXQgaW4gbWluZCBhcyB3ZSBkZXNpZ24gdGhlIHByb3RvY29sLiBXZSBjYW4gYWxzbyBkZWNp ZGUgaXQgaXMgb3V0IG9mIHNjb3BlLCBidXQgd2Ugc2hvdWxkIGJlIGludGVudGlvbmFsIGFib3V0 DQogdGhhdCBkZWNpc2lvbi48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRvIG15IG1pbmQsIHRoaXMgcm9sZSBkZWNvbXBvc2l0aW9uIGlz IHRoZSBuZXh0IGxvZ2ljYWwgc3RlcCBhZnRlciB0aGUgY2hhbm5lbCBkZWNvbXBvc2l0aW9uIHRo YXQgVHhBdXRoIGFscmVhZHkgZG9lcy4gSSBzZWUgYSBsb3Qgb2YgcG90ZW50aWFsIGluIGl0IGFu ZCB0aGluayB3ZSBzaG91bGQgYXQgbWluaW11bSBhdm9pZCBjbG9zaW5nIHRoZSBkb29yIG9uIGl0 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+T24gRGVjIDIyLCAyMDE5LCBhdCA1OjM1IFBNLCBKdXN0aW4g UmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1Ij5qcmljaGVyQG1pdC5l ZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB5b3XigJlyZSBjb25mbGF0aW5n IHRoZSA8aT5yb2xlczwvaT4mbmJzcDt0aGF0IGRpZmZlcmVudCBjb21wb25lbnRzIHBsYXksIGlu IHJlZ2FyZCB0byB0aGUgb3RoZXIgY29tcG9uZW50cywgd2l0aCB0aGUgcG90ZW50aWFsIGRlcGxv eW1lbnQgb2YgdGhvc2UgY29tcG9uZW50cy4gVGhlIHNwZWMgbmVlZHMgdG8gYmUgd3JpdHRlbiBp biB0ZXJtcyBvZiB0aGUgcm9sZXMuIFdoaWxlIHRoZSByb2xlcyBkbyBuZWVkDQogdG8gY29uc2lk ZXIgd2hhdCBwb3RlbnRpYWwgZGVwbG95bWVudHMgbWlnaHQgYmUsIGl04oCZcyBpbXBvcnRhbnQg dGhhdCB3ZSB3cml0ZSB0aGluZ3MgaW4gaW4gdGVybXMgb2YgaG93IHRoZXkgaW50ZXJhY3Qgd2l0 aCBlYWNoIG90aGVyIGFuZCBub3QgaW4gdGVybXMgb2YgaG93IHRoZXkgbWlnaHQgbG9vayB1bmRl ciB0aGUgY292ZXJzLg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TbyBmcm9tIHRoZSBjbGllbnRzIHBlcnNwZWN0aXZlLCB0aGUgVFggRW5kcG9pbnQgOmlz OiB0aGUgQVMuIFRoZSBjbGllbnQgZG9lc27igJl0IGNhcmUgdGhhdCBpdOKAmXMgYSDigJxnbG9y aWZpZWQgbWVzc2FnZSBxdWV1ZeKAnSBvciBpZiBpdOKAmXMgYSBtYXNzaXZlIHNlcnZlciBmYXJt LiBUaGUgY2xpZW50IGRvZXNu4oCZdCBjYXJlIGlmIHRoZXJl4oCZcyBhIFRMUyByZXZlcnNlIHBy b3h5IG9yIGlmIGl04oCZcyB0YWxraW5nIGRpcmVjdGx5DQogdG8gdGhlIGFwcGxpY2F0aW9uIGxh eWVyLiBUaGUgb25seSB0aGluZyB0aGUgY2xpZW50IGNhcmVzIGFib3V0IGlzIGlmIHRoZSBUWCBF bmRwb2ludCBkb2VzIHRoZSB0aGluZ3MgdGhhdCBhIFRYIEVuZHBvaW50IGlzIHN1cHBvc2VkIHRv IGRvLCBhbmQgd2UgZGVmaW5lIHRoYXQgdG8gYmUgdGhlIGZ1bmN0aW9uIG9mIHRoZSBBUy4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2hhdOKAmXMgaW1wb3J0YW50IGluIHlvdXIgc2NlbmFyaW8gYmVsb3cgaXMgdGhhdCB0aGUgY2xp ZW50IHdvdWxkIGhhdmUgdG8gdGFsayB0byB0aGUgUlMgZmlyc3QgZXZlcnkgdGltZS4gVGhhdOKA mXMgb25lIG9mIHRoZSBwcm9ibGVtcyB0aGF0IFVNQSBoYXMsIGFuZCBJIHRoaW5rIHNvbWV0aGlu ZyB3ZSBzaG91bGQgYXZvaWQuIEkgdGhpbmsgUlMtZmlyc3QgaXMgYW4gaW50ZXJlc3RpbmcgcGF0 dGVybiBidXQgQVMtZmlyc3QNCiBvdWdodCB0byBkcml2ZSB0aGlzLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHlvdXIgaHlw b3RoZXRpY2FsIGxheW91dCBiZWxvdywgaXQgcmVhbGx5IHNvdW5kcyBsaWtlIHRoZSBUWCBFbmRw b2ludCBpcyBhIGZ1bmN0aW9uIG9mIHRoZSBJRFAsIHdoaWNoIGlzIGZpbmUuIFRoZSBjbGllbnQg ZG9lc27igJl0IGNhcmUgdGhhdCBpdOKAmXMgZGVwbG95ZWQgdXNpbmcgc29tZSBleHRlcm5hbGl6 ZWQgY2xvdWQgc2VydmljZS4gVGhlIG9ubHkgd2VpcmQgdGhpbmcgZ29pbmcgb24gaXMgdGhlIHB1 c2gNCiBmcm9tIHRoZSBBUyBiYWNrIHRvIHRoZSBjbGllbnQuIFRoZSBjbGllbnQgd291bGQgbmVl ZCB0byByZWdpc3RlciB0aGF0IHdpdGggdGhlIEFTIChvciB0aHJvdWdoIHRoZSBBUyBtb3JlIHNw ZWNpZmljYWxseSkgYXMgcGFydCBvZiBpdHMgdHJhbnNhY3Rpb24gcmVxdWVzdC4gVGhpcyB3b3Vs ZCBiZSBwYXJ0IG9mIGl0cyBpbnRlcmFjdGlvbiBtZWNoYW5pc20sIGJlY2F1c2Ug4oCcaG93IHlv dSBnZXQgbWVzc2FnZXMgYW5kIHVwZGF0ZXMgYmFjayB0bw0KIHRoZSBjbGllbnTigJ0gaXMgcGFy dCBvZiB0aGUgaW50ZXJhY3Rpb24gbW9kZWwuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGZvciBhbiBSUy1maXJzdCB0cmFuc2Fj dGlvbiwgdGhlIGNsaWVudCBjYWxscyB0aGUgUlM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdFVCAvZm9vPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBSUyByZXR1cm5zIGEgcmVzb3Vy Y2UgaGFuZGxlLCBidXQgdGhlIGNsaWVudCBkb2VzbuKAmXQgY2FyZSB3aGVyZSB0aGF0IGNhbWUg ZnJvbS4gVGhlIFJTIGNvdWxkIHRhbGsgdG8gdGhlIEFTIHRvIGdldCBpdC4gUHJvYmFibHkgYSBu ZXcgZW5kcG9pbnQgb2Ygc29tZSBraW5kLCBjYW4gcHJvYmFibHkgdXNlIHRoZSBzYW1lIGtpbmRz IG9mIGtleSBiaW5kaW5nIHRoYXQgdGhlIFRYIEVuZHBvaW50IGhhcy4gT3INCiB0aGUgUlMgY2Fu IG1ha2Ugb25lIHVwIHRoYXQgdGhlIFRYIEVuZHBvaW50IGNhbiByZWNvZ25pemUuIE9yIGl0IGNh bGxzIHRoZSBJZFAgdG8gZ2V0IG9uZS4gVGhlIGNsaWVudCBkb2VzbuKAmXQgY2FyZSwgYW5kIHRo YXTigJlzIHRoZSBrZXkgcG9pbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldXVy1BdXRoZW50aWNhdGUgdHhfZW5kcG9pbnQ94oCc PGEgaHJlZj0iaHR0cDovL3NlcnZlciVFRiVCRiVCRC90eCI+aHR0cDovL3NlcnZlci8vdHg8L2E+ 4oCdIHJlc291cmNlOiDigJxhc2RmMTIzNOKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY2xpZW50IGNhbGxzIHRoZSBUWCBlbmRwb2lu dCBsaWtlIGEgbm9ybWFsIHRyYW5zYWN0aW9uOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QT1NUIC90eDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj57PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgcmVzb3VyY2VzOiBbIOKAnGFzZGYx MjM04oCdIF0sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgaW50ZXJhY3Q6IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgcmVkaXJlY3Q6IHRydWUsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 IHB1c2g6IOKAnDxhIGhyZWY9Imh0dHA6Ly9jbGllbnQvcHVzaC85ODc2Ij5odHRwOi8vY2xpZW50 L3B1c2gvOTg3NjwvYT7igJ08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj59PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBBUyAod2hpY2ggaXMgdG8gc2F5IHRoZSBUWCBFbmRwb2ludCkg dGVsbHMgdGhlIGNsaWVudCB0byBzZW5kIHRoZSB1c2VyIGFnZW50IHRvIHRoZSBJZFA8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ezxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IGludGVy YWN0X3VybDog4oCcPGEgaHJlZj0iaHR0cDovL2lkcC9sb2dpbiI+aHR0cDovL2lkcC9sb2dpbjwv YT7igJ0sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgaGFuZGxlOiB7IHZhbHVlOiDigJxoamts4oCdLCB0eXBlOiBiZWFyZXIgfTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3cgdGhlIGNs aWVudCBjb3VsZCBwb2xsIHRoZSBUWCBFbmRwb2ludCBidXQgaXQgY291bGQgYWxzbyBqdXN0IHNp dCBhbmQgd2FpdCBmb3IgYW4gdXBkYXRlIHRvIGJlIHB1c2hlZCBpbi4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIHBy b2JhYmx5IHRoaW5ncyB0aGF0IG5lZWQgdG8gYmUgdGllZCB0b2dldGhlciBmb3IgdGhpcyB0byBi ZSBzZWN1cmUsIGJ1dCBJIHRoaW5rIHRoZSBiYXNpYyBwYXR0ZXJuIHN0aWxsIGZpdHMuIEltcG9y dGFudGx5LCB0aGUgY2xpZW50IGRvZXNu4oCZdCBjYXJlIHdoZXJlYnkgb2YgdGhhdCBzdHVmZiBj YW1lIGZyb20g4oCUIGFzIGZhciBhcyBpdOKAmXMgY29uY2VybmVkLCBpdOKAmXMgdGFsa2luZyB0 byB0aGUNCiBBUy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+UmVtZW1iZXIsIHRoZSDigJxBU+KAnSBpcyBhIGxvZ2ljYWwgY29uc3Ry dWN0LCBub3QgYSBwaHlzaWNhbCBvbmUuIEp1c3QgbGlrZSB0aGUg4oCcY2xpZW504oCdIGNvdWxk IGJlIGEgY2x1c3RlciBvZiBhcHBsaWNhdGlvbnMgYW5kIHRoZSDigJxSU+KAnSBjb3VsZCBiZSBh IHN1aXRlIG9mIEFQSXMgdGllZCBiZWhpbmQgYSBnYXRld2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDvigJQgSnVzdGluPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIERlYyAyMiwgMjAxOSwgYXQgMTowNSBBTSwgUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUg Jmx0OzxhIGhyZWY9Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIERlYyAyMSwgMjAxOSwgYXQgNDo0MiBBTSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5FdmVuIGlmIHRoZSBjbGllbnQgc3RhcnRzIGF0IHRoZSBSUywgdGhlIGNs aWVudCBzdGlsbCBoYXMgdG8gZ28gdGFsayB0byB0aGUgQVMuIEkgaGF2ZW7igJl0IGJ1aWx0IHRo aXMgb3V0LCBidXQgSSBzZWUgaXQgd29ya2luZyBzb21ld2hhdCBsaWtlIFVNQS4gSW4gWFla4oCZ cyB0ZXJtczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4xLiBDbGllbnQgY2FsbHMgdGhlIFJTIHRyeWluZyB0byBEbyBBIFRoaW5nPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBSUyBjYWxs cyB0aGUgQVMgcmVxdWVzdGluZyBhIFJlc291cmNlIEhhbmRsZSAoYmVjYXVzZSB0aGF04oCZcyB3 aGF0IHRoZSBSUyByZXByZXNlbnRzLCByZXNvdXJjZXMpIOKAlCBhdCBsZWFzdCBnb29kIGVub3Vn aCB0byBjb3ZlciB3aGF0IHRoZSBjbGllbnQgdHJpZWQgdG8gZG8sIGNvdWxkIGJlIG1vcmU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuIFJTIGdp dmVzIHRoZSBSZXNvdXJjZSBIYW5kbGUgYW5kIEFTIFRyYW5zYWN0aW9uIEVuZHBvaW50IGJhY2sg dG8gdGhlIGNsaWVudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+NC4gQ2xpZW50IGNhbGxzIHRoZSBBUyBUcmFuc2FjdGlvbiBFbmRwb2ludCB0byBz dGFydCBhIHRyYW5zYWN0aW9uLCBpbmNsdWRlcyB0aGUgUmVzb3VyY2UgSGFuZGxlIGFzIHBhcnQg b2YgaXRzIHJlcXVlc3QgKG5vdGU6IGRvZXNu4oCZdCBoYXZlIHRvIGJlIHRoZSB3aG9sZSByZXNv dXJjZSBzZWN0aW9uLCBjbGllbnQgY2FuIGFkZCBzdHVmZik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUuIFByb2Nlc3MgY29udGludWVzIGFzIG5v cm1hbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgZGVwZW5kcyBvbiB3aGF0IHlvdSBj b25zaWRlciB0aGUg4oCcQVPigJ0uIENvbnNpZGVyIHRoZSBmb2xsb3dpbmcgaHlwb3RoZXRpY2Fs IGFyY2hpdGVjdHVyZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+4oCiIFRoZSBSUywgY2xpZW50LCBhbmQgdHggZW5kcG9pbnQgYXJlIG9uIHRo ZSBwdWJsaWMgSW50ZXJuZXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj7igKIgVGhlIHR4IGVuZHBvaW50IHJldHVybnMgaW50ZXJhY3Rpb24gdXJs cyB0aGF0IHBvaW50IHRvIGFuIElkUCB0aGF0IGlzIGluYWNjZXNzaWJsZSBmcm9tIHRoZSBwdWJs aWMgSW50ZXJuZXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj7igKIgVGhlIHVzZXIgYWdlbnQgY2FuIHJlYWNoIHRoZSBJZFAsIGJ1dCBub25lIG9m IHRoZSBvdGhlciBzeXN0ZW1zIGNhbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPuKAoiBXaGVuIHRoZSBVQSBpcyByZWRpcmVjdGVkIHRvIHRoZSBJ ZFAsIHRoZSBJZFAgY2FsbHMgdGhlIHR4IGVuZHBvaW50IHN5c3RlbSB0byByZXRyaWV2ZSB0cmFu c2FjdGlvbiBkZXRhaWxzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+4oCiIFdoZW4gYXV0aG9yaXphdGlvbiBpcyBncmFudGVkLCB0aGUgSWRQIHB1 c2hlcyBhcnRpZmFjdHMgZGlyZWN0bHkgdG8gYW4gZW5kcG9pbnQgcHJvdmlkZWQgYnkgdGhlIGNs aWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW4gdGhpcyBleGFtcGxlLCB0aGUgY2xpZW50IG9ubHkgaW50ZXJhY3RzIHdpdGggdGhlIFJT IGFuZCB0aGUgdHggZW5kcG9pbnQuIEl0IHNlZW1zIG9kZCB0byBtZSB0byBjb25zaWRlciB0aGUg c3lzdGVtIGhvc3RpbmcgdGhlIHR4IGVuZHBvaW50IHRvIGJlIHRoZSBBUyAob3IgYXQgbGVhc3Qg cGFydCBvZiB0aGUgQVMpLCBhcyBpdHMgYSBnbG9yaWZpZWQgbWVzc2FnZSBxdWV1ZSB3aXRoIGVz c2VudGlhbGx5IG5vDQogYXV0aG9yaXR5IGluIHRoaXMgYXJjaGl0ZWN0dXJlLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBjb3Vs ZCBnbyBhIHN0ZXAgZnVydGhlciBhbmQgcmVtb3ZlIHRoZSBjbGllbnTigJlzIGludGVyYWN0aW9u IHdpdGggdGhlIHR4IGVuZHBvaW50IGJ5IGhhdmluZyB0aGUgUlMgcmV0dXJuIHRoZSBpbnRlcmFj dGlvbiB1cmwgZGlyZWN0bHkgKHlvdeKAmWQgbmVlZCB0byBzZWN1cmUgdGhlIGNsaWVudCBub25j ZSBpZiB5b3Ugd2FudCB0byBoaWRlIGl0IGZyb20gdGhlIFJTLCBidXQgdGhhdOKAmXMgbm90IHRo YXQgaGFyZCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPklzIHRoZSBtZWFuaW5nIG9mIOKAnGF1dGhvcml6YXRpb24gc2VydmVy4oCdIChvciB0 aGUgcGhyYXNlIOKAnHRocm91Z2ggYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXLigJ0pIGZsZXhpYmxl IGVub3VnaCB0byBhY2NvbW1vZGF0ZSB0aGVzZSBjYXNlcz8gT3IgYXJlIHRoZXkgY29uc2lkZXJl ZCBvdXQgb2Ygc2NvcGUgZm9yIFR4QXV0aD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO+KAlCBKdXN0aW48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QXMgSSBzYWlkLCBtYXliZSBJ4oCZbSBiZWluZyB0b28gbGl0ZXJhbC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGltZyBib3JkZXI9 IjAiIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29t L3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVyb2Nv bnRlbnQmYW1wO2d1aWQ9ODExMjdhOWQtMDY0MS00MjNjLWJlNzctODEyMDcwMjQxMTAzIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0V1cGhlbWlhIFVDQVMm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgRGVjIDIw LCAyMDE5IGF0IDU6MDggUE0gUmljaGFyZCBCYWNrbWFuLCBBbm5hYmVsbGUgJmx0OzxhIGhyZWY9 Im1haWx0bzpyaWNoYW5uYUBhbWF6b24uY29tIj5yaWNoYW5uYUBhbWF6b24uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SeKAmW0gbm90IHN1cmUgaWYgdGhpcyBpcyB3aGF0IEV2 ZSBoYWQgaW4gbWluZCwgYnV0IGNvbnNpZGVyIGFuIGF1dG9tYXRlZCBzeXN0ZW0gaW4gYW4gZW50 ZXJwcmlzZSBjb250ZXh0IHRoYXQgaGFzIGJlZW4gYXV0aG9yaXplZCBieSBhbiBhZG1pbmlzdHJh dG9yLiBUaGUgYXV0b21hdGVkIHN5c3RlbSBpc27igJl0DQogYWN0aW5nIGFzIG9yIG9uIGJlaGFs ZiBvZiB0aGUgYWRtaW5pc3RyYXRvciwgYW5kIHRoZSBhZG1pbmlzdHJhdG9yIGhhc27igJl0IOKA nGRlbGVnYXRlZCBhY2Nlc3PigJ07IHRoZXnigJl2ZQ0KPGk+Z3JhbnRlZDwvaT4gYWNjZXNzLCBq dXN0IGFzIHRoZXkgZG8gd2hlbiB0aGV5IGFzc2lnbiBwZXJtaXNzaW9ucyB0byB1c2Vycy9ncm91 cHMvcm9sZXMvZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NYXli ZSBJ4oCZbSBiZWluZyB0b28gbGl0ZXJhbCwgYnV0IOKAnHRocm91Z2ggYW4gYXV0aG9yaXphdGlv biBzZXJ2ZXLigJ0gaW4gcGFyYWdyYXBoIDEgaW1wbGllcyBhIHNwZWNpZmljIGNvbnRleHQvaW5m b3JtYXRpb24vcmVxdWVzdCBmbG93IHRvIG1lLiBHaXZlbiB0aGF0IG9uZSBvZiBUeEF1dGjigJlz IGZlYXR1cmVzDQogaXMgZGVjb3VwbGluZyB0aGUgZGlmZmVyZW50IGNvbW11bmljYXRpb24gY2hh bm5lbHMsIHdlIHNob3VsZCBub3Qgc3VnZ2VzdCB0aGF0IHRoZSBjbGllbnQgb3IgYXV0aG9yaXpp bmcgcGFydHkgaXMgZGlyZWN0bHkgaW50ZXJhY3Rpbmcgd2l0aCB0aGUgQVMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPuKA kyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkFubmFiZWxsZSBSaWNoYXJkIEJhY2ttYW48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij5BV1MgSWRlbnRpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PlR4YXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg RGljayBIYXJkdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZGljay5oYXJkdEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwv Yj5GcmlkYXksIERlY2VtYmVyIDIwLCAyMDE5IGF0IDQ6MTQgUE08YnI+DQo8Yj5UbzogPC9iPkV2 ZSBNYWxlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmV2ZUB4bWxncnJsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmV2ZUB4bWxncnJsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVm PSJtYWlsdG86cmRkQGNlcnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+cmRkQGNlcnQub3JnPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkZEBjZXJ0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJk ZEBjZXJ0Lm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86dHhhdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnR4YXV0aEBpZXRmLm9yZzwv YT4mZ3Q7LA0KIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5l ZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OywgQmVuamFtaW4gS2Fk dWsgJmx0OzxhIGhyZWY9Im1haWx0bzprYWR1a0BtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+a2Fk dWtAbWl0LmVkdTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbVHhhdXRoXSBUeEF1 dGggUHJvcG9zZWQgQ2hhcnRlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5FdmU6IGRvIHlvdSBub3QgdGhpbmsg dGhlIHNvZnR3YXJlIGNsaWVudCBpcyBhY3Rpbmcgb24gYmVoYWxmIG9mIHNvbWUgcGFydHk/IE9y IGRvIHlvdSB0aGluayB0aGF0IHNvZnR3YXJlIGFsd2F5cyBpcyBhY3Rpbmcgb24gYmVoYWxmIG9m IHNvbWUgcGFydHksIGFuZCB0aGUgbWVudGlvbmVkIHBocmFzZSBpcw0KIHJlZHVuZGFudD8gPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SnVzdGluOiBh IGNvdXBsZSBxdWVzdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjEuIFdoYXQgaXMgbWVhbnQgYnkgJnF1b3Q7RGVsZWdhdGlvbiBi ZXR3ZWVuIG11bHRpcGxlIHVzZXJzJnF1b3Q7ID88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIuIFdoeSBkbyB5b3UgcmVzdHJpY3QgdGhp cyB0byBIVFRQPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+My4gV2h5IGlzIGF1dGhlbnRpY2F0aW9uIG5vdCBpbiBzY29wZT88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjQuIFdo ZW4geW91IHNheSAmcXVvdDtub3QgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBPQXV0aCAyLjAg YW5kIGl0cyBleHRlbnNpb25zJnF1b3Q7LCBkbyB5b3UgZXhwZWN0IHRvIGRlZmluZSBhIG5ldyBz dGFuZGFyZCB0byByZXBsYWNlIFJGQyA2NzUwPyBEZXZlbG9wZXJzIHdpbGwgaGF2ZSB0byBoYXZl IGEgbmV3IG1ldGhvZA0KIHRvIGNhbGwgQVBJcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIEZyaSwgRGVjIDIwLCAyMDE5IGF0IDM6MjcgUE0gRXZlIE1hbGVyICZsdDs8YSBocmVmPSJt YWlsdG86ZXZlQHhtbGdycmwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXZlQHhtbGdycmwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+UmUg 4oCcPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPnRvIGEgc29mdHdh cmUgY2xpZW50IF9hY3Rpbmcgb24gYmVoYWxmIG9mIGFuIGF1dGhvcml6aW5nIHBhcnR5X+KAnTog VGhlcmUgaXMgYSB3aG9sZSBsb3Qgb2YgcGhpbG9zb3BoeSBiZWhpbmQgd2hvbSB0aGUgZGVsZWdh dGVkIGFjY2VzcyBpcw0KIHBlcmZvcm1lZCBvbiBiZWhhbGYgb2YsIHVubGVzcyB0aGUgc2NlbmFy aW8gaXMgc2luZ2xlLXVzZXIgb3Igc29tZSAmcXVvdDthY3QgYXMmcXVvdDsgc2VtYW50aWMgaXMg c3BlbGxlZCBvdXQgb24gdGhlIHdpcmUuIERvZXMgaXQgbmVlZCB0byBiZSBzdGF0ZWQgaGVyZT8g V2hhdCdzIHRoZSBjb25zZXF1ZW5jZSBpZiB0aGUgaGlnaGxpZ2h0ZWQgcGhyYXNlIHdlcmUgcmVt b3ZlZD8mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy4wcHQiPkV2ZSBNYWxlciAo c2VudCBmcm9tIG15IGlQYWQpIHwmbmJzcDtjZWxsICYjNDM7MSA0MjUgMzQ1IDY3NTY8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gRGVjIDIwLCAyMDE5 LCBhdCA0OjM0IFBNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBt aXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SGkgYWxsLA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+QXMgZGlzY3Vzc2VkIGluIFNpbmdhcG9yZSwgbm8gbWF0dGVyIHdoYXQg Zm9ydW0gVHhBdXRoIHRha2VzLCBpdHMgd29yayB3aWxsIHJlcXVpcmUgYSBuZXcgY2hhcnRlci4g V2l0aCB0aGF0IGluIG1pbmQsIEnigJl2ZSB0YWtlbiBhIGJpdCBvZiB0aW1lIHRvIHB1dCB0b2dl dGhlciBhIHByb3Bvc2VkIGNoYXJ0ZXINCiB0ZXh0IGZvciB0aGUgVHhBdXRoIHdvcms6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAu MHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgZ3JvdXAgaXMgY2hhcnRlcmVk IHRvIGRldmVsb3AgYSBuZXh0LWdlbmVyYXRpb24gdHJhbnNhY3Rpb25hbCBhdXRob3JpemF0aW9u IGFuZCBkZWxlZ2F0aW9uIHByb3RvY29sIGZvciBIVFRQLWJhc2VkIEFQSXMgYW5kIHRoZWlyIGNs aWVudHMuIFRoZXNlIHRyYW5zYWN0aW9ucyB3aWxsIGFsbG93IGFuDQogYXV0aG9yaXppbmcgcGFy dHkgdG8gZGVsZWdhdGUgYSByaWdodCBvZiBhY2Nlc3MgZm9yIGFuIEFQSSBvciBzZXQgb2YgQVBJ cyB0aHJvdWdoIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGEgc29mdHdhcmUgY2xpZW50IGFj dGluZyBvbiBiZWhhbGYgb2YgYW4gYXV0aG9yaXppbmcgcGFydHkuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgZ3JvdXAg d2lsbCBkZWxpdmVyIGEgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiBkZXRhaWxpbmcgaG93IGEgY2xp ZW50IGNhbiByZXF1ZXN0IGFuZCBvYnRhaW4gZGVsZWdhdGVkIGFjY2VzcywgaG93IGFuIGF1dGhv cml6YXRpb24gc2VydmVyIGNhbiBwcm92aWRlIGRlbGVnYXRlZCBhY2Nlc3MsIGhvdyBhbg0KIGF1 dGhvcml6ZWQgcGFydHkgY2FuIGF1dGhvcml6ZSBkZWxlZ2F0ZWQgYWNjZXNzLCBhbmQgaG93IHRo YXQgYXV0aG9yaXplZCBhY2Nlc3MgY2FuIGJlIGNvbW11bmljYXRlZCB0byB0aGUgcmVzb3VyY2Vz IGJlaW5nIHByb3RlY3RlZC4gVGhlc2UgYWN0aW9ucyB3aWxsIGJlIGNvbm5lY3RlZCB0aHJvdWdo IGFuIGV4cGxpY2l0IHRyYW5zYWN0aW9uIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgYXV0aG9yaXph dGlvbiBzZXJ2ZXIsIHJlc3VsdGluZyBpbg0KIGFuIGFydGlmYWN0IHRoYXQgd2lsbCBhbGxvdyB0 aGUgY2xpZW50IHRvIHVuZGVydGFrZSB0aGUgZGVsZWdhdGVkIGFjdGlvbi4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFkZGl0 aW9uYWxseSwgdGhlIGRlbGVnYXRpb24gcHJvY2VzcyB3aWxsIGFsbG93IGZvcjo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBGaW5lLWdyYWlu ZWQgc3BlY2lmaWNhdGlvbiBvZiByZXNvdXJjZSBhY2Nlc3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBEZWxlZ2F0aW9uIGJldHdlZW4gbXVs dGlwbGUgdXNlcnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+LSBXZWIsIG1vYmlsZSwgc2luZ2xlLXBhZ2UsIGFuZCBvdGhlciBjbGllbnQgYXBw bGljYXRpb25zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGUgZ3JvdXAgd2lsbCBkZWZpbmUgZXh0ZW5zaW9uIHBvaW50cyBmb3IgdGhp cyBwcm90b2NvbCB0byBhbGxvdyBmb3IgZmxleGliaWxpdHkgaW4gYXJlYXMgaW5jbHVkaW5nOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ LSBDcnlwdG9ncmFwaGljIGFnaWxpdHkgZm9yIGtleXMsIG1lc3NhZ2Ugc2lnbmF0dXJlcywgYW5k IHByb29mIG9mIHBvc3Nlc3Npb24mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBVc2VyIGludGVyYWN0aW9uIG1lY2hhbmlzbXMgaW5j bHVkaW5nIHdlYiBhbmQgbm9uLXdlYiBtZXRob2RzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gVG9rZW4gcHJlc2VudGF0aW9uIG1lY2hhbmlz bXMgYW5kIGtleSBiaW5kaW5nczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGFydGlmYWN0cyBmb3IgdGhpcyB3b3JrIGFyZSBub3Qg aW50ZW5kZWQgb3IgZXhwZWN0ZWQgdG8gYmUgYmFja3dhcmRzLWNvbXBhdGlibGUgd2l0aCBPQXV0 aCAyLjAgYW5kIGl0cyBleHRlbnNpb25zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hpbGUgdGhp cyB3b3JrIGNvdWxkIGJlIGRvbmUgaW4gd2l0aGluIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLCBJ IG5vdyBiZWxpZXZlIHRoYXQgaXQgc2hvdWxkIGJlIGRvbmUgaW4gYSBuZXcgd29ya2luZyBncm91 cCwgYW5kIHRoYXQgd2Ugc2hvdWxkIHRyeSB0byBnZXQgdGhhdCB3b3JraW5nIGdyb3VwIHVwDQog YW5kIHJ1bm5pbmcgcHJpb3IgdG8gdGhlIFZhbmNvdXZlciBtZWV0aW5nIGluIE1hcmNoLi4gSSB0 aGluayB0aGlzIGdyb3VwIHNob3VsZCBzdGF5IGhlcmUgb24gdGhlIFR4QXV0aCBsaXN0LCBhbmQg aXTigJlzIG15IHN1Z2dlc3Rpb24gdGhhdCB0aGUgcmVzdWx0aW5nIHdvcmsgYmUgY2FsbGVkIE9B dXRoIDMuMC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPldoeSBhIG5ldyBncm91cD8gSSB0aGluayB0aGF0IHRoZSBPQXV0aCB3 b3JraW5nIGdyb3VwIHNob3VsZCByZW1haW4gZm9jdXNlZCBvbiBleHRlbmRpbmcsIHBhdGNoaW5n LCBhbmQgYWRhcHRpbmcgT0F1dGggMi4wIHRvIGEgY2hhbmdpbmcgd29ybGQuIEkgcGxhbiB0byBi ZSBlbmdhZ2VkIGluIGJvdGggZ3JvdXBzLA0KIGFuZCBJIGtub3cgbW9zdCBvZiB5b3UgYXJlIGFz IHdlbGwsIGJ1dCB0aGF04oCZcyBub3QgdW5pdmVyc2FsLiBTaW5jZSBPQXV0aCAyLjAgaXMgc28g ZXN0YWJsaXNoZWQgYWxyZWFkeSwgdGhlcmUgYXJlIGEgTE9UIG9mIHBlb3BsZSB3aG8gYXJlbuKA mXQgZ29pbmcgdG8gYmUgaW50ZXJlc3RlZCBpbiBzb21ldGhpbmcgbmV3IGFueSB0aW1lIHNvb24u IEJ1dCBvbiB0aGUgb3RoZXIgaGFuZCwgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHBlb3BsZSBmb3Ig d2hvbQ0KIE9BdXRoIDIuMCBkb2VzIG5vdCB3b3JrLCBvciBpcyBhdCB0aGUgdmVyeSBsZWFzdCBh IHBvb3IgZml0LCBhbmQgd2XigJlsbCB3YW50IHRvIGJyaW5nIHRoZW0gaW4gYXQgdGhpcyBlYXJs eSBzdGFnZS4gU28gZXZlbiB3aXRoIHNpZ25pZmljYW50IG92ZXJsYXAsIEkgdGhpbmsgdGhlcmXi gJlzIGVub3VnaCBkaXNjb25uZWN0IGluIHRoZSBjb21tdW5pdHkgZnJvbSBib3RoIHNpZGVzIHRo YXQgd2FycmFudHMgYSBuZXcgZ3JvdXAuIEluIGFkZGl0aW9uLCBJDQogdGhpbmsgdGhpcyBpcyBh IGJpZyBlbm91Z2ggcGllY2Ugb2Ygd29yayB0aGF0IGl04oCZcyBzaW1wbHkgdG9vIG11Y2ggZm9y IHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIHRvIGJlIGFibGUgdG8gZm9jdXMgb24uIFdlIHdvdWxk buKAmXQgYmUgYWJsZSB0byBnZXQgYWRkaXRpb25hbCBtZWV0aW5nIHRpbWUsIGFuZCBPQXV0aCBh bHJlYWR5IGhhcyB0cm91YmxlIGZpdHRpbmcgaW50byBpdHMgdHdvIG1lZXRpbmcgc2xvdHMgYXMg aXQgaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5J4oCZdmUgcHVibGlzaGVkIGEgYmxvZyBwb3N0IGRldGFpbGluZyBtb3JlIG9mIG15 IHJhdGlvbmFsZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vbWVkaXVtLmNvbS9AanVzdGluc2VjdXJpdHkv dGhlLWNhc2UtZm9yLW9hdXRoLTMtMC13aHktYS1uZXctd29ya2luZy1ncm91cC1kNjIyOWJhOGUz Nj8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21lZGl1bS5jb20vQGp1c3RpbnNlY3VyaXR5L3Ro ZS1jYXNlLWZvci1vYXV0aC0zLTAtd2h5LWEtbmV3LXdvcmtpbmctZ3JvdXAtZDYyMjliYThlMzY/ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+UGxlYXNlIHN1Z2dlc3QgY2hhbmdlcyB0byB0aGUgcHJvcG9zZWQgY2hhcnRlciB0ZXh0 IGFib3ZlLiBJdOKAmXMgbXkgaG9wZSB0aGF0IHdlIGNhbiBnZXQgdGhlIGNoYXJ0ZXJpbmcgcHJv Y2VzcyBzdGFydGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPi0tDQo8YnI+DQpUeGF1dGggbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOlR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlR4YXV0aEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHhhdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0NCjxicj4NClR4YXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+VHhhdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_684F4469031B4AB98B53A87597AE012Eamazoncom_-- From nobody Mon Dec 23 18:39:40 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA17D120044 for ; Mon, 23 Dec 2019 18:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-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 uySt8ViBpy95 for ; Mon, 23 Dec 2019 18:39:36 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 BC2BE12002F for ; Mon, 23 Dec 2019 18:39:36 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id t8so15533996iln.4 for ; Mon, 23 Dec 2019 18:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5OOOrFLh4yWXK0Dl4A+/P+OCHmKZMQgzBg4zR4RD9C4=; b=wuEx+9cxY5/g4Aai9OrH5ImBVDEf5J2S/C5S1KW4iVNpBlEp66kFL978IGb8fdqxlq XxwkF8PNFO4rl5ZxR6zY1EnHdwrPqqCtLlJkykh0nT8d1n/fTn75MNC4etOzv9bK8jp1 DdQHdmM+e0ek911rXpoOxZlEMRgyyvsqHNRjLE1NaO2gWeBk4iHqAVnpRnBR6YayaOv0 Nip0Po7Hr90oclJKSjn2R5Zc4RIx733Cj4NuGTpf3l6JoO6tT1ZIjnakVGTXugqF+Voe h1TR6RXhZJh2UlqgDF/ZZ5gGIyV+xQMT3xAT33t0Y9SVORNsxusP+HjxwwlzXAYvW3m/ dlqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5OOOrFLh4yWXK0Dl4A+/P+OCHmKZMQgzBg4zR4RD9C4=; b=GjJtN/hUpB+JtQZqj2K6F1xtm55+6ph67Di3ilg1wRYDnqvVABSorsKJTgAUs2aIWF 80sXmE33r3XsllYHHHXurmRKLCVORjc0TTEQrzln5ONq57vYCS+vpwU76yCYWyv4U00A 8qBud7/4975M41AcYf1WQr1RtQd+JoJn4tFAokQjriSSy2R+7TWdlgFT4PnBVR/nkbpZ nfRdOXrjGk+gHlcVe4c+D7ykBAqKEgSw8njtzKcpa6n8MWLtjPHWWclCIkgf+wjVVX7y NQ5Zhf3H3hMtAjPz1QRo6cMIoejEfMLldZD+Z1PlUeQ5PkH6rlpJaTSVUQsKCsONCEBH EDwA== X-Gm-Message-State: APjAAAVErfq/ZKaxM1bDbXWpWQOa9D2jJrDwxE4iVfq7QzOZ1y0ycvBS FfXF0VPiBv7N0HEpPhnzXS+mk3drhM0= X-Google-Smtp-Source: APXvYqxlLWM4OlWFVVmXfKuKkJ0DrRbWLp80X0353xQyaMjwRDsbmwL8ea4x0GARTTgsBvfEg03hCA== X-Received: by 2002:a92:7606:: with SMTP id r6mr27687743ilc.120.1577155175867; Mon, 23 Dec 2019 18:39:35 -0800 (PST) Received: from mail-il1-f174.google.com (mail-il1-f174.google.com. [209.85.166.174]) by smtp.gmail.com with ESMTPSA id k17sm6776510ioh.64.2019.12.23.18.39.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Dec 2019 18:39:34 -0800 (PST) Received: by mail-il1-f174.google.com with SMTP id t17so15469869ilm.13 for ; Mon, 23 Dec 2019 18:39:34 -0800 (PST) X-Received: by 2002:a92:d18a:: with SMTP id z10mr29200294ilz.48.1577155174406; Mon, 23 Dec 2019 18:39:34 -0800 (PST) MIME-Version: 1.0 References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> In-Reply-To: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> From: Aaron Parecki Date: Mon, 23 Dec 2019 18:39:23 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Justin Richer Cc: Benjamin Kaduk , Yaron Sheffer , "rdd@cert.org" , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000ed235f059a6a0d32" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2019 02:39:40 -0000 --000000000000ed235f059a6a0d32 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I definitely am not trying to discuss specifics of *how* authentication should be included right now, but I just want to make sure it's included in the charter so that we can actually talk about it and it won't be "out of scope" when we eventually do talk about the specifics. Aaron On Mon, Dec 23, 2019 at 1:51 PM Justin Richer wrote: > I=E2=80=99m fine with it being in charter but I do think it should be a c= learly > separate layer, much like OIDC/Facebook Connect/GitHub Login/etc are with > OAuth today. In all of these the authorization is first, and I think that= =E2=80=99s > the right pattern. So if we do take it on we=E2=80=99ll just need to be c= areful how > it=E2=80=99s structured in with everything else. Otherwise, I think the > authentication side can quickly overwhelm and drag down the authorization > side. > > Good news: A lot of the additional stuff in OIDC is there to patch holes > in core OAuth in a common fashion, and we=E2=80=99ll at least be in a pos= ition to > not have to do that again. > > > =E2=80=94 Justin > > On Dec 22, 2019, at 10:46 PM, Aaron Parecki wrote: > > I do think authentication should be part of the charter from the outset. > Frankly the fact that authentication is intentionally left out of OAuth a= nd > has to be bolted on to the side via OpenID Connect is one of the exact > reasons people get confused about the whole space to begin with. > > It's a relatively minor addition to the existing proposed spec to make it > useful as a minimum viable authentication solution, and I'd like to see > that be addressed at the beginning of this work. > > I think we can do this in a smart way and that authentication should be > included in the charter. > > Aaron > > > > > On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer > wrote: > >> Hi Justin, >> >> >> >> I think the charter should mention target use cases. For example, =E2=80= =9Call >> use cases supported by OAuth 2 will be supported by the new protocol=E2= =80=9D or >> =E2=80=9Cthe protocol will support at least use cases X and Y=E2=80=9D. >> >> >> >> And given the importance of OIDC, we could say something like: =E2=80=9C= The >> protocol will allow future extension to support authentication, in an >> analogous way to OpenID Connect. However authentication is explicitly no= t >> part of the initial scope.=E2=80=9D >> >> >> >> Thanks, >> >> Yaron >> >> >> >> *From: *Txauth on behalf of Justin Richer < >> jricher@mit.edu> >> *Date: *Saturday, December 21, 2019 at 00:34 >> *To: * >> *Cc: *"rdd@cert.org" , Benjamin Kaduk >> *Subject: *[Txauth] TxAuth Proposed Charter >> >> >> >> Hi all, >> >> >> >> As discussed in Singapore, no matter what forum TxAuth takes, its work >> will require a new charter. With that in mind, I=E2=80=99ve taken a bit = of time to >> put together a proposed charter text for the TxAuth work: >> >> >> >> This group is chartered to develop a next-generation transactional >> authorization and delegation protocol for HTTP-based APIs and their >> clients. These transactions will allow an authorizing party to delegate = a >> right of access for an API or set of APIs through an authorization serve= r >> to a software client acting on behalf of an authorizing party. >> >> >> >> The group will deliver a protocol specification detailing how a client >> can request and obtain delegated access, how an authorization server can >> provide delegated access, how an authorized party can authorize delegate= d >> access, and how that authorized access can be communicated to the resour= ces >> being protected. These actions will be connected through an explicit >> transaction between the client and authorization server, resulting in an >> artifact that will allow the client to undertake the delegated action. >> >> >> >> Additionally, the delegation process will allow for: >> >> - Fine-grained specification of resource access >> >> - Delegation between multiple users >> >> - Web, mobile, single-page, and other client applications >> >> >> >> The group will define extension points for this protocol to allow for >> flexibility in areas including: >> >> >> >> - Cryptographic agility for keys, message signatures, and proof of >> possession >> >> - User interaction mechanisms including web and non-web methods >> >> - Token presentation mechanisms and key bindings >> >> >> >> The artifacts for this work are not intended or expected to be >> backwards-compatible with OAuth 2.0 and its extensions. >> >> >> >> While this work could be done in within the OAuth working group, I now >> believe that it should be done in a new working group, and that we shoul= d >> try to get that working group up and running prior to the Vancouver meet= ing >> in March. I think this group should stay here on the TxAuth list, and it= =E2=80=99s >> my suggestion that the resulting work be called OAuth 3.0. >> >> >> >> Why a new group? I think that the OAuth working group should remain >> focused on extending, patching, and adapting OAuth 2.0 to a changing wor= ld. >> I plan to be engaged in both groups, and I know most of you are as well, >> but that=E2=80=99s not universal. Since OAuth 2.0 is so established alre= ady, there >> are a LOT of people who aren=E2=80=99t going to be interested in somethi= ng new any >> time soon. But on the other hand, there are a number of people for whom >> OAuth 2.0 does not work, or is at the very least a poor fit, and we=E2= =80=99ll want >> to bring them in at this early stage. So even with significant overlap, = I >> think there=E2=80=99s enough disconnect in the community from both sides= that >> warrants a new group. In addition, I think this is a big enough piece of >> work that it=E2=80=99s simply too much for the OAuth working group to be= able to >> focus on. We wouldn=E2=80=99t be able to get additional meeting time, an= d OAuth >> already has trouble fitting into its two meeting slots as it is. >> >> >> >> I=E2=80=99ve published a blog post detailing more of my rationale: >> >> >> >> >> https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-work= ing-group-d6229ba8e36? >> >> >> >> Please suggest changes to the proposed charter text above. It=E2=80=99s = my hope >> that we can get the chartering process started. >> >> >> >> =E2=80=94 Justin >> >> -- Txauth mailing list Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > -- ---- Aaron Parecki aaronparecki.com @aaronpk --000000000000ed235f059a6a0d32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I definitely am not trying to discuss specifics of *= how* authentication should be included right now, but I just want to make s= ure it's included in the charter so that we can actually talk about it = and it won't be "out of scope" when we eventually do talk abo= ut the specifics.

= Aaron


On Mon, D= ec 23, 2019 at 1:51 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m f= ine with it being in charter but I do think it should be a clearly separate= layer, much like OIDC/Facebook Connect/GitHub Login/etc are with OAuth tod= ay. In all of these the authorization is first, and I think that=E2=80=99s = the right pattern. So if we do take it on we=E2=80=99ll just need to be car= eful how it=E2=80=99s structured in with everything else. Otherwise, I thin= k the authentication side can quickly overwhelm and drag down the authoriza= tion side.

Good news: A lot of the additional stuff in O= IDC is there to patch holes in core OAuth in a common fashion, and we=E2=80= =99ll at least be in a position to not have to do that again.=C2=A0
<= br>

=C2=A0=E2=80=94 Justin

On Dec 22, 2019, at 10:46 PM, Aaron Parecki <aaron@parecki.com> wrote:=

I do think authentication should be p= art of the charter from the outset. Frankly the fact that authentication is= intentionally left out of OAuth and has to be bolted on to the side via Op= enID Connect is one of the exact reasons people get confused about the whol= e space to begin with.=C2=A0

It's a relatively minor addition to the existing proposed sp= ec to make it useful as a minimum viable authentication solution, and I'= ;d like to see that be addressed at the beginning of this work.

I think we can do this in a smart w= ay and that authentication should be included in the charter.

Aaron




On Sat, Dec 21, 20= 19 at 1:51 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
<= p class=3D"MsoNormal">Hi Justin,

=C2=A0

I think the charter should men= tion target use cases. For example, =E2=80=9Call use cases supported by OAu= th 2 will be supported by the new protocol=E2=80=9D or =E2=80=9Cthe protoco= l will support at least use cases X and Y=E2=80=9D.

=C2=A0

And given t= he importance of OIDC, we could say something like: =E2=80=9CThe protocol w= ill allow future extension to support authentication, in an analogous way t= o OpenID Connect. However authentication is explicitly not part of the init= ial scope.=E2=80=9D

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0<= u>

From: Txauth <txauth-bounces@ietf.org&g= t; on behalf of Justin Richer <jricher@mit.edu>
Date: Saturday, December 21, = 2019 at 00:34
To: <txauth@ietf.org>
Cc: "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <<= a href=3D"mailto:kaduk@mit.edu" target=3D"_blank">kaduk@mit.edu>
= Subject: [Txauth] TxAuth Proposed Charter

=C2=A0

Hi all,

=C2= =A0

As discussed in Singapore, = no matter what forum TxAuth takes, its work will require a new charter. Wit= h that in mind, I=E2=80=99ve taken a bit of time to put together a proposed= charter text for the TxAuth work:

=C2=A0

This group is chartered= to develop a next-generation transactional authorization and delegation pr= otocol for HTTP-based APIs and their clients. These transactions will allow= an authorizing party to delegate a right of access for an API or set of AP= Is through an authorization server to a software client acting on behalf of= an authorizing party.=C2=A0

=C2=A0

The group wi= ll deliver a protocol specification detailing how a client can request and = obtain delegated access, how an authorization server can provide delegated = access, how an authorized party can authorize delegated access, and how tha= t authorized access can be communicated to the resources being protected. T= hese actions will be connected through an explicit transaction between the = client and authorization server, resulting in an artifact that will allow t= he client to undertake the delegated action.=C2=A0

<= div>

=C2=A0

Additionally, the delegation process will allow for:

- Fine-grained specification of reso= urce access

- Delegation= between multiple users

= - Web, mobile, single-page, and other client applications

=

=C2=A0

The group will define extension points for this protocol t= o allow for flexibility in areas including:

=C2=A0

- Cryptographic agility for keys, message signatures, and proof of posse= ssion=C2=A0

- User inter= action mechanisms including web and non-web methods

=

- Token presentation mechanisms and key binding= s

=C2=A0

The artifacts for this work are not int= ended or expected to be backwards-compatible with OAuth 2.0 and its extensi= ons.=C2=A0

= =C2=A0

While this work c= ould be done in within the OAuth working group, I now believe that it shoul= d be done in a new working group, and that we should try to get that workin= g group up and running prior to the Vancouver meeting in March. I think thi= s group should stay here on the TxAuth list, and it=E2=80=99s my suggestion= that the resulting work be called OAuth 3.0.=C2=A0

=

=C2=A0

Why a new group? I think that the OAuth working group should rem= ain focused on extending, patching, and adapting OAuth 2.0 to a changing wo= rld. I plan to be engaged in both groups, and I know most of you are as wel= l, but that=E2=80=99s not universal. Since OAuth 2.0 is so established alre= ady, there are a LOT of people who aren=E2=80=99t going to be interested in= something new any time soon. But on the other hand, there are a number of = people for whom OAuth 2.0 does not work, or is at the very least a poor fit= , and we=E2=80=99ll want to bring them in at this early stage. So even with= significant overlap, I think there=E2=80=99s enough disconnect in the comm= unity from both sides that warrants a new group. In addition, I think this = is a big enough piece of work that it=E2=80=99s simply too much for the OAu= th working group to be able to focus on. We wouldn=E2=80=99t be able to get= additional meeting time, and OAuth already has trouble fitting into its tw= o meeting slots as it is.

=C2=A0

I=E2=80=99ve pu= blished a blog post detailing more of my rationale:

=

=C2=A0

=C2=A0<= u>

Please suggest changes to the p= roposed charter text above. It=E2=80=99s my hope that we can get the charte= ring process started.

=C2=A0

=C2=A0=E2=80=94 Jus= tin

-- Txauth mailing list Txauth@ietf.org http= s://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
----
Aaron Parecki


-- =
----
Aaron Parecki

--000000000000ed235f059a6a0d32-- From nobody Tue Dec 24 06:55:17 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71072120116 for ; Tue, 24 Dec 2019 06:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 NVvJJPbtd9oX for ; Tue, 24 Dec 2019 06:55:12 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 2FC651200F7 for ; Tue, 24 Dec 2019 06:55:12 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id f15so15233806lfl.13 for ; Tue, 24 Dec 2019 06:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jzI1qB4WvxxQDzP3wV2QIH78X5Ou6s+z6RM6PfMToao=; b=WduEqDUdwea5BLuSFV/ENg1SYFOMFQePqJ9P/eEj1fKJLVykj/1FpgiQbKh6Ht6wy9 G58Obza0CMjARcoQP4O6d920rDq/Xkkgkjd+Ha18HK5KtRQyZCEsVSbt3sfNc4pRFFe8 Ubr/gijPtPbRnRi8gTsKKbKIiiRB4rlkmeYdDtlqbHkMfqy0iUyO8nF3+A3aPjSGnY74 Oh9VpcQEwmLW2lULz6p6xUoLvUt6faELJBVLQfgXEMlV8/ou8DB1beYbMbh6u4PoJ3vz byc6wewjomT31nwlYWNnFj5xQ7V9fJ2FTcNI+0h06H2d3EtHAFJqakvmKqaYAQBSVpyK 7Rvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jzI1qB4WvxxQDzP3wV2QIH78X5Ou6s+z6RM6PfMToao=; b=jE0D7zvWJleIFb9SKHEkiYL7gcNMvw+ciqtOlIfx7oO4GFqnQrMVlYmLzqENvXTpbb ckRr+mpMFCcP5wM6P9gt3Q89ivcTIXjH4rLQKqNMtRSrWiog8MmGLewC/c1Hwl9x6P+Y fKTCkQzSq+JTxZbuTUeMtfeNtLThV6CyUOsKLX97nOU1cNmEvyoytkZ5aUbbbdw/zJnE ujBcIcQ/37xggS5QH6XOMD19nAUxNQOjJ/w67Do2quaN+LFQ1EzwgyqSrIFlRE0BZ8J9 PIws4hH0moD+o8cdeigRmZopUmTxJBtmsy/O525oz+oRl9lxp9VwzRzOzgaxDcNtLPhY 372A== X-Gm-Message-State: APjAAAVLhSM1s/L/Tmz+aiVC0+8lzJlA9kHR749FgL2Mjn6C19DISZz6 azUn8byVdIHPiymHHel+P3V0coXDwBHEUpmn61WK3P4T7fBFLAv+LSEdsLiTQm+myVoS9CsJthT uV7pibiTUjx7wiVQ= X-Google-Smtp-Source: APXvYqxn3MgATFdE/MtNyFNdLngYt54lh+Hl1txosUpghfhTATuyED/iQ0GHgp4Pj+I2KozZnNYqEVGQYWbdKWuGT+E= X-Received: by 2002:ac2:5592:: with SMTP id v18mr18801348lfg.17.1577199310262; Tue, 24 Dec 2019 06:55:10 -0800 (PST) MIME-Version: 1.0 References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> In-Reply-To: From: Brian Campbell Date: Tue, 24 Dec 2019 07:54:43 -0700 Message-ID: To: Aaron Parecki Cc: Justin Richer , "rdd@cert.org" , Yaron Sheffer , Benjamin Kaduk , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000a0ebbb059a7454b8" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2019 14:55:15 -0000 --000000000000a0ebbb059a7454b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Naming any prospective resulting work here "OAuth 3.0" would significantly exacerbate confusion in the whole space and would be a major disservice to the broader community. On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki wrote: > I definitely am not trying to discuss specifics of *how* authentication > should be included right now, but I just want to make sure it's included = in > the charter so that we can actually talk about it and it won't be "out of > scope" when we eventually do talk about the specifics. > > Aaron > > > > On Mon, Dec 23, 2019 at 1:51 PM Justin Richer wrote: > >> I=E2=80=99m fine with it being in charter but I do think it should be a = clearly >> separate layer, much like OIDC/Facebook Connect/GitHub Login/etc are wit= h >> OAuth today. In all of these the authorization is first, and I think tha= t=E2=80=99s >> the right pattern. So if we do take it on we=E2=80=99ll just need to be = careful how >> it=E2=80=99s structured in with everything else. Otherwise, I think the >> authentication side can quickly overwhelm and drag down the authorizatio= n >> side. >> >> Good news: A lot of the additional stuff in OIDC is there to patch holes >> in core OAuth in a common fashion, and we=E2=80=99ll at least be in a po= sition to >> not have to do that again. >> >> >> =E2=80=94 Justin >> >> On Dec 22, 2019, at 10:46 PM, Aaron Parecki wrote: >> >> I do think authentication should be part of the charter from the outset. >> Frankly the fact that authentication is intentionally left out of OAuth = and >> has to be bolted on to the side via OpenID Connect is one of the exact >> reasons people get confused about the whole space to begin with. >> >> It's a relatively minor addition to the existing proposed spec to make i= t >> useful as a minimum viable authentication solution, and I'd like to see >> that be addressed at the beginning of this work. >> >> I think we can do this in a smart way and that authentication should be >> included in the charter. >> >> Aaron >> >> >> >> >> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer >> wrote: >> >>> Hi Justin, >>> >>> >>> >>> I think the charter should mention target use cases. For example, =E2= =80=9Call >>> use cases supported by OAuth 2 will be supported by the new protocol=E2= =80=9D or >>> =E2=80=9Cthe protocol will support at least use cases X and Y=E2=80=9D. >>> >>> >>> >>> And given the importance of OIDC, we could say something like: =E2=80= =9CThe >>> protocol will allow future extension to support authentication, in an >>> analogous way to OpenID Connect. However authentication is explicitly n= ot >>> part of the initial scope.=E2=80=9D >>> >>> >>> >>> Thanks, >>> >>> Yaron >>> >>> >>> >>> *From: *Txauth on behalf of Justin Richer < >>> jricher@mit.edu> >>> *Date: *Saturday, December 21, 2019 at 00:34 >>> *To: * >>> *Cc: *"rdd@cert.org" , Benjamin Kaduk >>> *Subject: *[Txauth] TxAuth Proposed Charter >>> >>> >>> >>> Hi all, >>> >>> >>> >>> As discussed in Singapore, no matter what forum TxAuth takes, its work >>> will require a new charter. With that in mind, I=E2=80=99ve taken a bit= of time to >>> put together a proposed charter text for the TxAuth work: >>> >>> >>> >>> This group is chartered to develop a next-generation transactional >>> authorization and delegation protocol for HTTP-based APIs and their >>> clients. These transactions will allow an authorizing party to delegate= a >>> right of access for an API or set of APIs through an authorization serv= er >>> to a software client acting on behalf of an authorizing party. >>> >>> >>> >>> The group will deliver a protocol specification detailing how a client >>> can request and obtain delegated access, how an authorization server ca= n >>> provide delegated access, how an authorized party can authorize delegat= ed >>> access, and how that authorized access can be communicated to the resou= rces >>> being protected. These actions will be connected through an explicit >>> transaction between the client and authorization server, resulting in a= n >>> artifact that will allow the client to undertake the delegated action. >>> >>> >>> >>> Additionally, the delegation process will allow for: >>> >>> - Fine-grained specification of resource access >>> >>> - Delegation between multiple users >>> >>> - Web, mobile, single-page, and other client applications >>> >>> >>> >>> The group will define extension points for this protocol to allow for >>> flexibility in areas including: >>> >>> >>> >>> - Cryptographic agility for keys, message signatures, and proof of >>> possession >>> >>> - User interaction mechanisms including web and non-web methods >>> >>> - Token presentation mechanisms and key bindings >>> >>> >>> >>> The artifacts for this work are not intended or expected to be >>> backwards-compatible with OAuth 2.0 and its extensions. >>> >>> >>> >>> While this work could be done in within the OAuth working group, I now >>> believe that it should be done in a new working group, and that we shou= ld >>> try to get that working group up and running prior to the Vancouver mee= ting >>> in March. I think this group should stay here on the TxAuth list, and i= t=E2=80=99s >>> my suggestion that the resulting work be called OAuth 3.0. >>> >>> >>> >>> Why a new group? I think that the OAuth working group should remain >>> focused on extending, patching, and adapting OAuth 2.0 to a changing wo= rld. >>> I plan to be engaged in both groups, and I know most of you are as well= , >>> but that=E2=80=99s not universal. Since OAuth 2.0 is so established alr= eady, there >>> are a LOT of people who aren=E2=80=99t going to be interested in someth= ing new any >>> time soon. But on the other hand, there are a number of people for whom >>> OAuth 2.0 does not work, or is at the very least a poor fit, and we=E2= =80=99ll want >>> to bring them in at this early stage. So even with significant overlap,= I >>> think there=E2=80=99s enough disconnect in the community from both side= s that >>> warrants a new group. In addition, I think this is a big enough piece o= f >>> work that it=E2=80=99s simply too much for the OAuth working group to b= e able to >>> focus on. We wouldn=E2=80=99t be able to get additional meeting time, a= nd OAuth >>> already has trouble fitting into its two meeting slots as it is. >>> >>> >>> >>> I=E2=80=99ve published a blog post detailing more of my rationale: >>> >>> >>> >>> >>> https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-wo= rking-group-d6229ba8e36? >>> >>> >>> >>> >>> Please suggest changes to the proposed charter text above. It=E2=80=99s= my hope >>> that we can get the chartering process started. >>> >>> >>> >>> =E2=80=94 Justin >>> >>> -- Txauth mailing list Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> -- >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> >> -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000a0ebbb059a7454b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Naming any prospective resulting work here "OAut= h 3.0" would significantly exacerbate confusion in the whole space and= would be a major disservice to the broader community.

<= /div>

On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki <aaron@parecki.com> wrote:
I definitely am not trying to discuss specifics of *how* authenticatio= n should be included right now, but I just want to make sure it's inclu= ded in the charter so that we can actually talk about it and it won't b= e "out of scope" when we eventually do talk about the specifics.<= /div>

Aaron



On Mon, Dec 23, 2019 at 1:5= 1 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m fine with it being in charter but I do thi= nk it should be a clearly separate layer, much like OIDC/Facebook Connect/G= itHub Login/etc are with OAuth today. In all of these the authorization is = first, and I think that=E2=80=99s the right pattern. So if we do take it on= we=E2=80=99ll just need to be careful how it=E2=80=99s structured in with = everything else. Otherwise, I think the authentication side can quickly ove= rwhelm and drag down the authorization side.

Good news: = A lot of the additional stuff in OIDC is there to patch holes in core OAuth= in a common fashion, and we=E2=80=99ll at least be in a position to not ha= ve to do that again.=C2=A0


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

On Dec 22, 2= 019, at 10:46 PM, Aaron Parecki <aaron@parecki.com> wrote:

I do think authentication should be part of the charter from the= outset. Frankly the fact that authentication is intentionally left out of = OAuth and has to be bolted on to the side via OpenID Connect is one of the = exact reasons people get confused about the whole space to begin with.=C2= =A0

It's a rel= atively minor addition to the existing proposed spec to make it useful as a= minimum viable authentication solution, and I'd like to see that be ad= dressed at the beginning of this work.

I think we can do this in a smart way and that authenticatio= n should be included in the charter.

Aaron


<= /div>


On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheff= er <yaronf.ie= tf@gmail.com> wrote:

Hi Justin,

=C2=A0

I think the charter should mention target use cases. For example, = =E2=80=9Call use cases supported by OAuth 2 will be supported by the new pr= otocol=E2=80=9D or =E2=80=9Cthe protocol will support at least use cases X = and Y=E2=80=9D.

=C2=A0

And given the importance of OIDC, we could say = something like: =E2=80=9CThe protocol will allow future extension to suppor= t authentication, in an analogous way to OpenID Connect. However authentica= tion is explicitly not part of the initial scope.=E2=80=9D

=C2=A0

Than= ks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

From: Txauth <txauth-bounces@ietf.org&g= t; on behalf of Justin Richer <jricher@mit.edu>
Date: Saturday, December 21, = 2019 at 00:34
To: <txauth@ietf.org>
Cc: "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <<= a href=3D"mailto:kaduk@mit.edu" target=3D"_blank">kaduk@mit.edu>
= Subject: [Txauth] TxAuth Proposed Charter

=C2=A0

Hi all,

=C2= =A0

As discussed in Singapore, = no matter what forum TxAuth takes, its work will require a new charter. Wit= h that in mind, I=E2=80=99ve taken a bit of time to put together a proposed= charter text for the TxAuth work:

=C2=A0

This group is chartered t= o develop a next-generation transactional authorization and delegation prot= ocol for HTTP-based APIs and their clients. These transactions will allow a= n authorizing party to delegate a right of access for an API or set of APIs= through an authorization server to a software client acting on behalf of a= n authorizing party.=C2=A0

=C2=A0

The group will= deliver a protocol specification detailing how a client can request and ob= tain delegated access, how an authorization server can provide delegated ac= cess, how an authorized party can authorize delegated access, and how that = authorized access can be communicated to the resources being protected. The= se actions will be connected through an explicit transaction between the cl= ient and authorization server, resulting in an artifact that will allow the= client to undertake the delegated action.=C2=A0

=C2=A0

Additionally, the delegation process will allow for:<= /p>

- Fine-grained specification of resour= ce access

- Delegation b= etween multiple users

- = Web, mobile, single-page, and other client applications

=C2=A0

The group will define extension points for this protocol to = allow for flexibility in areas including:

=C2=A0

- Cryptographic agility for keys, message signatures, and proof of possess= ion=C2=A0

- User interac= tion mechanisms including web and non-web methods

- Token presentation mechanisms and key bindings<= u>

=C2=A0

=

The artifacts for this work are not inten= ded or expected to be backwards-compatible with OAuth 2.0 and its extension= s.=C2=A0

=C2=A0

While this work cou= ld be done in within the OAuth working group, I now believe that it should = be done in a new working group, and that we should try to get that working = group up and running prior to the Vancouver meeting in March. I think this = group should stay here on the TxAuth list, and it=E2=80=99s my suggestion t= hat the resulting work be called OAuth 3.0.=C2=A0

=C2=A0

Why a new group? I think that the OAuth working group should remai= n focused on extending, patching, and adapting OAuth 2.0 to a changing worl= d. I plan to be engaged in both groups, and I know most of you are as well,= but that=E2=80=99s not universal. Since OAuth 2.0 is so established alread= y, there are a LOT of people who aren=E2=80=99t going to be interested in s= omething new any time soon. But on the other hand, there are a number of pe= ople for whom OAuth 2.0 does not work, or is at the very least a poor fit, = and we=E2=80=99ll want to bring them in at this early stage. So even with s= ignificant overlap, I think there=E2=80=99s enough disconnect in the commun= ity from both sides that warrants a new group. In addition, I think this is= a big enough piece of work that it=E2=80=99s simply too much for the OAuth= working group to be able to focus on. We wouldn=E2=80=99t be able to get a= dditional meeting time, and OAuth already has trouble fitting into its two = meeting slots as it is.

= =C2=A0

I=E2=80=99ve publ= ished a blog post detailing more of my rationale:

=C2=A0

=C2=A0

Please suggest changes to the pr= oposed charter text above. It=E2=80=99s my hope that we can get the charter= ing process started.

= =C2=A0

=C2=A0=E2=80=94 Just= in

-- Txauth mailing list Txauth@ietf.org https= ://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
----
Aaron = Parecki


-- =
----
Aaron Parecki
=

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000a0ebbb059a7454b8-- From nobody Tue Dec 24 16:11:05 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC6612003E for ; Tue, 24 Dec 2019 16:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 ep_7Z3SIihrl for ; Tue, 24 Dec 2019 16:10:59 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 1BAD912008B for ; Tue, 24 Dec 2019 16:10:58 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBP0ApIa021499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Dec 2019 19:10:52 -0500 From: Justin Richer Message-Id: <7CA2CAA2-231D-40B4-BC0E-9CECCB16AE90@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_1C11A5C1-7B8E-498A-972A-3B8E0D485D94" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Dec 2019 19:10:51 -0500 In-Reply-To: <684F4469-031B-4AB9-8B53-A87597AE012E@amazon.com> Cc: Dick Hardt , Eve Maler , "rdd@cert.org" , "txauth@ietf.org" , Benjamin Kaduk To: "Richard Backman, Annabelle" References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> <949341AE-C72B-4645-8F20-699F14529FFB@mit.edu> <78FA3EB7-C72F-4543-95A8-03123F4E40A1@amazon.com> <1FD41975-3CB5-48B6-88D5-6DB7511742CA@mit.edu> <684F4469-031B-4AB9-8B53-A87597AE012E@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 00:11:03 -0000 --Apple-Mail=_1C11A5C1-7B8E-498A-972A-3B8E0D485D94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t think we should write the charter with a specific = solution in mind, but instead describing the problems that we want to = solve with a standard. The =E2=80=9Cwith a standard=E2=80=9D is = important here as not every aspect is going to need a standard = specification, only the parts where we expect communication and = interoperability between implementations, right? I would say that rather the charter should be more general in describing = the purpose and not putting things :out: of scope. It might very well be = that the deployment you=E2=80=99re describing is an optimization, but if = it makes sense within the bounds of the work, even if the details are = described in their own spec (or not in a spec at all, if we decide = that=E2=80=99s one of the =E2=80=9Cunder the hood=E2=80=9D aspects), = then that=E2=80=99s OK. I do agree that what=E2=80=99s really important = here is having an idea of what the different moving parts are, at least = to start. Any proposed ideas on how to describe this without getting = into prescriptive deployment details? =E2=80=94 Justin > On Dec 23, 2019, at 6:22 PM, Richard Backman, Annabelle = wrote: >=20 > The point is, I might want my tokens to be signed using keys that my = TX Endpoint does not have access to. E.g., my token issuer signs tokens = with key A and my TX Endpoint signs HTTP response messages with key B, = neither system has access to the other key, and tokens signed by key B = are rejected by RSes. This requires the working group to understand that = trust boundaries may exist between the different components implementing = portions of =E2=80=9CAS=E2=80=9D behavior. If this isn=E2=80=99t = understood, then if/when I bring up this use case, I=E2=80=99m going to = be told =E2=80=9Cthere are no trust boundaries within an AS, so what = you=E2=80=99re describing isn=E2=80=99t an AS anymore, and not in scope = per the charter.=E2=80=9D > =20 > I=E2=80=99m sensitive to the desire to not overcomplicate things. The = scenario I=E2=80=99m describing is unusual, and probably not what we = should optimize the protocol for (though that could always change). But = we=E2=80=99re talking about charter, not protocol. The charter can be as = detailed and nuanced as it needs to be to properly describe what we are = setting out to accomplish. > =20 > =E2=80=93=20 > Annabelle Richard Backman > AWS Identity > =20 > =20 > From: Justin Richer > Date: Monday, December 23, 2019 at 1:57 PM > To: "Richard Backman, Annabelle" > Cc: Dick Hardt , Eve Maler , = "rdd@cert.org" , "txauth@ietf.org" , = Benjamin Kaduk > Subject: Re: [Txauth] TxAuth Proposed Charter > =20 > So the thing is, I don=E2=80=99t think you need a single JWKS URI = anymore anyway. You=E2=80=99d have one associated with the TxEndpoint, = if you=E2=80=99ve got signed tokens that you need to validate = separately. And if you=E2=80=99re doing signed user assertions, you=E2=80=99= d have a different one identified in the assertion (either directly or = via an issuer-discovery mechanism). Ultimately the client is going to = care about one and the RS about another so it=E2=80=99s fine that = they=E2=80=99re different. We get to define what that looks like.=20 > =20 > On the surface I=E2=80=99m OK with a decomposed AS, to some extent, = but only if there are very, very clear boundaries about what the = individual roles are. And the more roles we make, the more we have to = define what the communication points are in between them. Maybe =E2=80=9CA= S=E2=80=9D is too all-encompassing of a role now, but I=E2=80=99m not = yet convinced that=E2=80=99s true in practice, and I do want someone to = be able to deploy this by having all the =E2=80=9Cserver=E2=80=9D side = functionalities running out of a single, simple box. That might be a = case of that single box needing to play multiple roles, and that=E2=80=99s= OK, but we need to be clear on what kinds of optimizations are = allowable in cases like that. > =20 > I do think there=E2=80=99s precedent in asking this question though, = since between OAuth 1 and 2 we split the =E2=80=9Cserver=E2=80=9D into = =E2=80=9CAS and RS=E2=80=9D. OAuth 2 famously didn=E2=80=99t define a = connection point between them until much later (JWT and Introspection), = but that pattern seems to have mostly worked. > =20 > =E2=80=94 Justin >=20 >=20 >> On Dec 22, 2019, at 11:52 PM, Richard Backman, Annabelle = > wrote: >> =20 >> My example demonstrates an architecture where the TX Endpoint, = authentication system, and token issuer aren=E2=80=99t simply different = micro services, they=E2=80=99re completely independent systems in = different trust boundaries, possibly have different domains and = different keys. This has implications for protocol design. For example, = it would no longer be sufficient to have a single jwks_uri, as OAuth 2.0 = has. >>=20 >>=20 >> If we want to support this kind of =E2=80=9Cdecomposed AS=E2=80=9D = model, then we need to make sure that=E2=80=99s supported by the charter = and keep it in mind as we design the protocol. We can also decide it is = out of scope, but we should be intentional about that decision. >>=20 >> =20 >> To my mind, this role decomposition is the next logical step after = the channel decomposition that TxAuth already does. I see a lot of = potential in it and think we should at minimum avoid closing the door on = it. >>=20 >>=20 >>> On Dec 22, 2019, at 5:35 PM, Justin Richer > wrote: >>>=20 >>> I think you=E2=80=99re conflating the roles that different = components play, in regard to the other components, with the potential = deployment of those components. The spec needs to be written in terms of = the roles. While the roles do need to consider what potential = deployments might be, it=E2=80=99s important that we write things in in = terms of how they interact with each other and not in terms of how they = might look under the covers. >>> =20 >>> So from the clients perspective, the TX Endpoint :is: the AS. The = client doesn=E2=80=99t care that it=E2=80=99s a =E2=80=9Cglorified = message queue=E2=80=9D or if it=E2=80=99s a massive server farm. The = client doesn=E2=80=99t care if there=E2=80=99s a TLS reverse proxy or if = it=E2=80=99s talking directly to the application layer. The only thing = the client cares about is if the TX Endpoint does the things that a TX = Endpoint is supposed to do, and we define that to be the function of the = AS.=20 >>> =20 >>> What=E2=80=99s important in your scenario below is that the client = would have to talk to the RS first every time. That=E2=80=99s one of the = problems that UMA has, and I think something we should avoid. I think = RS-first is an interesting pattern but AS-first ought to drive this.=20 >>> =20 >>> With your hypothetical layout below, it really sounds like the TX = Endpoint is a function of the IDP, which is fine. The client doesn=E2=80=99= t care that it=E2=80=99s deployed using some externalized cloud service. = The only weird thing going on is the push from the AS back to the = client. The client would need to register that with the AS (or through = the AS more specifically) as part of its transaction request. This would = be part of its interaction mechanism, because =E2=80=9Chow you get = messages and updates back to the client=E2=80=9D is part of the = interaction model.=20 >>> =20 >>> So for an RS-first transaction, the client calls the RS: >>> =20 >>> GET /foo >>> =20 >>> The RS returns a resource handle, but the client doesn=E2=80=99t = care where that came from. The RS could talk to the AS to get it. = Probably a new endpoint of some kind, can probably use the same kinds of = key binding that the TX Endpoint has. Or the RS can make one up that the = TX Endpoint can recognize. Or it calls the IdP to get one. The client = doesn=E2=80=99t care, and that=E2=80=99s the key point.=20 >>> =20 >>> WWW-Authenticate tx_endpoint=3D=E2=80=9Chttp://server//tx = =E2=80=9D resource: =E2=80=9Casdf1234=E2=80=9D >>> =20 >>> The client calls the TX endpoint like a normal transaction: >>> =20 >>> POST /tx >>> =20 >>> { >>> resources: [ =E2=80=9Casdf1234=E2=80=9D ], >>> interact: { >>> redirect: true, >>> push: =E2=80=9Chttp://client/push/9876 = =E2=80=9D >>> } >>> } >>> =20 >>> The AS (which is to say the TX Endpoint) tells the client to send = the user agent to the IdP >>> =20 >>> { >>> interact_url: =E2=80=9Chttp://idp/login =E2=80=9D,= >>> handle: { value: =E2=80=9Chjkl=E2=80=9D, type: bearer } >>> } >>> =20 >>> Now the client could poll the TX Endpoint but it could also just sit = and wait for an update to be pushed in.=20 >>> =20 >>> There are probably things that need to be tied together for this to = be secure, but I think the basic pattern still fits. Importantly, the = client doesn=E2=80=99t care whereby of that stuff came from =E2=80=94 as = far as it=E2=80=99s concerned, it=E2=80=99s talking to the AS.=20 >>> =20 >>> Remember, the =E2=80=9CAS=E2=80=9D is a logical construct, not a = physical one. Just like the =E2=80=9Cclient=E2=80=9D could be a cluster = of applications and the =E2=80=9CRS=E2=80=9D could be a suite of APIs = tied behind a gateway. >>> =20 >>> =E2=80=94 Justin >>> =20 >>>=20 >>>=20 >>>> On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle = > wrote: >>>> =20 >>>> =20 >>>>> On Dec 21, 2019, at 4:42 AM, Justin Richer > wrote: >>>> =20 >>>>> Even if the client starts at the RS, the client still has to go = talk to the AS. I haven=E2=80=99t built this out, but I see it working = somewhat like UMA. In XYZ=E2=80=99s terms: >>>>> =20 >>>>> =20 >>>>> 1. Client calls the RS trying to Do A Thing >>>>> 2. RS calls the AS requesting a Resource Handle (because that=E2=80=99= s what the RS represents, resources) =E2=80=94 at least good enough to = cover what the client tried to do, could be more >>>>> 3. RS gives the Resource Handle and AS Transaction Endpoint back = to the client >>>>> 4. Client calls the AS Transaction Endpoint to start a = transaction, includes the Resource Handle as part of its request (note: = doesn=E2=80=99t have to be the whole resource section, client can add = stuff) >>>>> 5. Process continues as normal >>>> =20 >>>> It depends on what you consider the =E2=80=9CAS=E2=80=9D. Consider = the following hypothetical architecture: >>>> =20 >>>> =E2=80=A2 The RS, client, and tx endpoint are on the public = Internet. >>>> =E2=80=A2 The tx endpoint returns interaction urls that point to an = IdP that is inaccessible from the public Internet. >>>> =E2=80=A2 The user agent can reach the IdP, but none of the other = systems can. >>>> =E2=80=A2 When the UA is redirected to the IdP, the IdP calls the = tx endpoint system to retrieve transaction details. >>>> =E2=80=A2 When authorization is granted, the IdP pushes artifacts = directly to an endpoint provided by the client. >>>> =20 >>>> In this example, the client only interacts with the RS and the tx = endpoint. It seems odd to me to consider the system hosting the tx = endpoint to be the AS (or at least part of the AS), as its a glorified = message queue with essentially no authority in this architecture.=20 >>>> =20 >>>> We could go a step further and remove the client=E2=80=99s = interaction with the tx endpoint by having the RS return the interaction = url directly (you=E2=80=99d need to secure the client nonce if you want = to hide it from the RS, but that=E2=80=99s not that hard). >>>> =20 >>>> Is the meaning of =E2=80=9Cauthorization server=E2=80=9D (or the = phrase =E2=80=9Cthrough an authorization server=E2=80=9D) flexible = enough to accommodate these cases? Or are they considered out of scope = for TxAuth? >>>> =20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>>=20 >>>>>> =20 >>>>>> As I said, maybe I=E2=80=99m being too literal. >>>>>>=20 >>>>>>=20 >>>>>>> =E1=90=A7 >>>>>>> On Fri, Dec 20, 2019 at 5:08 PM Richard Backman, Annabelle = > wrote: >>>>>>>> I=E2=80=99m not sure if this is what Eve had in mind, but = consider an automated system in an enterprise context that has been = authorized by an administrator. The automated system isn=E2=80=99t = acting as or on behalf of the administrator, and the administrator = hasn=E2=80=99t =E2=80=9Cdelegated access=E2=80=9D; they=E2=80=99ve = granted access, just as they do when they assign permissions to = users/groups/roles/etc. >>>>>>>> Maybe I=E2=80=99m being too literal, but =E2=80=9Cthrough an = authorization server=E2=80=9D in paragraph 1 implies a specific = context/information/request flow to me. Given that one of TxAuth=E2=80=99s= features is decoupling the different communication channels, we should = not suggest that the client or authorizing party is directly interacting = with the AS. >>>>>>>> =20 >>>>>>>> =E2=80=93=20 >>>>>>>> Annabelle Richard Backman >>>>>>>> AWS Identity >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> From: Txauth > on behalf of Dick Hardt = > >>>>>>>> Date: Friday, December 20, 2019 at 4:14 PM >>>>>>>> To: Eve Maler > >>>>>>>> Cc: "rdd@cert.org " >, "txauth@ietf.org " = >, Justin Richer = >, Benjamin Kaduk = > >>>>>>>> Subject: Re: [Txauth] TxAuth Proposed Charter >>>>>>>> =20 >>>>>>>> Eve: do you not think the software client is acting on behalf = of some party? Or do you think that software always is acting on behalf = of some party, and the mentioned phrase is redundant?=20 >>>>>>>> =20 >>>>>>>> Justin: a couple questions >>>>>>>> =20 >>>>>>>> 1. What is meant by "Delegation between multiple users" ? >>>>>>>> =20 >>>>>>>> 2. Why do you restrict this to HTTP? >>>>>>>> =20 >>>>>>>> 3. Why is authentication not in scope? >>>>>>>> =20 >>>>>>>> 4. When you say "not backwards compatible with OAuth 2.0 and = its extensions", do you expect to define a new standard to replace RFC = 6750? Developers will have to have a new method to call APIs? >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> On Fri, Dec 20, 2019 at 3:27 PM Eve Maler > wrote: >>>>>>>>> Re =E2=80=9Cto a software client _acting on behalf of an = authorizing party_=E2=80=9D: There is a whole lot of philosophy behind = whom the delegated access is performed on behalf of, unless the scenario = is single-user or some "act as" semantic is spelled out on the wire. = Does it need to be stated here? What's the consequence if the = highlighted phrase were removed?=20 >>>>>>>>>=20 >>>>>>>>> Eve Maler (sent from my iPad) | cell +1 425 345 6756 >>>>>>>>> =20 >>>>>>>>>=20 >>>>>>>>>> On Dec 20, 2019, at 4:34 PM, Justin Richer > wrote: >>>>>>>>>>=20 >>>>>>>>>> Hi all, >>>>>>>>>> =20 >>>>>>>>>> As discussed in Singapore, no matter what forum TxAuth takes, = its work will require a new charter. With that in mind, I=E2=80=99ve = taken a bit of time to put together a proposed charter text for the = TxAuth work: >>>>>>>>>> =20 >>>>>>>>>>> This group is chartered to develop a next-generation = transactional authorization and delegation protocol for HTTP-based APIs = and their clients. These transactions will allow an authorizing party to = delegate a right of access for an API or set of APIs through an = authorization server to a software client acting on behalf of an = authorizing party.=20 >>>>>>>>>>> =20 >>>>>>>>>>> The group will deliver a protocol specification detailing = how a client can request and obtain delegated access, how an = authorization server can provide delegated access, how an authorized = party can authorize delegated access, and how that authorized access can = be communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>>>>>>>>>> =20 >>>>>>>>>>> Additionally, the delegation process will allow for: >>>>>>>>>>> - Fine-grained specification of resource access >>>>>>>>>>> - Delegation between multiple users >>>>>>>>>>> - Web, mobile, single-page, and other client applications >>>>>>>>>>> =20 >>>>>>>>>>> The group will define extension points for this protocol to = allow for flexibility in areas including: >>>>>>>>>>> =20 >>>>>>>>>>> - Cryptographic agility for keys, message signatures, and = proof of possession=20 >>>>>>>>>>> - User interaction mechanisms including web and non-web = methods >>>>>>>>>>> - Token presentation mechanisms and key bindings >>>>>>>>>>> =20 >>>>>>>>>>> The artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 and its extensions.=20 >>>>>>>>>> =20 >>>>>>>>>> While this work could be done in within the OAuth working = group, I now believe that it should be done in a new working group, and = that we should try to get that working group up and running prior to the = Vancouver meeting in March.. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>>>>>>>>> =20 >>>>>>>>>> Why a new group? I think that the OAuth working group should = remain focused on extending, patching, and adapting OAuth 2.0 to a = changing world. I plan to be engaged in both groups, and I know most of = you are as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>>>>>>>>> =20 >>>>>>>>>> I=E2=80=99ve published a blog post detailing more of my = rationale: >>>>>>>>>> =20 >>>>>>>>>> = https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? = >>>>>>>>>> =20 >>>>>>>>>> Please suggest changes to the proposed charter text above. = It=E2=80=99s my hope that we can get the chartering process started. >>>>>>>>>> =20 >>>>>>>>>> =E2=80=94 Justin >>>>>>>>>> --=20 >>>>>>>>>> Txauth mailing list >>>>>>>>>> Txauth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>>>>> --=20 >>>>>>>>> Txauth mailing list >>>>>>>>> Txauth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_1C11A5C1-7B8E-498A-972A-3B8E0D485D94 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = don=E2=80=99t think we should write the charter with a specific solution = in mind, but instead describing the problems that we want to solve with = a standard. The =E2=80=9Cwith a standard=E2=80=9D is important here as = not every aspect is going to need a standard specification, only the = parts where we expect communication and interoperability between = implementations, right?

I would say that rather the charter should be more general in = describing the purpose and not putting things :out: of scope. It might = very well be that the deployment you=E2=80=99re describing is an = optimization, but if it makes sense within the bounds of the work, even = if the details are described in their own spec (or not in a spec at all, = if we decide that=E2=80=99s one of the =E2=80=9Cunder the hood=E2=80=9D = aspects), then that=E2=80=99s OK. I do agree that what=E2=80=99s really = important here is having an idea of what the different moving parts are, = at least to start. Any proposed ideas on how to describe this without = getting into prescriptive deployment details?

 =E2=80=94 Justin

On Dec 23, 2019, at 6:22 PM, Richard Backman, Annabelle = <richanna@amazon.com> wrote:

The point = is, I might want my tokens to be signed using keys that my TX Endpoint = does not have access to. E.g., my token issuer signs tokens with key A = and my TX Endpoint signs HTTP response messages with key B, neither = system has access to the other key, and tokens signed by key B are = rejected by RSes. This requires the working group to understand that = trust boundaries may exist between the different components implementing = portions of =E2=80=9CAS=E2=80=9D behavior. If this isn=E2=80=99t = understood, then if/when I bring up this use case, I=E2=80=99m going to = be told =E2=80=9Cthere are no trust boundaries within an AS, so what = you=E2=80=99re describing isn=E2=80=99t an AS anymore, and not in scope = per the charter.=E2=80=9D
 
I=E2=80=99m sensitive to the desire to not overcomplicate = things. The scenario I=E2=80=99m describing is unusual, and probably not = what we should optimize the protocol for (though that could always = change). But we=E2=80=99re talking about charter, = not protocol. The charter can be as detailed and nuanced as = it needs to be to properly describe what we are setting out to = accomplish.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: Justin Richer <jricher@mit.edu>
Date: Monday, December 23, = 2019 at 1:57 PM
To: "Richard Backman, = Annabelle" <richanna@amazon.com>
Cc: Dick = Hardt <dick.hardt@gmail.com>, Eve Maler <eve@xmlgrrl.com>, "rdd@cert.org" <rdd@cert.org>, "txauth@ietf.org" <txauth@ietf.org>, = Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: [Txauth] TxAuth = Proposed Charter
 
So the thing is, I don=E2=80=99t think you need a single JWKS = URI anymore anyway. You=E2=80=99d have one associated with the = TxEndpoint, if you=E2=80=99ve got signed tokens that you need to = validate separately. And if you=E2=80=99re doing signed user assertions, = you=E2=80=99d have a different one identified in the assertion (either = directly or via an issuer-discovery mechanism). Ultimately the client is = going to care about one and the RS about another so it=E2=80=99s fine = that they=E2=80=99re different. We get to define what that looks = like. 
 
On the surface I=E2=80=99m OK with a decomposed AS, to some = extent, but only if there are very, very clear boundaries about what the = individual roles are. And the more roles we make, the more we have to = define what the communication points are in between them. Maybe =E2=80=9CA= S=E2=80=9D is too all-encompassing of a role now, but I=E2=80=99m not = yet convinced that=E2=80=99s true in practice, and I do want someone to = be able to deploy this by having all the =E2=80=9Cserver=E2=80=9D side = functionalities running out of a single, simple box. That might be a = case of that single box needing to play multiple roles, and that=E2=80=99s= OK, but we need to be clear on what kinds of optimizations are = allowable in cases like that.
 
I do think there=E2=80=99s precedent in asking this question = though, since between OAuth 1 and 2 we split the =E2=80=9Cserver=E2=80=9D = into =E2=80=9CAS and RS=E2=80=9D. OAuth 2 famously didn=E2=80=99t define = a connection point between them until much later (JWT and = Introspection), but that pattern seems to have mostly worked.
 
 =E2=80=94 Justin


On Dec 22, 2019, at 11:52 PM, Richard = Backman, Annabelle <richanna@amazon.com> wrote:
 
My example demonstrates an architecture = where the TX Endpoint, authentication system, and token issuer aren=E2=80=99= t simply different micro services, they=E2=80=99re completely = independent systems in different trust boundaries, possibly have = different domains and different keys. This has implications for protocol = design. For example, it would no longer be sufficient to have a single = jwks_uri, as OAuth 2.0 has.


If we want to support this kind of = =E2=80=9Cdecomposed AS=E2=80=9D model, then we need to make sure = that=E2=80=99s supported by the charter and keep it in mind as we design = the protocol. We can also decide it is out of scope, but we should be = intentional about that decision.

 
To my mind, this role decomposition is = the next logical step after the channel decomposition that TxAuth = already does. I see a lot of potential in it and think we should at = minimum avoid closing the door on it.


On Dec 22, 2019, at 5:35 PM, Justin Richer <jricher@mit.edu> wrote:

I think you=E2=80=99re conflating = the roles that different components play, in regard to = the other components, with the potential deployment of those components. = The spec needs to be written in terms of the roles. While the roles do = need to consider what potential deployments might be, it=E2=80=99s = important that we write things in in terms of how they interact with = each other and not in terms of how they might look under the covers.
 
So from the clients perspective, the TX = Endpoint :is: the AS. The client doesn=E2=80=99t care that it=E2=80=99s = a =E2=80=9Cglorified message queue=E2=80=9D or if it=E2=80=99s a massive = server farm. The client doesn=E2=80=99t care if there=E2=80=99s a TLS = reverse proxy or if it=E2=80=99s talking directly to the application = layer. The only thing the client cares about is if the TX Endpoint does = the things that a TX Endpoint is supposed to do, and we define that to = be the function of the AS. 
 
What=E2=80=99s important in your scenario below is that the = client would have to talk to the RS first every time. That=E2=80=99s one = of the problems that UMA has, and I think something we should avoid. I = think RS-first is an interesting pattern but AS-first ought to drive = this. 
 
With your hypothetical layout below, it really sounds like = the TX Endpoint is a function of the IDP, which is fine. The client = doesn=E2=80=99t care that it=E2=80=99s deployed using some externalized = cloud service. The only weird thing going on is the push from the AS = back to the client. The client would need to register that with the AS = (or through the AS more specifically) as part of its transaction = request. This would be part of its interaction mechanism, because =E2=80=9C= how you get messages and updates back to the client=E2=80=9D is part of = the interaction model. 
 
So for an RS-first transaction, the client calls the RS:
 
GET /foo
 
The RS returns a resource handle, but = the client doesn=E2=80=99t care where that came from. The RS could talk = to the AS to get it. Probably a new endpoint of some kind, can probably = use the same kinds of key binding that the TX Endpoint has. Or the RS = can make one up that the TX Endpoint can recognize. Or it calls the IdP = to get one. The client doesn=E2=80=99t care, and that=E2=80=99s the key = point. 
 
WWW-Authenticate tx_endpoint=3D=E2=80=9Chttp://server//tx=E2=80=9D = resource: =E2=80=9Casdf1234=E2=80=9D
 
The client calls the TX endpoint like a normal = transaction:
 
POST /tx
 
{
  resources: [ =E2=80=9Casdf1234=E2=80= =9D ],
  interact: {
    redirect: true,
    push: =E2=80=9Chttp://client/push/9876=E2=80=9D=
  }
}
 
The AS (which is to say the TX Endpoint) tells the client to = send the user agent to the IdP
 
{
  interact_url: =E2=80=9Chttp://idp/login=E2=80=9D,
  handle: { value: =E2=80=9Chjkl=E2=80=9D, type: bearer = }
}
 
Now the client could poll the TX Endpoint but it could also = just sit and wait for an update to be pushed in. 
 
There are probably things that need to = be tied together for this to be secure, but I think the basic pattern = still fits. Importantly, the client doesn=E2=80=99t care whereby of that = stuff came from =E2=80=94 as far as it=E2=80=99s concerned, it=E2=80=99s = talking to the AS. 
 
Remember, the =E2=80=9CAS=E2=80=9D is a logical construct, = not a physical one. Just like the =E2=80=9Cclient=E2=80=9D could be a = cluster of applications and the =E2=80=9CRS=E2=80=9D could be a suite of = APIs tied behind a gateway.
 
 =E2=80=94 Justin
 


On Dec 22, 2019, at 1:05 AM, Richard = Backman, Annabelle <richanna@amazon.com> wrote:
 
 
On Dec = 21, 2019, at 4:42 AM, Justin Richer <jricher@mit.edu> wrote:
 
Even if the client starts at the RS, = the client still has to go talk to the AS. I haven=E2=80=99t built this = out, but I see it working somewhat like UMA. In XYZ=E2=80=99s terms:
 
 
1. Client calls the RS trying to Do A Thing
2. RS calls the AS requesting a Resource Handle (because = that=E2=80=99s what the RS represents, resources) =E2=80=94 at least = good enough to cover what the client tried to do, could be more
3. RS gives the Resource Handle and AS Transaction Endpoint = back to the client
4. Client calls the AS Transaction = Endpoint to start a transaction, includes the Resource Handle as part of = its request (note: doesn=E2=80=99t have to be the whole resource = section, client can add stuff)
5. Process continues as = normal
 
It depends on what you consider the =E2=80=9CAS=E2=80=9D. = Consider the following hypothetical architecture:
 
=E2=80=A2 The RS, client, and tx = endpoint are on the public Internet.
=E2=80=A2 The tx endpoint = returns interaction urls that point to an IdP that is inaccessible from = the public Internet.
=E2=80=A2 The user agent can reach the = IdP, but none of the other systems can.
=E2=80=A2 When the UA is redirected to the IdP, the IdP calls = the tx endpoint system to retrieve transaction details.
=E2=80=A2 When authorization is granted, the IdP pushes = artifacts directly to an endpoint provided by the client.
 
In this example, the client only = interacts with the RS and the tx endpoint. It seems odd to me to = consider the system hosting the tx endpoint to be the AS (or at least = part of the AS), as its a glorified message queue with essentially no = authority in this architecture. 
 
We could go a step further and remove = the client=E2=80=99s interaction with the tx endpoint by having the RS = return the interaction url directly (you=E2=80=99d need to secure the = client nonce if you want to hide it from the RS, but that=E2=80=99s not = that hard).
 
Is the meaning of =E2=80=9Cauthorization server=E2=80=9D (or = the phrase =E2=80=9Cthrough an authorization server=E2=80=9D) flexible = enough to accommodate these cases? Or are they considered out of scope = for TxAuth?
 
 =E2=80= =94 Justin


 
As I said, maybe I=E2=80=99m being too literal.


=E1=90=A7
On Fri, = Dec 20, 2019 at 5:08 PM Richard Backman, Annabelle <richanna@amazon.com> = wrote:
I=E2=80=99m not sure if = this is what Eve had in mind, but consider an automated system in an = enterprise context that has been authorized by an administrator. The = automated system isn=E2=80=99t acting as or on behalf of the = administrator, and the administrator hasn=E2=80=99t =E2=80=9Cdelegated = access=E2=80=9D; they=E2=80=99ve granted access, just as they do = when they assign permissions to users/groups/roles/etc.
Maybe = I=E2=80=99m being too literal, but =E2=80=9Cthrough an authorization = server=E2=80=9D in paragraph 1 implies a specific = context/information/request flow to me. Given that one of TxAuth=E2=80=99s= features is decoupling the different communication channels, we should = not suggest that the client or authorizing party is directly interacting = with the AS.
 
=E2=80=93 
Annabelle Richard Backman
AWS Identity
 
 
From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
Date: Friday, December 20, = 2019 at 4:14 PM
To: Eve Maler <eve@xmlgrrl.com>Cc: "rdd@cert.org" <rdd@cert.org>, "txauth@ietf.org" = <txauth@ietf.org>, = Justin Richer <jricher@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: [Txauth] TxAuth = Proposed Charter
 
Eve: do you not think the software = client is acting on behalf of some party? Or do you think that software = always is acting on behalf of some party, and the mentioned phrase is = redundant? 
 
Justin: a couple questions
 
1. What is meant by "Delegation between = multiple users" ?
 
2. Why do you restrict this to HTTP?
 
3. Why is authentication not in = scope?
 
4. When you say "not backwards compatible with OAuth 2.0 and = its extensions", do you expect to define a new standard to replace RFC = 6750? Developers will have to have a new method to call APIs?
 
 
On Fri, Dec 20, 2019 at = 3:27 PM Eve Maler <eve@xmlgrrl.com> wrote:

Re =E2=80=9Cto a software client _acting on behalf of an authorizing = party_=E2=80=9D: There is a whole lot of philosophy behind whom the = delegated access is performed on behalf of, unless the scenario is = single-user or some "act as" semantic is spelled out on the wire. Does = it need to be stated here? What's the consequence if the highlighted = phrase were removed? 

Eve Maler (sent from my iPad) = | cell +1 425 345 6756

 

On Dec 20, 2019, at 4:34 PM, Justin = Richer <jricher@mit.edu> wrote:

Hi all,
 
As discussed in Singapore, no matter what forum TxAuth takes, = its work will require a new charter. With that in mind, I=E2=80=99ve = taken a bit of time to put together a proposed charter text for the = TxAuth work:
 
This group is chartered to develop a next-generation = transactional authorization and delegation protocol for HTTP-based APIs = and their clients. These transactions will allow an authorizing party to = delegate a right of access for an API or set of APIs through an = authorization server to a software client acting on behalf of an = authorizing party. 
 
The group will deliver a protocol specification detailing how = a client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action. 
 
Additionally, the delegation process = will allow for:
- Fine-grained specification of = resource access
- Delegation between multiple users
- Web, mobile, single-page, and other client applications
 
The group will define extension points = for this protocol to allow for flexibility in areas including:
 
- Cryptographic agility for keys, = message signatures, and proof of possession 
- User interaction mechanisms including web and non-web = methods
- Token presentation mechanisms and key = bindings
 
The artifacts for this work are not intended or expected to = be backwards-compatible with OAuth 2.0 and its extensions. 
 
While this work could be done in within the OAuth working = group, I now believe that it should be done in a new working group, and = that we should try to get that working group up and running prior to the = Vancouver meeting in March.. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0. 
 
Why a new group? I think that the OAuth working group should = remain focused on extending, patching, and adapting OAuth 2.0 to a = changing world. I plan to be engaged in both groups, and I know most of = you are as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is.
 
I=E2=80=99ve published a blog post = detailing more of my rationale:
 
 
Please suggest changes to the proposed charter text above. = It=E2=80=99s my hope that we can get the chartering process started.
 
 =E2=80=94 Justin
-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
<= /div>
<= /blockquote>
= --Apple-Mail=_1C11A5C1-7B8E-498A-972A-3B8E0D485D94-- From nobody Tue Dec 24 16:11:33 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B38F12008B for ; Tue, 24 Dec 2019 16:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 lMbBLXxt86zB for ; Tue, 24 Dec 2019 16:11:29 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 8FAC512003E for ; Tue, 24 Dec 2019 16:11:28 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBP0ApIb021499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Dec 2019 19:11:25 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C8A047A1-B161-4B38-916B-918BA9D8F868" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Dec 2019 19:11:25 -0500 In-Reply-To: Cc: Benjamin Kaduk , Yaron Sheffer , "rdd@cert.org" , txauth@ietf.org To: Aaron Parecki References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 00:11:31 -0000 --Apple-Mail=_C8A047A1-B161-4B38-916B-918BA9D8F868 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m personally fine with that position. =E2=80=94 Justin > On Dec 23, 2019, at 9:39 PM, Aaron Parecki wrote: >=20 > I definitely am not trying to discuss specifics of *how* = authentication should be included right now, but I just want to make = sure it's included in the charter so that we can actually talk about it = and it won't be "out of scope" when we eventually do talk about the = specifics. >=20 > Aaron >=20 >=20 >=20 > On Mon, Dec 23, 2019 at 1:51 PM Justin Richer > wrote: > I=E2=80=99m fine with it being in charter but I do think it should be = a clearly separate layer, much like OIDC/Facebook Connect/GitHub = Login/etc are with OAuth today. In all of these the authorization is = first, and I think that=E2=80=99s the right pattern. So if we do take it = on we=E2=80=99ll just need to be careful how it=E2=80=99s structured in = with everything else. Otherwise, I think the authentication side can = quickly overwhelm and drag down the authorization side. >=20 > Good news: A lot of the additional stuff in OIDC is there to patch = holes in core OAuth in a common fashion, and we=E2=80=99ll at least be = in a position to not have to do that again.=20 >=20 >=20 > =E2=80=94 Justin >=20 >> On Dec 22, 2019, at 10:46 PM, Aaron Parecki > wrote: >>=20 >> I do think authentication should be part of the charter from the = outset. Frankly the fact that authentication is intentionally left out = of OAuth and has to be bolted on to the side via OpenID Connect is one = of the exact reasons people get confused about the whole space to begin = with.=20 >>=20 >> It's a relatively minor addition to the existing proposed spec to = make it useful as a minimum viable authentication solution, and I'd like = to see that be addressed at the beginning of this work. >>=20 >> I think we can do this in a smart way and that authentication should = be included in the charter. >>=20 >> Aaron >>=20 >>=20 >>=20 >>=20 >> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer > wrote: >> Hi Justin, >>=20 >> =20 >>=20 >> I think the charter should mention target use cases. For example, = =E2=80=9Call use cases supported by OAuth 2 will be supported by the new = protocol=E2=80=9D or =E2=80=9Cthe protocol will support at least use = cases X and Y=E2=80=9D. >>=20 >> =20 >>=20 >> And given the importance of OIDC, we could say something like: =E2=80=9C= The protocol will allow future extension to support authentication, in = an analogous way to OpenID Connect. However authentication is explicitly = not part of the initial scope.=E2=80=9D >>=20 >> =20 >>=20 >> Thanks, >>=20 >> Yaron >>=20 >> =20 >>=20 >> From: Txauth > on behalf of Justin Richer = > >> Date: Saturday, December 21, 2019 at 00:34 >> To: > >> Cc: "rdd@cert.org " >, Benjamin Kaduk > >> Subject: [Txauth] TxAuth Proposed Charter >>=20 >> =20 >>=20 >> Hi all, >>=20 >> =20 >>=20 >> As discussed in Singapore, no matter what forum TxAuth takes, its = work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of time to put together a proposed charter text for the TxAuth work: >>=20 >> =20 >>=20 >> This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 >>=20 >> =20 >>=20 >> The group will deliver a protocol specification detailing how a = client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>=20 >> =20 >>=20 >> Additionally, the delegation process will allow for: >>=20 >> - Fine-grained specification of resource access >>=20 >> - Delegation between multiple users >>=20 >> - Web, mobile, single-page, and other client applications >>=20 >> =20 >>=20 >> The group will define extension points for this protocol to allow for = flexibility in areas including: >>=20 >> =20 >>=20 >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >>=20 >> - User interaction mechanisms including web and non-web methods >>=20 >> - Token presentation mechanisms and key bindings >>=20 >> =20 >>=20 >> The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >>=20 >> =20 >>=20 >> While this work could be done in within the OAuth working group, I = now believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>=20 >> =20 >>=20 >> Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing = world. I plan to be engaged in both groups, and I know most of you are = as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>=20 >> =20 >>=20 >> I=E2=80=99ve published a blog post detailing more of my rationale: >>=20 >> =20 >>=20 >> = https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? = >> =20 >>=20 >> Please suggest changes to the proposed charter text above. It=E2=80=99s= my hope that we can get the chartering process started. >>=20 >> =20 >>=20 >> =E2=80=94 Justin >>=20 >> -- Txauth mailing list Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth = --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> --=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=20 >=20 > --=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 --Apple-Mail=_C8A047A1-B161-4B38-916B-918BA9D8F868 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m personally fine with that position.

 =E2=80=94 Justin

On Dec 23, 2019, at 9:39 PM, Aaron Parecki <aaron@parecki.com> = wrote:

I definitely am = not trying to discuss specifics of *how* authentication should be = included right now, but I just want to make sure it's included in the = charter so that we can actually talk about it and it won't be "out of = scope" when we eventually do talk about the specifics.

Aaron



On Mon, Dec 23, 2019 at 1:51 PM Justin Richer = <jricher@mit.edu> = wrote:
I=E2=80=99m fine with it being in charter but I do think it = should be a clearly separate layer, much like OIDC/Facebook = Connect/GitHub Login/etc are with OAuth today. In all of these the = authorization is first, and I think that=E2=80=99s the right pattern. So = if we do take it on we=E2=80=99ll just need to be careful how it=E2=80=99s= structured in with everything else. Otherwise, I think the = authentication side can quickly overwhelm and drag down the = authorization side.

Good news: A lot of the additional stuff in OIDC is there to = patch holes in core OAuth in a common fashion, and we=E2=80=99ll at = least be in a position to not have to do that = again. 


 =E2=80=94 Justin

On Dec 22, 2019, at 10:46 PM, Aaron Parecki <aaron@parecki.com> wrote:

I do think = authentication should be part of the charter from the outset. Frankly = the fact that authentication is intentionally left out of OAuth and has = to be bolted on to the side via OpenID Connect is one of the exact = reasons people get confused about the whole space to begin = with. 

It's a relatively minor = addition to the existing proposed spec to make it useful as a minimum = viable authentication solution, and I'd like to see that be addressed at = the beginning of this work.

I think we can do this in = a smart way and that authentication should be included in the = charter.

Aaron




On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

Hi Justin,

 

I think the charter should mention target use cases. = For example, =E2=80=9Call use cases supported by OAuth 2 will be = supported by the new protocol=E2=80=9D or =E2=80=9Cthe protocol will = support at least use cases X and Y=E2=80=9D.

 

And given the importance of = OIDC, we could say something like: =E2=80=9CThe protocol will allow = future extension to support authentication, in an analogous way to = OpenID Connect. However authentication is explicitly not part of the = initial scope.=E2=80=9D

 

Thanks,

         =        Yaron

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer = <jricher@mit.edu>
Date: = Saturday, December 21, 2019 at 00:34
To: = <txauth@ietf.org>
Cc: = "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>
Subject: = [Txauth] TxAuth Proposed Charter

 

Hi= all,

 

As = discussed in Singapore, no matter what forum TxAuth takes, its work will = require a new charter. With that in mind, I=E2=80=99ve taken a bit of = time to put together a proposed charter text for the TxAuth work:

 

This group is chartered to develop a = next-generation transactional authorization and delegation protocol for = HTTP-based APIs and their clients. These transactions will allow an = authorizing party to delegate a right of access for an API or set of = APIs through an authorization server to a software client acting on = behalf of an authorizing party. 

 

The group will deliver a protocol specification = detailing how a client can request and obtain delegated access, how an = authorization server can provide delegated access, how an authorized = party can authorize delegated access, and how that authorized access can = be communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action. 

 

Additionally, the delegation process will allow = for:

- Fine-grained specification of resource access

- Delegation between multiple users

- Web, mobile, single-page, and other client = applications

 

The = group will define extension points for this protocol to allow for = flexibility in areas including:

 

- Cryptographic agility for keys, message = signatures, and proof of possession 

- User = interaction mechanisms including web and non-web methods

- Token presentation mechanisms and key bindings

 

The = artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions. 

 

While = this work could be done in within the OAuth working group, I now believe = that it should be done in a new working group, and that we should try to = get that working group up and running prior to the Vancouver meeting in = March. I think this group should stay here on the TxAuth list, and = it=E2=80=99s my suggestion that the resulting work be called OAuth = 3.0. 

 

Why a = new group? I think that the OAuth working group should remain focused on = extending, patching, and adapting OAuth 2.0 to a changing world. I plan = to be engaged in both groups, and I know most of you are as well, but = that=E2=80=99s not universal. Since OAuth 2.0 is so established already, = there are a LOT of people who aren=E2=80=99t going to be interested in = something new any time soon. But on the other hand, there are a number = of people for whom OAuth 2.0 does not work, or is at the very least a = poor fit, and we=E2=80=99ll want to bring them in at this early stage. = So even with significant overlap, I think there=E2=80=99s enough = disconnect in the community from both sides that warrants a new group. = In addition, I think this is a big enough piece of work that it=E2=80=99s = simply too much for the OAuth working group to be able to focus on. We = wouldn=E2=80=99t be able to get additional meeting time, and OAuth = already has trouble fitting into its two meeting slots as it is.

 

I=E2=80=99= ve published a blog post detailing more of my rationale:

 

https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a= -new-working-group-d6229ba8e36?

 

Please suggest changes to the proposed charter text = above. It=E2=80=99s my hope that we can get the chartering process = started.

 

 =E2=80= =94 Justin

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
----
Aaron Parecki
aaronparecki.com
@aaronpk


--
----
Aaron Parecki
aaronparecki.com
@aaronpk


= --Apple-Mail=_C8A047A1-B161-4B38-916B-918BA9D8F868-- From nobody Tue Dec 24 16:22:01 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34171120099 for ; Tue, 24 Dec 2019 16:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 3-JkruNVF3SS for ; Tue, 24 Dec 2019 16:21:57 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 0C62512003E for ; Tue, 24 Dec 2019 16:21:56 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBP0LqwH024574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Dec 2019 19:21:53 -0500 From: Justin Richer Message-Id: <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_A3B14EBC-5B92-4059-8036-906A8B492F0C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Dec 2019 19:21:52 -0500 In-Reply-To: Cc: Aaron Parecki , "rdd@cert.org" , Yaron Sheffer , Benjamin Kaduk , txauth@ietf.org To: Brian Campbell References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 00:22:00 -0000 --Apple-Mail=_A3B14EBC-5B92-4059-8036-906A8B492F0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, I hear what you=E2=80=99re saying, but I disagree completely. Who would be confused by seeing a major revision to an existing protocol = that worked in a different way and did the same things but also new = things? That happens all the time. Was there significant confusion between OAuth 1 and 2, enough to hamper = adoption of either? For the people who deeply invested in OAuth 1 and = didn=E2=80=99t need or want the OAuth 2 newness, they stuck with it = (see: twitter).=20 Was OpenID Connect a major disservice to OpenID 2? It was a disruption, = for sure, but people transitioned where it made sense for them, and in = many cases that took years of dual-deployment and transition.=20 I see us walking along the same kind of path here, nearly a decade = later. That=E2=80=99s why I think OAuth 3 makes sense as a name for the = output of this work. Or at the very least, for the core delegation = protocol portion of whatever we make. I think it sends the right message = to implementers and developers: the community that knows and understands = OAuth 2 is working on the next version of that thing, so when it=E2=80=99s= ready, maybe you should look at it. Until it=E2=80=99s done, and for a = long time after, OAuth 2 is still going to be there and be the right = answer.=20 The name isn=E2=80=99t a hill I=E2=80=99m committed to dying alone on, = but I think it sends a :bad: message if we call it something new = entirely. Namely, that we think people :should: abandon the entire world = of OAuth, all of its ideas and implementations. That=E2=80=99s not what = we=E2=80=99re doing with this design, it=E2=80=99s an evolution as I see = things. And as an evolution, a new major revision number makes sense. =E2=80=94 Justin > On Dec 24, 2019, at 9:54 AM, Brian Campbell = wrote: >=20 > Naming any prospective resulting work here "OAuth 3.0" would = significantly exacerbate confusion in the whole space and would be a = major disservice to the broader community.=20 >=20 >=20 > On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki > wrote: > I definitely am not trying to discuss specifics of *how* = authentication should be included right now, but I just want to make = sure it's included in the charter so that we can actually talk about it = and it won't be "out of scope" when we eventually do talk about the = specifics. >=20 > Aaron >=20 >=20 >=20 > On Mon, Dec 23, 2019 at 1:51 PM Justin Richer > wrote: > I=E2=80=99m fine with it being in charter but I do think it should be = a clearly separate layer, much like OIDC/Facebook Connect/GitHub = Login/etc are with OAuth today. In all of these the authorization is = first, and I think that=E2=80=99s the right pattern. So if we do take it = on we=E2=80=99ll just need to be careful how it=E2=80=99s structured in = with everything else. Otherwise, I think the authentication side can = quickly overwhelm and drag down the authorization side. >=20 > Good news: A lot of the additional stuff in OIDC is there to patch = holes in core OAuth in a common fashion, and we=E2=80=99ll at least be = in a position to not have to do that again.=20 >=20 >=20 > =E2=80=94 Justin >=20 >> On Dec 22, 2019, at 10:46 PM, Aaron Parecki > wrote: >>=20 >> I do think authentication should be part of the charter from the = outset. Frankly the fact that authentication is intentionally left out = of OAuth and has to be bolted on to the side via OpenID Connect is one = of the exact reasons people get confused about the whole space to begin = with.=20 >>=20 >> It's a relatively minor addition to the existing proposed spec to = make it useful as a minimum viable authentication solution, and I'd like = to see that be addressed at the beginning of this work. >>=20 >> I think we can do this in a smart way and that authentication should = be included in the charter. >>=20 >> Aaron >>=20 >>=20 >>=20 >>=20 >> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer > wrote: >> Hi Justin, >>=20 >> =20 >>=20 >> I think the charter should mention target use cases. For example, = =E2=80=9Call use cases supported by OAuth 2 will be supported by the new = protocol=E2=80=9D or =E2=80=9Cthe protocol will support at least use = cases X and Y=E2=80=9D. >>=20 >> =20 >>=20 >> And given the importance of OIDC, we could say something like: =E2=80=9C= The protocol will allow future extension to support authentication, in = an analogous way to OpenID Connect. However authentication is explicitly = not part of the initial scope.=E2=80=9D >>=20 >> =20 >>=20 >> Thanks, >>=20 >> Yaron >>=20 >> =20 >>=20 >> From: Txauth > on behalf of Justin Richer = > >> Date: Saturday, December 21, 2019 at 00:34 >> To: > >> Cc: "rdd@cert.org " >, Benjamin Kaduk > >> Subject: [Txauth] TxAuth Proposed Charter >>=20 >> =20 >>=20 >> Hi all, >>=20 >> =20 >>=20 >> As discussed in Singapore, no matter what forum TxAuth takes, its = work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of time to put together a proposed charter text for the TxAuth work: >>=20 >> =20 >>=20 >> This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 >>=20 >> =20 >>=20 >> The group will deliver a protocol specification detailing how a = client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>=20 >> =20 >>=20 >> Additionally, the delegation process will allow for: >>=20 >> - Fine-grained specification of resource access >>=20 >> - Delegation between multiple users >>=20 >> - Web, mobile, single-page, and other client applications >>=20 >> =20 >>=20 >> The group will define extension points for this protocol to allow for = flexibility in areas including: >>=20 >> =20 >>=20 >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >>=20 >> - User interaction mechanisms including web and non-web methods >>=20 >> - Token presentation mechanisms and key bindings >>=20 >> =20 >>=20 >> The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >>=20 >> =20 >>=20 >> While this work could be done in within the OAuth working group, I = now believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>=20 >> =20 >>=20 >> Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing = world. I plan to be engaged in both groups, and I know most of you are = as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>=20 >> =20 >>=20 >> I=E2=80=99ve published a blog post detailing more of my rationale: >>=20 >> =20 >>=20 >> = https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-worki= ng-group-d6229ba8e36? = >> =20 >>=20 >> Please suggest changes to the proposed charter text above. It=E2=80=99s= my hope that we can get the chartering process started. >>=20 >> =20 >>=20 >> =E2=80=94 Justin >>=20 >> -- Txauth mailing list Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth = --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >> --=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=20 >=20 > --=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. --Apple-Mail=_A3B14EBC-5B92-4059-8036-906A8B492F0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Brian, I hear what you=E2=80=99re saying, but I disagree = completely.

Who = would be confused by seeing a major revision to an existing protocol = that worked in a different way and did the same things but also new = things? That happens all the time.

Was there significant confusion between = OAuth 1 and 2, enough to hamper adoption of either? For the people who = deeply invested in OAuth 1 and didn=E2=80=99t need or want the OAuth 2 = newness, they stuck with it (see: twitter). 
Was OpenID Connect a major disservice = to OpenID 2? It was a disruption, for sure, but people transitioned = where it made sense for them, and in many cases that took years of = dual-deployment and transition. 

I see us walking along the same kind of = path here, nearly a decade later. That=E2=80=99s why I think OAuth 3 = makes sense as a name for the output of this work. Or at the very least, = for the core delegation protocol portion of whatever we make. I think it = sends the right message to implementers and developers: the community = that knows and understands OAuth 2 is working on the next version of = that thing, so when it=E2=80=99s ready, maybe you should look at it. = Until it=E2=80=99s done, and for a long time after, OAuth 2 is still = going to be there and be the right answer. 

The name isn=E2=80=99t a hill I=E2=80=99m= committed to dying alone on, but I think it sends a :bad: message if we = call it something new entirely. Namely, that we think people :should: = abandon the entire world of OAuth, all of its ideas and implementations. = That=E2=80=99s not what we=E2=80=99re doing with this design, it=E2=80=99s= an evolution as I see things. And as an evolution, a new major revision = number makes sense.

 =E2=80=94 Justin

On Dec = 24, 2019, at 9:54 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Naming any = prospective resulting work here "OAuth 3.0" would significantly = exacerbate confusion in the whole space and would be a major disservice = to the broader community.


On Mon, Dec = 23, 2019 at 7:39 PM Aaron Parecki <aaron@parecki.com> wrote:
I definitely am not trying to discuss specifics of *how* = authentication should be included right now, but I just want to make = sure it's included in the charter so that we can actually talk about it = and it won't be "out of scope" when we eventually do talk about the = specifics.

Aaron



On Mon, Dec = 23, 2019 at 1:51 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m fine with = it being in charter but I do think it should be a clearly separate = layer, much like OIDC/Facebook Connect/GitHub Login/etc are with OAuth = today. In all of these the authorization is first, and I think that=E2=80=99= s the right pattern. So if we do take it on we=E2=80=99ll just need to = be careful how it=E2=80=99s structured in with everything else. = Otherwise, I think the authentication side can quickly overwhelm and = drag down the authorization side.

Good news: A lot of the additional stuff in OIDC is there to = patch holes in core OAuth in a common fashion, and we=E2=80=99ll at = least be in a position to not have to do that = again. 


 =E2=80= =94 Justin

On Dec 22, 2019, at 10:46 PM, = Aaron Parecki <aaron@parecki.com> wrote:

I do think = authentication should be part of the charter from the outset. Frankly = the fact that authentication is intentionally left out of OAuth and has = to be bolted on to the side via OpenID Connect is one of the exact = reasons people get confused about the whole space to begin = with. 

It's a relatively minor = addition to the existing proposed spec to make it useful as a minimum = viable authentication solution, and I'd like to see that be addressed at = the beginning of this work.

I think we can do this in = a smart way and that authentication should be included in the = charter.

Aaron




On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

Hi Justin,

 

I think the charter should = mention target use cases. For example, =E2=80=9Call use cases supported = by OAuth 2 will be supported by the new protocol=E2=80=9D or =E2=80=9Cthe = protocol will support at least use cases X and Y=E2=80=9D.

 

And = given the importance of OIDC, we could say something like: =E2=80=9CThe = protocol will allow future extension to support authentication, in an = analogous way to OpenID Connect. However authentication is explicitly = not part of the initial scope.=E2=80=9D

 

Thanks,

         =        Yaron

 

From: = Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer = <jricher@mit.edu>
Date: = Saturday, December 21, 2019 at 00:34
To: = <txauth@ietf.org>
Cc: = "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>
Subject: = [Txauth] TxAuth Proposed Charter

 

Hi= all,

 

As = discussed in Singapore, no matter what forum TxAuth takes, its work will = require a new charter. With that in mind, I=E2=80=99ve taken a bit of = time to put together a proposed charter text for the TxAuth work:

 

This group is chartered to develop a next-generation = transactional authorization and delegation protocol for HTTP-based APIs = and their clients. These transactions will allow an authorizing party to = delegate a right of access for an API or set of APIs through an = authorization server to a software client acting on behalf of an = authorizing party. 

 

The = group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can = provide delegated access, how an authorized party can authorize = delegated access, and how that authorized access can be communicated to = the resources being protected. These actions will be connected through = an explicit transaction between the client and authorization server, = resulting in an artifact that will allow the client to undertake the = delegated action. 

 

Additionally, the delegation process will allow = for:

- Fine-grained specification of resource access

- Delegation between multiple users

- Web, mobile, single-page, and other client = applications

 

The = group will define extension points for this protocol to allow for = flexibility in areas including:

 

- Cryptographic agility for keys, message = signatures, and proof of possession 

- User = interaction mechanisms including web and non-web methods

- Token presentation mechanisms and key bindings

 

The = artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions. 

 

While = this work could be done in within the OAuth working group, I now believe = that it should be done in a new working group, and that we should try to = get that working group up and running prior to the Vancouver meeting in = March. I think this group should stay here on the TxAuth list, and = it=E2=80=99s my suggestion that the resulting work be called OAuth = 3.0. 

 

Why a = new group? I think that the OAuth working group should remain focused on = extending, patching, and adapting OAuth 2.0 to a changing world. I plan = to be engaged in both groups, and I know most of you are as well, but = that=E2=80=99s not universal. Since OAuth 2.0 is so established already, = there are a LOT of people who aren=E2=80=99t going to be interested in = something new any time soon. But on the other hand, there are a number = of people for whom OAuth 2.0 does not work, or is at the very least a = poor fit, and we=E2=80=99ll want to bring them in at this early stage. = So even with significant overlap, I think there=E2=80=99s enough = disconnect in the community from both sides that warrants a new group. = In addition, I think this is a big enough piece of work that it=E2=80=99s = simply too much for the OAuth working group to be able to focus on. We = wouldn=E2=80=99t be able to get additional meeting time, and OAuth = already has trouble fitting into its two meeting slots as it is.

 

I=E2=80=99= ve published a blog post detailing more of my rationale:

 

https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-= a-new-working-group-d6229ba8e36?

 

Please suggest changes to the proposed charter text = above. It=E2=80=99s my hope that we can get the chartering process = started.

 

 =E2=80= =94 Justin

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
----
Aaron = Parecki
aaronparecki.com
@aaronpk


--
----
Aaron Parecki
aaronparecki.com
@aaronpk

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.
= --Apple-Mail=_A3B14EBC-5B92-4059-8036-906A8B492F0C-- From nobody Tue Dec 24 16:59:58 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE4B1200B9 for ; Tue, 24 Dec 2019 16:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 c7wMrUow7YJL for ; Tue, 24 Dec 2019 16:59:55 -0800 (PST) Received: from alkaline-solutions.com (unknown [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id ED0CD120099 for ; Tue, 24 Dec 2019 16:59:54 -0800 (PST) Received: from [IPv6:2601:282:202:b210:9dc7:8647:acc7:cc14] (unknown [IPv6:2601:282:202:b210:9dc7:8647:acc7:cc14]) by alkaline-solutions.com (Postfix) with ESMTPSA id 98211315C5; Wed, 25 Dec 2019 01:01:14 +0000 (UTC) From: David Waite Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8B7D323C-A2ED-4E8E-92B2-24BA5EFA2C34" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.1\)) Date: Tue, 24 Dec 2019 17:59:53 -0700 In-Reply-To: <3423A32E-3D54-4C5E-9EC5-C3A36258B65D@mit.edu> Cc: txauth@ietf.org To: Justin Richer References: <2B4EEA97-BB91-4368-B460-4FE161C9A155@alkaline-solutions.com> <3423A32E-3D54-4C5E-9EC5-C3A36258B65D@mit.edu> X-Mailer: Apple Mail (2.3608.60.0.2.1) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2019 00:59:56 -0000 --Apple-Mail=_8B7D323C-A2ED-4E8E-92B2-24BA5EFA2C34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 21, 2019, at 5:37 AM, Justin Richer wrote: >=20 > First, naming things is hard.=20 So very agree! >=20 > But second, the two key points that you pull our below are important, = and both of those led me to the =E2=80=9Ctransactional=E2=80=9D name. = What I realized is that the process of authorization is, itself, a = transaction between multiple parties. The whole idea with a transaction = is that you have multiple actions that get bound together into one = result. By reifying that transaction, you can start to think of the = process in these terms: >=20 >=20 > 1. Client starts a transaction with the AS > 2. User modifies the transaction=E2=80=99s state at the AS with their = authorization > 3. Client continues the transaction with the AS > 4. AS creates a token representing the end result of the transaction = (access) >=20 >=20 Right, and I wouldn=E2=80=99t imply the name is wrong, only that there = are multiple interpretations of =E2=80=99transactional=E2=80=99 and we = should be clear (both in the charter and in specifications) what is = meant so we can be clear in goals and clear to the audience. It sounds like the primary use of the adjective =E2=80=99transactional=E2=80= =99 is to describe exchanges and interactions in general - specifically = that the specification aims to describe how to allow communication = between what has become four parties - the AS, the client, the = authorizing user agent, and the protected resource (some nomenclatures = refer to the client and user agent as the accessing and authorizing = agents). And really, many of the OAuth 2 grants can be looked at handling = differences in the relationship between the client and authorizing user = agent: 1. the client is able to directly control its behavior (code, native = apps) 2. the client replaces the need for an authorizing user agent (client = credentials, ROPC) 3. the client can=E2=80=99t interact directly but can give the user = instructions on how to authorize (device) 4. the client has a hint about the identity of the user or authorizing = device and will give it to the AS to initiate authorization (CIBA) Implicit could also be considered to have been a flow to deal with when = the client is running on the authorizing user agent, without the = capability to use code flow. > So it=E2=80=99s stateful, multi-step, and multi-party.There=E2=80=99s = also a common thread binding each step to the next, which is at least in = line with your notion of atomicity. If any part of the process fails, = you can stop the whole thing and throw it out. When it=E2=80=99s = finished, you commit it into an artifact (the token).=20 There=E2=80=99s an element of representing the interaction between the = client and AS as being an atomic transaction as well - you either = succeed (and get tokens) or fail (and get a message why and/or = instructions on how to rectify the situation). When you squint to look = at it that way, the =E2=80=99transaction handle=E2=80=99 is there so you = can repeat the =E2=80=9Cauthorization request=E2=80=9D transaction. -DW > We are not saying that it=E2=80=99s authorization for transactional = APIs, though it obviously could be used for that.=20 >=20 > =E2=80=94 Justin --Apple-Mail=_8B7D323C-A2ED-4E8E-92B2-24BA5EFA2C34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On Dec 21, 2019, at 5:37 AM, Justin Richer = <jricher@mit.edu> = wrote:

First, naming things = is hard. 

So very = agree!


But second, the two key points that you = pull our below are important, and both of those led me to the = =E2=80=9Ctransactional=E2=80=9D name. What I realized is that the = process of authorization is, itself, a transaction between multiple = parties.  The whole idea with a transaction is that you have = multiple actions that get bound together into one result. By = reifying that transaction, you can start to think of the process in = these terms:

1. Client starts a transaction with = the AS
2. User modifies the transaction=E2=80=99s = state at the AS with their authorization
3. Client = continues the transaction with the AS
4. AS creates = a token representing the end result of the transaction = (access)



Right, and I wouldn=E2=80=99t imply the name is = wrong, only that there are multiple interpretations of = =E2=80=99transactional=E2=80=99 and we should be clear (both in the = charter and in specifications) what is meant so we can be clear in goals = and clear to the audience.

It sounds like the primary use of the adjective = =E2=80=99transactional=E2=80=99 is to describe exchanges and = interactions in general - specifically that the specification aims to = describe how to allow communication between what has become four parties = - the AS, the client, the authorizing user agent, and the protected = resource (some nomenclatures refer to the client and user agent = as the accessing and authorizing agents).

And = really, many of the OAuth 2 grants can be looked at handling differences = in the relationship between the client and authorizing user = agent:

1. =  the client is able to directly control its behavior (code, native = apps)
2. =  the client replaces the need for an authorizing user agent (client = credentials, ROPC)
3. =  the client can=E2=80=99t interact directly but can give the user = instructions on how to authorize (device)
4.  the client has a hint about the = identity of the user or authorizing device and will give it to the AS to = initiate authorization (CIBA)

Implicit could also be considered to have been a flow to deal = with when the client is running on the authorizing user agent, without = the capability to use code flow.

So it=E2=80=99s stateful, = multi-step, and multi-party.There=E2=80=99s also a common thread binding = each step to the next, which is at least in line with your notion of = atomicity. If any part of the process fails, you can stop the whole = thing and throw it out. When it=E2=80=99s finished, you commit it into = an artifact (the token). 

There=E2=80=99s an element of representing the = interaction between the client and AS as being an atomic transaction as = well - you either succeed (and get tokens) or fail (and get a message = why and/or instructions on how to rectify the situation). When you = squint to look at it that way, the =E2=80=99transaction handle=E2=80=99 = is there so you can repeat the =E2=80=9Cauthorization request=E2=80=9D =  transaction.

-DW

We are not saying that = it=E2=80=99s authorization for transactional APIs, though it obviously = could be used for that. 

 =E2=80=94 = Justin

= --Apple-Mail=_8B7D323C-A2ED-4E8E-92B2-24BA5EFA2C34-- From nobody Thu Dec 26 08:42:46 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F097512004A for ; Thu, 26 Dec 2019 08:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=hardjono.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4ExRlD50ALa for ; Thu, 26 Dec 2019 08:42:41 -0800 (PST) Received: from gateway23.websitewelcome.com (gateway23.websitewelcome.com [192.185.48.104]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772D3120026 for ; Thu, 26 Dec 2019 08:42:41 -0800 (PST) Received: from cm17.websitewelcome.com (cm17.websitewelcome.com [100.42.49.20]) by gateway23.websitewelcome.com (Postfix) with ESMTP id E3CC47A33 for ; Thu, 26 Dec 2019 10:42:40 -0600 (CST) Received: from box5207.bluehost.com ([162.241.224.194]) by cmsmtp with SMTP id kWDgiHR2wqNtvkWDgix98g; Thu, 26 Dec 2019 10:42:40 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hardjono.net; s=default; h=Content-transfer-encoding:Content-type: Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PM+l/9268p2ab5Yfkhp386G2rfZhq06PICweRAs+xKg=; b=ibavodho9j6Dg9zjT0ytOnewTr +osc5HWhqr/C6+ME46AtSOBwwvFLnZH9Db0RSa1jq3vsAuRU1gxcIPlDnvcjLGmiAcYb5oIOwm+al +mencq9V3QMgbl7sH86Wtg9eT; Received: from c-73-167-220-69.hsd1.ma.comcast.net ([73.167.220.69]:62428 helo=[10.0.0.194]) by box5207.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ikWDg-000kGl-CU; Thu, 26 Dec 2019 09:42:40 -0700 User-Agent: Microsoft-MacOutlook/10.10.11.191208 Date: Thu, 26 Dec 2019 11:42:37 -0500 From: Thomas Hardjono To: Justin Richer , Message-ID: <543EBD14-5629-48CA-8FE8-417678DADD97@hardjono.net> Thread-Topic: [Txauth] TxAuth Proposed Charter References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5207.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hardjono.net X-BWhitelist: no X-Source-IP: 73.167.220.69 X-Source-L: No X-Exim-ID: 1ikWDg-000kGl-CU X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-73-167-220-69.hsd1.ma.comcast.net ([10.0.0.194]) [73.167.220.69]:62428 X-Source-Auth: ietf-txauth@hardjono.net X-Email-Count: 1 X-Source-Cap: aGFyZGpvbm87aGFyZGpvbm87Ym94NTIwNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2019 16:42:44 -0000 I know the proposed charter is still a drafty draft, but I have a couple of= high-level questions. (i) Will there be a separate specification for the TXT core protocol and fo= r the "authorization_details" (Torsten's draft). Is this what the proposaed = Charter refers to as "Fine-grained specification of resource access". (ii) Will there be an AS-to-AS mechanism to deliver authorization informati= on (either in the "authorization_details" format or otherwise). This is rele= vant for authorization federation (for ASes in different domains) and for ad= dressing some of the issues that Annabelle presented at IETF106 (i.e. contex= t sharing). -- thomas -- =EF=BB=BF-----Original Message----- From: Txauth on behalf of Justin Richer Date: Friday, December 20, 2019 at 5:34 PM To: Cc: "rdd@cert.org" , Benjamin Kaduk Subject: [Txauth] TxAuth Proposed Charter Hi all, As discussed in Singapore, no matter what forum TxAuth takes, its work will= require a new charter. With that in mind, I=E2=80=99ve taken a bit of time to put= together a proposed charter text for the TxAuth work: This group is chartered to develop a next-generation transactional authoriz= ation and delegation protocol for HTTP-based APIs and their clients. These t= ransactions will allow an authorizing party to delegate a right of access fo= r an API or set of APIs through an authorization server to a software client= acting on behalf of an authorizing party.=20 The group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can provide= delegated access, how an authorized party can authorize delegated access, a= nd how that authorized access can be communicated to the resources being pro= tected. These actions will be connected through an explicit transaction betw= een the client and authorization server, resulting in an artifact that will = allow the client to undertake the delegated action.=20 Additionally, the delegation process will allow for: - Fine-grained specification of resource access - Delegation between multiple users - Web, mobile, single-page, and other client applications The group will define extension points for this protocol to allow for flexi= bility in areas including: - Cryptographic agility for keys, message signatures, and proof of possessi= on=20 - User interaction mechanisms including web and non-web methods - Token presentation mechanisms and key bindings The artifacts for this work are not intended or expected to be backwards-co= mpatible with OAuth 2.0 and its extensions.=20 While this work could be done in within the OAuth working group, I now beli= eve that it should be done in a new working group, and that we should try to= get that working group up and running prior to the Vancouver meeting in Mar= ch. I think this group should stay here on the TxAuth list, and it=E2=80=99s my su= ggestion that the resulting work be called OAuth 3.0.=20 Why a new group? I think that the OAuth working group should remain focused= on extending, patching, and adapting OAuth 2.0 to a changing world. I plan = to be engaged in both groups, and I know most of you are as well, but that=E2=80= =99s not universal. Since OAuth 2.0 is so established already, there are a LOT= of people who aren=E2=80=99t going to be interested in something new any time soo= n. But on the other hand, there are a number of people for whom OAuth 2.0 do= es not work, or is at the very least a poor fit, and we=E2=80=99ll want to bring t= hem in at this early stage. So even with significant overlap, I think there=E2= =80=99s enough disconnect in the community from both sides that warrants a new g= roup. In addition, I think this is a big enough piece of work that it=E2=80=99s si= mply too much for the OAuth working group to be able to focus on. We wouldn=E2= =80=99t be able to get additional meeting time, and OAuth already has trouble fi= tting into its two meeting slots as it is. I=E2=80=99ve published a blog post detailing more of my rationale: https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working= -group-d6229ba8e36? Please suggest changes to the proposed charter text above. It=E2=80=99s my hope t= hat we can get the chartering process started. =E2=80=94 Justin --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth From nobody Thu Dec 26 08:45:29 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA8612004A for ; Thu, 26 Dec 2019 08:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=hardjono.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sszLLt5XPhjr for ; Thu, 26 Dec 2019 08:45:25 -0800 (PST) Received: from gateway31.websitewelcome.com (gateway31.websitewelcome.com [192.185.143.46]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C30120026 for ; Thu, 26 Dec 2019 08:45:25 -0800 (PST) Received: from cm12.websitewelcome.com (cm12.websitewelcome.com [100.42.49.8]) by gateway31.websitewelcome.com (Postfix) with ESMTP id 19C6E18028 for ; Thu, 26 Dec 2019 10:45:25 -0600 (CST) Received: from box5207.bluehost.com ([162.241.224.194]) by cmsmtp with SMTP id kWGLiXmOOW4frkWGLiq8fk; Thu, 26 Dec 2019 10:45:25 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hardjono.net; s=default; h=Content-transfer-encoding:Content-type: Mime-version:In-Reply-To:References:Message-ID:To:From:Subject:Date:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/rDZfYWtnxXcO7PTdL4XsBK3rn6Bf9bYcpcc4BeTcU8=; b=DPEdtXNehbRssLV8D0pnzi9hWV rRD0Ex0k7t18O2dmIOr4mDkFBCjX1aEPqxxwUefxG1udj4OjuWMKPuvVYK3xsY/DaU0SUiufdH6y5 cx38Qrl/goC94JldBU4WXQg6h; Received: from c-73-167-220-69.hsd1.ma.comcast.net ([73.167.220.69]:62428 helo=[10.0.0.194]) by box5207.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ikWGK-000kGl-RN; Thu, 26 Dec 2019 09:45:24 -0700 User-Agent: Microsoft-MacOutlook/10.10.11.191208 Date: Thu, 26 Dec 2019 11:45:24 -0500 From: Thomas Hardjono To: Justin Richer , Message-ID: <5CC36DBF-4DA0-47FD-952B-2A41FF8342BA@hardjono.net> Thread-Topic: [Txauth] TxAuth Proposed Charter References: <543EBD14-5629-48CA-8FE8-417678DADD97@hardjono.net> In-Reply-To: <543EBD14-5629-48CA-8FE8-417678DADD97@hardjono.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5207.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hardjono.net X-BWhitelist: no X-Source-IP: 73.167.220.69 X-Source-L: No X-Exim-ID: 1ikWGK-000kGl-RN X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-73-167-220-69.hsd1.ma.comcast.net ([10.0.0.194]) [73.167.220.69]:62428 X-Source-Auth: ietf-txauth@hardjono.net X-Email-Count: 3 X-Source-Cap: aGFyZGpvbm87aGFyZGpvbm87Ym94NTIwNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2019 16:45:28 -0000 Correction: TXauth core protocol (not TXT core protocol, as TXT is Trusted = Execution, and also the name of a K-Pop band). =EF=BB=BF-----Original Message----- From: Thomas Hardjono Date: Thursday, December 26, 2019 at 11:42 AM To: Justin Richer , Subject: Re: [Txauth] TxAuth Proposed Charter I know the proposed charter is still a drafty draft, but I have a couple of= high-level questions. (i) Will there be a separate specification for the TXT core protocol and fo= r the "authorization_details" (Torsten's draft). Is this what the proposaed = Charter refers to as "Fine-grained specification of resource access". (ii) Will there be an AS-to-AS mechanism to deliver authorization informati= on (either in the "authorization_details" format or otherwise). This is rele= vant for authorization federation (for ASes in different domains) and for ad= dressing some of the issues that Annabelle presented at IETF106 (i.e. contex= t sharing). -- thomas -- =EF=BB=BF-----Original Message----- From: Txauth on behalf of Justin Richer Date: Friday, December 20, 2019 at 5:34 PM To: Cc: "rdd@cert.org" , Benjamin Kaduk Subject: [Txauth] TxAuth Proposed Charter Hi all, As discussed in Singapore, no matter what forum TxAuth takes, its work will= require a new charter. With that in mind, I=E2=80=99ve taken a bit of time to put= together a proposed charter text for the TxAuth work: This group is chartered to develop a next-generation transactional authoriz= ation and delegation protocol for HTTP-based APIs and their clients. These t= ransactions will allow an authorizing party to delegate a right of access fo= r an API or set of APIs through an authorization server to a software client= acting on behalf of an authorizing party.=20 The group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can provide= delegated access, how an authorized party can authorize delegated access, a= nd how that authorized access can be communicated to the resources being pro= tected. These actions will be connected through an explicit transaction betw= een the client and authorization server, resulting in an artifact that will = allow the client to undertake the delegated action.=20 Additionally, the delegation process will allow for: - Fine-grained specification of resource access - Delegation between multiple users - Web, mobile, single-page, and other client applications The group will define extension points for this protocol to allow for flexi= bility in areas including: - Cryptographic agility for keys, message signatures, and proof of possessi= on=20 - User interaction mechanisms including web and non-web methods - Token presentation mechanisms and key bindings The artifacts for this work are not intended or expected to be backwards-co= mpatible with OAuth 2.0 and its extensions.=20 While this work could be done in within the OAuth working group, I now beli= eve that it should be done in a new working group, and that we should try to= get that working group up and running prior to the Vancouver meeting in Mar= ch. I think this group should stay here on the TxAuth list, and it=E2=80=99s my su= ggestion that the resulting work be called OAuth 3.0.=20 Why a new group? I think that the OAuth working group should remain focused= on extending, patching, and adapting OAuth 2.0 to a changing world. I plan = to be engaged in both groups, and I know most of you are as well, but that=E2=80= =99s not universal. Since OAuth 2.0 is so established already, there are a LOT= of people who aren=E2=80=99t going to be interested in something new any time soo= n. But on the other hand, there are a number of people for whom OAuth 2.0 do= es not work, or is at the very least a poor fit, and we=E2=80=99ll want to bring t= hem in at this early stage. So even with significant overlap, I think there=E2= =80=99s enough disconnect in the community from both sides that warrants a new g= roup. In addition, I think this is a big enough piece of work that it=E2=80=99s si= mply too much for the OAuth working group to be able to focus on. We wouldn=E2= =80=99t be able to get additional meeting time, and OAuth already has trouble fi= tting into its two meeting slots as it is. I=E2=80=99ve published a blog post detailing more of my rationale: https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working= -group-d6229ba8e36? Please suggest changes to the proposed charter text above. It=E2=80=99s my hope t= hat we can get the chartering process started. =E2=80=94 Justin --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth From nobody Thu Dec 26 13:29:41 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3253B1200EC for ; Thu, 26 Dec 2019 13:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 isgRv4S7J-2T for ; Thu, 26 Dec 2019 13:29:36 -0800 (PST) Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (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 DC7F01200B6 for ; Thu, 26 Dec 2019 13:29:35 -0800 (PST) Received: by mail-lf1-x142.google.com with SMTP id m30so19282459lfp.8 for ; Thu, 26 Dec 2019 13:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gxmlb1i/yLaRq5TysRPCpSyY+wJo3aDp5jJPpnrItt4=; b=ONukdKqGfLCJbOILI44OfSPfF4jvaZbGT7XH5tRaUiVqRWw2lVqv31l1zxft1dgERD +/+AAtsp1KFjqoHnyZJbfjPWWYLlyihAnOd5q9+UMDjVUBw5Gh1kxXP4y/4ztYmSjUyF ZEaH2GPoKrJM5Qr+FK+BCqYwxUg3EqPsRtv3Np1phEw0mcC2MT/xGTFFv5/z5op+B8IF xNMUZw0vPgq2p7C3OTm7uyuedlyaCfehQIcxr5JvSXK5X5EwFDNDHwKLLcOslkA3InfK DXnMSAZB2zHm5o7uvmsYxFpKUb/AWP5jk3q5Qefu8s1hlk6uDs4l4TlghAMRGxh0vb2G K90A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gxmlb1i/yLaRq5TysRPCpSyY+wJo3aDp5jJPpnrItt4=; b=PGCJcMHTXNuN59waS3HaE6XFHwWpIxcIH7gx5KMdiVvgQgfV23YSnCWc3o1jH2NFep YIsLNjNRtod+JL1tKjsYp4YQdXz1D40ugoCnTI8lwdU42PWc7QXrmMkGuoZhRd3rYvD/ 2/VUFLQXz+OX0x7KQ+/3wf80+FgtECbm2BnYaFAx7n226K71YLtHiyl/twM4qdUHkJkJ JCU3odEaBhkuVrMCLsPm/RIWGkyniS+1Ve4rwTRt4jse3x889OVf1y+jw7J8vBzMwRgo 6uyEuIrzYrvAOBNZjEBEaCBBFgMqVhGih5IkOrU+yHyFYxfrOjkU8DyKLViXXhrERPiz +0Sg== X-Gm-Message-State: APjAAAU0VA07f0AxRk8hEbKZJBns5DfX7xp5fXGMus3r67AVDzdzGUKV 388g+5gL8okHifBVplopDSDY2KbvexfxRXeHfPI43vjiMCsbTbGS2r3Ah436IKuPCUjyUFiDChp nVBuMRsNkr4OpoJo= X-Google-Smtp-Source: APXvYqyNImARbzsMMAlHqHnHgi4/BFNSr5TztIsSdittJdWK4JP4E03+E3M5vfI7VJASLAPKbO9RQwWD6WurhexTTrs= X-Received: by 2002:ac2:44d9:: with SMTP id d25mr28284872lfm.15.1577395773946; Thu, 26 Dec 2019 13:29:33 -0800 (PST) MIME-Version: 1.0 References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> In-Reply-To: <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> From: Brian Campbell Date: Thu, 26 Dec 2019 14:29:07 -0700 Message-ID: To: Justin Richer Cc: Aaron Parecki , "rdd@cert.org" , Yaron Sheffer , Benjamin Kaduk , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000c6dd0d059aa212fb" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2019 21:29:40 -0000 --000000000000c6dd0d059aa212fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [doctored image credit: Nishant Kaushik] Well, I'm already on record at the Singapore BoF (in a rambling incoherent jetlagged kind of way but still) as not supporting progression of this work. Concern around the confusion it'll cause in the wider community is one of my reasons for that opposition and I personally think that using the OAuth brand will exacerbate potential perception issues and confusion. But with that said, while I don't necessarily agree with you, I do think your arguments hold up for TXAuth/XYZ as an authorization protocol. However, bringing identity/authentication into it would broaden the scope beyond the evolution of an authorization protocol and into the realm of OIDC (and even SAML), which is something we've been fighting to explain to the world that OAuth isn't for years. The message that you don't ever do user authentication with OAuth unless it's this particular version of OAuth would be crazy confusing. So with all that being said, I'll throw out the strawman name of MOAUTH*, which is soft of a combination of a portmanteau and a play on word sounds. It could be taken as "More OAuth" or "More Than OAuth" or "MOre Auth[n/z]" or similar.. It'd maintain some link to OAuth heritage while indicating progression/evolution and more easily allowing for a potentially a broadening scope to include identity and user authentication. * I cannot claim credit for MOAUTH but I don't know if the person from whom I got the idea wants to be named so that'll be withheld for the time being On Tue, Dec 24, 2019 at 5:21 PM Justin Richer wrote: > Brian, I hear what you=E2=80=99re saying, but I disagree completely. > > Who would be confused by seeing a major revision to an existing protocol > that worked in a different way and did the same things but also new thing= s? > That happens all the time. > > Was there significant confusion between OAuth 1 and 2, enough to hamper > adoption of either? For the people who deeply invested in OAuth 1 and > didn=E2=80=99t need or want the OAuth 2 newness, they stuck with it (see:= twitter). > > Was OpenID Connect a major disservice to OpenID 2? It was a disruption, > for sure, but people transitioned where it made sense for them, and in ma= ny > cases that took years of dual-deployment and transition. > > I see us walking along the same kind of path here, nearly a decade later. > That=E2=80=99s why I think OAuth 3 makes sense as a name for the output o= f this > work. Or at the very least, for the core delegation protocol portion of > whatever we make. I think it sends the right message to implementers and > developers: the community that knows and understands OAuth 2 is working o= n > the next version of that thing, so when it=E2=80=99s ready, maybe you sho= uld look > at it. Until it=E2=80=99s done, and for a long time after, OAuth 2 is sti= ll going > to be there and be the right answer. > > The name isn=E2=80=99t a hill I=E2=80=99m committed to dying alone on, bu= t I think it > sends a :bad: message if we call it something new entirely. Namely, that = we > think people :should: abandon the entire world of OAuth, all of its ideas > and implementations. That=E2=80=99s not what we=E2=80=99re doing with thi= s design, it=E2=80=99s an > evolution as I see things. And as an evolution, a new major revision numb= er > makes sense. > > =E2=80=94 Justin > > On Dec 24, 2019, at 9:54 AM, Brian Campbell > wrote: > > Naming any prospective resulting work here "OAuth 3.0" would significantl= y > exacerbate confusion in the whole space and would be a major disservice t= o > the broader community. > > > On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki wrote: > >> I definitely am not trying to discuss specifics of *how* authentication >> should be included right now, but I just want to make sure it's included= in >> the charter so that we can actually talk about it and it won't be "out o= f >> scope" when we eventually do talk about the specifics. >> >> Aaron >> >> >> >> On Mon, Dec 23, 2019 at 1:51 PM Justin Richer wrote: >> >>> I=E2=80=99m fine with it being in charter but I do think it should be a= clearly >>> separate layer, much like OIDC/Facebook Connect/GitHub Login/etc are wi= th >>> OAuth today. In all of these the authorization is first, and I think th= at=E2=80=99s >>> the right pattern. So if we do take it on we=E2=80=99ll just need to be= careful how >>> it=E2=80=99s structured in with everything else. Otherwise, I think the >>> authentication side can quickly overwhelm and drag down the authorizati= on >>> side. >>> >>> Good news: A lot of the additional stuff in OIDC is there to patch hole= s >>> in core OAuth in a common fashion, and we=E2=80=99ll at least be in a p= osition to >>> not have to do that again. >>> >>> >>> =E2=80=94 Justin >>> >>> On Dec 22, 2019, at 10:46 PM, Aaron Parecki wrote: >>> >>> I do think authentication should be part of the charter from the outset= . >>> Frankly the fact that authentication is intentionally left out of OAuth= and >>> has to be bolted on to the side via OpenID Connect is one of the exact >>> reasons people get confused about the whole space to begin with. >>> >>> It's a relatively minor addition to the existing proposed spec to make >>> it useful as a minimum viable authentication solution, and I'd like to = see >>> that be addressed at the beginning of this work. >>> >>> I think we can do this in a smart way and that authentication should be >>> included in the charter. >>> >>> Aaron >>> >>> >>> >>> >>> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer >>> wrote: >>> >>>> Hi Justin, >>>> >>>> >>>> >>>> I think the charter should mention target use cases. For example, =E2= =80=9Call >>>> use cases supported by OAuth 2 will be supported by the new protocol= =E2=80=9D or >>>> =E2=80=9Cthe protocol will support at least use cases X and Y=E2=80=9D= . >>>> >>>> >>>> >>>> And given the importance of OIDC, we could say something like: =E2=80= =9CThe >>>> protocol will allow future extension to support authentication, in an >>>> analogous way to OpenID Connect. However authentication is explicitly = not >>>> part of the initial scope.=E2=80=9D >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Yaron >>>> >>>> >>>> >>>> *From: *Txauth on behalf of Justin Richer < >>>> jricher@mit.edu> >>>> *Date: *Saturday, December 21, 2019 at 00:34 >>>> *To: * >>>> *Cc: *"rdd@cert.org" , Benjamin Kaduk >>>> *Subject: *[Txauth] TxAuth Proposed Charter >>>> >>>> >>>> >>>> Hi all, >>>> >>>> >>>> >>>> As discussed in Singapore, no matter what forum TxAuth takes, its work >>>> will require a new charter. With that in mind, I=E2=80=99ve taken a bi= t of time to >>>> put together a proposed charter text for the TxAuth work: >>>> >>>> >>>> >>>> This group is chartered to develop a next-generation transactional >>>> authorization and delegation protocol for HTTP-based APIs and their >>>> clients. These transactions will allow an authorizing party to delegat= e a >>>> right of access for an API or set of APIs through an authorization ser= ver >>>> to a software client acting on behalf of an authorizing party. >>>> >>>> >>>> >>>> The group will deliver a protocol specification detailing how a client >>>> can request and obtain delegated access, how an authorization server c= an >>>> provide delegated access, how an authorized party can authorize delega= ted >>>> access, and how that authorized access can be communicated to the reso= urces >>>> being protected. These actions will be connected through an explicit >>>> transaction between the client and authorization server, resulting in = an >>>> artifact that will allow the client to undertake the delegated action. >>>> >>>> >>>> >>>> Additionally, the delegation process will allow for: >>>> >>>> - Fine-grained specification of resource access >>>> >>>> - Delegation between multiple users >>>> >>>> - Web, mobile, single-page, and other client applications >>>> >>>> >>>> >>>> The group will define extension points for this protocol to allow for >>>> flexibility in areas including: >>>> >>>> >>>> >>>> - Cryptographic agility for keys, message signatures, and proof of >>>> possession >>>> >>>> - User interaction mechanisms including web and non-web methods >>>> >>>> - Token presentation mechanisms and key bindings >>>> >>>> >>>> >>>> The artifacts for this work are not intended or expected to be >>>> backwards-compatible with OAuth 2.0 and its extensions. >>>> >>>> >>>> >>>> While this work could be done in within the OAuth working group, I now >>>> believe that it should be done in a new working group, and that we sho= uld >>>> try to get that working group up and running prior to the Vancouver me= eting >>>> in March. I think this group should stay here on the TxAuth list, and = it=E2=80=99s >>>> my suggestion that the resulting work be called OAuth 3.0. >>>> >>>> >>>> >>>> Why a new group? I think that the OAuth working group should remain >>>> focused on extending, patching, and adapting OAuth 2.0 to a changing w= orld. >>>> I plan to be engaged in both groups, and I know most of you are as wel= l, >>>> but that=E2=80=99s not universal. Since OAuth 2.0 is so established al= ready, there >>>> are a LOT of people who aren=E2=80=99t going to be interested in somet= hing new any >>>> time soon. But on the other hand, there are a number of people for who= m >>>> OAuth 2.0 does not work, or is at the very least a poor fit, and we=E2= =80=99ll want >>>> to bring them in at this early stage. So even with significant overlap= , I >>>> think there=E2=80=99s enough disconnect in the community from both sid= es that >>>> warrants a new group. In addition, I think this is a big enough piece = of >>>> work that it=E2=80=99s simply too much for the OAuth working group to = be able to >>>> focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth >>>> already has trouble fitting into its two meeting slots as it is. >>>> >>>> >>>> >>>> I=E2=80=99ve published a blog post detailing more of my rationale: >>>> >>>> >>>> >>>> >>>> https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-w= orking-group-d6229ba8e36? >>>> >>>> >>>> >>>> >>>> Please suggest changes to the proposed charter text above. It=E2=80=99= s my hope >>>> that we can get the chartering process started. >>>> >>>> >>>> >>>> =E2=80=94 Justin >>>> >>>> -- Txauth mailing list Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>> >>> >>> -- >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000c6dd0d059aa212fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[doctored image credit: Nishant Kaushik]
Well, I'm already on record at the Singapore BoF (in a rambling incoherent jetlagged kind of way= but still) as not supporting progression of this work. Concern around the = confusion it'll cause in the wider community is one of my reasons for t= hat opposition and I personally think that using the OAuth b= rand will exacerbate potential perception issues and confusion. But with th= at said, while I don't necessarily agree with you, I do think your argu= ments hold up for TXAuth/XYZ as an authorization protocol. However, bringin= g identity/authentication into it would broaden the scope beyond the evolut= ion of an authorization protocol and into the realm of OIDC = (and even SAML), which is something we've been fighting = to explain to the world that OAuth isn't for years. The = message that you don't ever do user authentication with OAuth unless it's this particular version of OAuth would= be crazy confusing.

So with all that being s= aid, I'll throw out the strawman name of MOAUTH*, which is soft of a co= mbination of a portmanteau and a play on word sounds. It could be taken as = "More OAuth" or "More Than OAuth" or "MOre Auth[n/= z]" or similar.. It'd maintain some link to OAuth heritage while i= ndicating progression/evolution and more easily allowing for a potentially = a broadening scope to include identity and user authentication.=C2=A0
<= /div>


* I cannot claim credit for MO= AUTH but I don't know if the person from whom I got the idea wants to b= e named so that'll be withheld for the time being




On Tue, Dec 24, 2019 at 5:21 PM Jus= tin Richer <jricher@mit.edu> wrote:
<= /div>
Brian, I hear w= hat you=E2=80=99re saying, but I disagree completely.

Wh= o would be confused by seeing a major revision to an existing protocol that= worked in a different way and did the same things but also new things? Tha= t happens all the time.

Was there significant conf= usion between OAuth 1 and 2, enough to hamper adoption of either? For the p= eople who deeply invested in OAuth 1 and didn=E2=80=99t need or want the OA= uth 2 newness, they stuck with it (see: twitter).=C2=A0

Was OpenID Connect a major disservice to OpenID 2? It was a disruptio= n, for sure, but people transitioned where it made sense for them, and in m= any cases that took years of dual-deployment and transition.=C2=A0

I see us walking along the same kind of path here, nearly = a decade later. That=E2=80=99s why I think OAuth 3 makes sense as a name fo= r the output of this work. Or at the very least, for the core delegation pr= otocol portion of whatever we make. I think it sends the right message to i= mplementers and developers: the community that knows and understands OAuth = 2 is working on the next version of that thing, so when it=E2=80=99s ready,= maybe you should look at it. Until it=E2=80=99s done, and for a long time = after, OAuth 2 is still going to be there and be the right answer.=C2=A0

The name isn=E2=80=99t a hill I=E2=80=99m committed = to dying alone on, but I think it sends a :bad: message if we call it somet= hing new entirely. Namely, that we think people :should: abandon the entire= world of OAuth, all of its ideas and implementations. That=E2=80=99s not w= hat we=E2=80=99re doing with this design, it=E2=80=99s an evolution as I se= e things. And as an evolution, a new major revision number makes sense.

=C2=A0=E2=80=94 Justin

On Dec 24, 2019, at 9:54 AM, Brian Campbell <bcampbell@pingidentity.= com> wrote:

Naming any prospecti= ve resulting work here "OAuth 3.0" would significantly exacerbate= confusion in the whole space and would be a major disservice to the broade= r community.


On Mon, Dec 23, 2019 at 7:39 PM = Aaron Parecki <aa= ron@parecki.com> wrote:
I definitely am not trying to discuss= specifics of *how* authentication should be included right now, but I just= want to make sure it's included in the charter so that we can actually= talk about it and it won't be "out of scope" when we eventua= lly do talk about the specifics.

Aaron


On Mon, Dec 23, 2019 at 1:51 PM Justin Richer <jricher@mit.edu> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I=E2=80=99m fine with= it being in charter but I do think it should be a clearly separate layer, = much like OIDC/Facebook Connect/GitHub Login/etc are with OAuth today. In a= ll of these the authorization is first, and I think that=E2=80=99s the righ= t pattern. So if we do take it on we=E2=80=99ll just need to be careful how= it=E2=80=99s structured in with everything else. Otherwise, I think the au= thentication side can quickly overwhelm and drag down the authorization sid= e.

Good news: A lot of the additional stuff in OIDC is t= here to patch holes in core OAuth in a common fashion, and we=E2=80=99ll at= least be in a position to not have to do that again.=C2=A0


=C2=A0=E2=80=94 Justin

On Dec 22, 2019, at 10:46 PM, Aaron Parecki <aaron@parecki.com> = wrote:

I do think authentication shoul= d be part of the charter from the outset. Frankly the fact that authenticat= ion is intentionally left out of OAuth and has to be bolted on to the side = via OpenID Connect is one of the exact reasons people get confused about th= e whole space to begin with.=C2=A0

<= div dir=3D"auto">It's a relatively minor addition to the existing propo= sed spec to make it useful as a minimum viable authentication solution, and= I'd like to see that be addressed at the beginning of this work.
=

I think we can do this in a s= mart way and that authentication should be included in the charter.

Aaron



On Sat, Dec = 21, 2019 at 1:51 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Justin,

= =C2=A0

I think the charter should mention = target use cases. For example, =E2=80=9Call use cases supported by OAuth 2 = will be supported by the new protocol=E2=80=9D or =E2=80=9Cthe protocol wil= l support at least use cases X and Y=E2=80=9D.

=C2=A0

And given the im= portance of OIDC, we could say something like: =E2=80=9CThe protocol will a= llow future extension to support authentication, in an analogous way to Ope= nID Connect. However authentication is explicitly not part of the initial s= cope.=E2=80=9D

=C2=A0=

Thanks,

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Yaron

=C2=A0

= From: Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer <jricher@mit.edu>
Dat= e: Saturday, December 21, 2019 at 00:34
To: <txauth@ietf.org>
Cc: <= /b>"rdd@cert.org= " <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>
Subject: [Txauth] TxAuth Proposed Charte= r

=C2=A0

Hi all,

=C2=A0

A= s discussed in Singapore, no matter what forum TxAuth takes, its work will = require a new charter. With that in mind, I=E2=80=99ve taken a bit of time = to put together a proposed charter text for the TxAuth work:<= /p>

=C2=A0

This group is chartered to develop a next-generation transactional authori= zation and delegation protocol for HTTP-based APIs and their clients. These= transactions will allow an authorizing party to delegate a right of access= for an API or set of APIs through an authorization server to a software cl= ient acting on behalf of an authorizing party.=C2=A0

=C2=A0

The group will deliver a protocol specification detailing how a= client can request and obtain delegated access, how an authorization serve= r can provide delegated access, how an authorized party can authorize deleg= ated access, and how that authorized access can be communicated to the reso= urces being protected. These actions will be connected through an explicit = transaction between the client and authorization server, resulting in an ar= tifact that will allow the client to undertake the delegated action.=C2=A0<= u>

=C2=A0

=

Additionally, the delegation process will= allow for:

- Fine-grain= ed specification of resource access

- Delegation between multiple users

- Web, mobile, single-page, and other client applic= ations

=C2=A0<= /u>

The group will define extension po= ints for this protocol to allow for flexibility in areas including:<= u>

=C2=A0

<= div>

- Cryptographic agility for keys, message signat= ures, and proof of possession=C2=A0

- User interaction mechanisms including web and non-web methods=

- Token presentation me= chanisms and key bindings

=C2=A0

The artifacts f= or this work are not intended or expected to be backwards-compatible with O= Auth 2.0 and its extensions.=C2=A0

=C2=A0

While this work could be done in within the OAuth working group, I n= ow believe that it should be done in a new working group, and that we shoul= d try to get that working group up and running prior to the Vancouver meeti= ng in March. I think this group should stay here on the TxAuth list, and it= =E2=80=99s my suggestion that the resulting work be called OAuth 3.0.=C2=A0=

=C2=A0

Why a new group? I think that the OAuth = working group should remain focused on extending, patching, and adapting OA= uth 2.0 to a changing world. I plan to be engaged in both groups, and I kno= w most of you are as well, but that=E2=80=99s not universal. Since OAuth 2.= 0 is so established already, there are a LOT of people who aren=E2=80=99t g= oing to be interested in something new any time soon. But on the other hand= , there are a number of people for whom OAuth 2.0 does not work, or is at t= he very least a poor fit, and we=E2=80=99ll want to bring them in at this e= arly stage. So even with significant overlap, I think there=E2=80=99s enoug= h disconnect in the community from both sides that warrants a new group. In= addition, I think this is a big enough piece of work that it=E2=80=99s sim= ply too much for the OAuth working group to be able to focus on. We wouldn= =E2=80=99t be able to get additional meeting time, and OAuth already has tr= ouble fitting into its two meeting slots as it is.

<= div>

=C2=A0

I=E2=80=99ve published a blog post detailing more of my rationale= :

=C2=A0

=C2=A0

Pl= ease suggest changes to the proposed charter text above. It=E2=80=99s my ho= pe that we can get the chartering process started.

<= div>

=C2=A0

=C2=A0=E2=80=94 Justin

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth <= u>

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
----
Aaron = Parecki


-- =
----
Aaron Parecki
@aaronpk

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

CONFIDENTIALITY NOTICE: This email m= ay contain confidential and privileged material for the sole use of the int= ended recipient(s). Any review, use, distribution or disclosure by others i= s strictly prohibited.=C2=A0 If you have received this communication in err= or, please notify the sender immediately by e-mail and delete the message a= nd any file attachments from your computer. Thank you.

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000c6dd0d059aa212fb-- From nobody Thu Dec 26 14:54:08 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D17512009C for ; Thu, 26 Dec 2019 14:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 odSLkMan7KMf for ; Thu, 26 Dec 2019 14:54:03 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 F0660120025 for ; Thu, 26 Dec 2019 14:54:02 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBQMrmK5027423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Dec 2019 17:53:49 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: <5CC36DBF-4DA0-47FD-952B-2A41FF8342BA@hardjono.net> Date: Thu, 26 Dec 2019 17:53:48 -0500 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <887A5D73-9C0D-4BAE-981D-CDB3560E7BB9@mit.edu> References: <543EBD14-5629-48CA-8FE8-417678DADD97@hardjono.net> <5CC36DBF-4DA0-47FD-952B-2A41FF8342BA@hardjono.net> To: Thomas Hardjono X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2019 22:54:06 -0000 What goes into what draft is, I believe, still largely up for discussion = and decision by a WG. The charter doesn=E2=80=99t need to decide that = ahead of time. What the charter can do though is decide what=E2=80=99s = in and out of scope overall. That said, I think the core will need to define something like XYZ=E2=80=99= s =E2=80=9Cresources=E2=80=9D structure and how it relates to the rest = of the request. It=E2=80=99s possible that defining the details of what = goes in that structure lives elsewhere, but given how it=E2=80=99s = written in XYZ today I don=E2=80=99t think that is a necessary = abstraction layer. It=E2=80=99s a separate draft in OAuth just because = we didn=E2=80=99t have it in OAuth 2 to begin with, and look at the mess = that=E2=80=99s causing with the aud, resource, scope, and other = parameters. I think the problem of sharing security policies across security domains = is probably too much for this working group. Just look at everything = that=E2=80=99s happened with XACML and its descendants =E2=80=94 it=E2=80=99= s a very, very difficult problem space, with confusing solutions where = any exist at all. That said, I don=E2=80=99t see any reason the parts = that we define, like the resources block, couldn=E2=80=99t be used as = part of a separate cross-domain protocol. That=E2=80=99s one of the = benefits of separating the concerns of the request like this =E2=80=94 = but without the over-engineering and over-abstraction of something like = WS-*.=20 So I=E2=80=99d like to put inter-domain security policies out of scope = for this work. Thoughts? =E2=80=94 Justin > On Dec 26, 2019, at 11:45 AM, Thomas Hardjono = wrote: >=20 > Correction: TXauth core protocol (not TXT core protocol, as TXT is = Trusted Execution, and also the name of a K-Pop band). >=20 >=20 > =EF=BB=BF-----Original Message----- > From: Thomas Hardjono > Date: Thursday, December 26, 2019 at 11:42 AM > To: Justin Richer , > Subject: Re: [Txauth] TxAuth Proposed Charter >=20 >=20 > I know the proposed charter is still a drafty draft, but I have a = couple of high-level questions. >=20 > (i) Will there be a separate specification for the TXT core protocol = and for the "authorization_details" (Torsten's draft). Is this what the = proposaed Charter refers to as "Fine-grained specification of resource = access". >=20 > (ii) Will there be an AS-to-AS mechanism to deliver authorization = information (either in the "authorization_details" format or otherwise). = This is relevant for authorization federation (for ASes in different = domains) and for addressing some of the issues that Annabelle presented = at IETF106 (i.e. context sharing). >=20 >=20 > -- thomas -- >=20 >=20 >=20 > =EF=BB=BF-----Original Message----- > From: Txauth on behalf of Justin Richer = > Date: Friday, December 20, 2019 at 5:34 PM > To: > Cc: "rdd@cert.org" , Benjamin Kaduk > Subject: [Txauth] TxAuth Proposed Charter >=20 > Hi all, > As discussed in Singapore, no matter what forum TxAuth takes, its work = will require a new charter. With that in mind, I=E2=80=99ve taken a bit = of time to put together a proposed charter text for the TxAuth work: >=20 >=20 > This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 >=20 > The group will deliver a protocol specification detailing how a client = can request and obtain delegated access, how an authorization server can = provide delegated access, how an authorized party can authorize = delegated access, and how that authorized access can be communicated to = the resources being protected. These actions will be connected through = an explicit transaction between the client and authorization server, = resulting in an artifact that will allow the client to undertake the = delegated action.=20 >=20 > Additionally, the delegation process will allow for: > - Fine-grained specification of resource access > - Delegation between multiple users > - Web, mobile, single-page, and other client applications >=20 > The group will define extension points for this protocol to allow for = flexibility in areas including: >=20 > - Cryptographic agility for keys, message signatures, and proof of = possession=20 > - User interaction mechanisms including web and non-web methods > - Token presentation mechanisms and key bindings >=20 > The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >=20 >=20 >=20 > While this work could be done in within the OAuth working group, I now = believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >=20 > Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing = world. I plan to be engaged in both groups, and I know most of you are = as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >=20 > I=E2=80=99ve published a blog post detailing more of my rationale: >=20 > = https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? >=20 > Please suggest changes to the proposed charter text above. It=E2=80=99s = my hope that we can get the chartering process started. >=20 > =E2=80=94 Justin > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >=20 >=20 >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Thu Dec 26 15:10:44 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBF71200E7 for ; Thu, 26 Dec 2019 15:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.188 X-Spam-Level: X-Spam-Status: No, score=-4.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 2Ibvj-0jYb_r for ; Thu, 26 Dec 2019 15:10:39 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 979D4120025 for ; Thu, 26 Dec 2019 15:10:38 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBQNATKB030787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Dec 2019 18:10:29 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F8540848-EAC6-429E-87FB-6FB4C7F2577E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 26 Dec 2019 18:10:28 -0500 In-Reply-To: Cc: Aaron Parecki , "rdd@cert.org" , Yaron Sheffer , Benjamin Kaduk , txauth@ietf.org To: Brian Campbell References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2019 23:10:43 -0000 --Apple-Mail=_F8540848-EAC6-429E-87FB-6FB4C7F2577E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I hear you about the potential confusion, and believe me that=E2=80=99s = something I want to avoid as well. But I disagree with you about what = kind of confusion this would cause. I also believe that :not: doing the = work and :not: admitting what this work really is would be a greater = disservice than any temporary confusion that would come. Developers are = going to reach for the libraries and tools that solve their problems, = and for a while yet, that=E2=80=99s going to be OAuth 2. People will = move to something else as it both solves what they need and also is = available in their favorite platforms and libraries. Any successful = standard goes through this growth cycle, regardless of what you call it. = We saw some churn between OAuth 1 and 2 but nothing that was = unmanageable.=20 I think it=E2=80=99s clear that many existing vendors aren=E2=80=99t = going to be fans of a new protocol. After all, why invest in building = something new if you can keep selling what you=E2=80=99ve already built? = In the end, some will adopt it, some won=E2=80=99t. Just like there were = SAML vendors that implemented OIDC as well, and some that didn=E2=80=99t. = Either of those is fine, though =E2=80=94 nobody=E2=80=99s forcing = anyone to follow along with new work. Those that did were sometimes = dragged into it by customer demand, others were quick to dive in front = of what they saw as a trend. And of course there were a lot of OIDC = vendors who never wrote a SAML implementation in the first place. All of = those decisions amount to managing the marketplace, and us pretending = that the technology world is going to stand still for the sake of = existing implementations isn=E2=80=99t doing anybody any favors.=20 As for authentication, maybe it=E2=80=99s time that we, as a community, = admit that we=E2=80=99re the source of the confusion. Yes, we=E2=80=99ve = been explaining to people for many years that OAuth isn=E2=80=99t = authentication. Except for when it is, and you call it by a different = name like OIDC (or Facebook Connect, or Sign In With GitHub, etc=E2=80=A6.= ) if you think to, but most developers still call what they=E2=80=99re = doing =E2=80=9Cauthenticating with OAuth=E2=80=9D. So why don=E2=80=99t = we admit that maybe we did it wrong last time around? Even with that in = mind, I still think that the identity/authentication layer should be = separate and on top of the base delegation protocol, since they should = be separable from each other. Maybe the identity layer will even get a = new non-OAuth name, too. That doesn=E2=80=99t mean that they should be = in different working groups, though, and I=E2=80=99d be glad to see them = come together with this work. Also, note that most of what OIDC had to invent was to patch holes in = OAuth=E2=80=99s core that arguably shouldn=E2=80=99t have been there in = the first place. There=E2=80=99s remarkably little in OIDC that is = required to make the identity protocol portions work, and I think Aaron = P=E2=80=99s pointed out some ways in which that could be slimmed down = even more with this work.=20 And finally, I am not at all a fan of the name =E2=80=9CMOAuth=E2=80=9D, = and personally think it=E2=80=99s even more confusing than just calling = this OAuth 3.=20 =E2=80=94 Justin > On Dec 26, 2019, at 4:29 PM, Brian Campbell = wrote: >=20 >=20 > [doctored image credit: Nishant Kaushik] >=20 > Well, I'm already on record at the Singapore BoF (in a rambling = incoherent jetlagged kind of way but still) as not supporting = progression of this work. Concern around the confusion it'll cause in = the wider community is one of my reasons for that opposition and I = personally think that using the OAuth brand will exacerbate potential = perception issues and confusion. But with that said, while I don't = necessarily agree with you, I do think your arguments hold up for = TXAuth/XYZ as an authorization protocol. However, bringing = identity/authentication into it would broaden the scope beyond the = evolution of an authorization protocol and into the realm of OIDC (and = even SAML), which is something we've been fighting to explain to the = world that OAuth isn't for years. The message that you don't ever do = user authentication with OAuth unless it's this particular version of = OAuth would be crazy confusing.=20 >=20 > So with all that being said, I'll throw out the strawman name of = MOAUTH*, which is soft of a combination of a portmanteau and a play on = word sounds. It could be taken as "More OAuth" or "More Than OAuth" or = "MOre Auth[n/z]" or similar.. It'd maintain some link to OAuth heritage = while indicating progression/evolution and more easily allowing for a = potentially a broadening scope to include identity and user = authentication. =20 >=20 >=20 > * I cannot claim credit for MOAUTH but I don't know if the person from = whom I got the idea wants to be named so that'll be withheld for the = time being=20 >=20 >=20 >=20 >=20 > On Tue, Dec 24, 2019 at 5:21 PM Justin Richer > wrote: > Brian, I hear what you=E2=80=99re saying, but I disagree completely. >=20 > Who would be confused by seeing a major revision to an existing = protocol that worked in a different way and did the same things but also = new things? That happens all the time. >=20 > Was there significant confusion between OAuth 1 and 2, enough to = hamper adoption of either? For the people who deeply invested in OAuth 1 = and didn=E2=80=99t need or want the OAuth 2 newness, they stuck with it = (see: twitter).=20 >=20 > Was OpenID Connect a major disservice to OpenID 2? It was a = disruption, for sure, but people transitioned where it made sense for = them, and in many cases that took years of dual-deployment and = transition.=20 >=20 > I see us walking along the same kind of path here, nearly a decade = later. That=E2=80=99s why I think OAuth 3 makes sense as a name for the = output of this work. Or at the very least, for the core delegation = protocol portion of whatever we make. I think it sends the right message = to implementers and developers: the community that knows and understands = OAuth 2 is working on the next version of that thing, so when it=E2=80=99s= ready, maybe you should look at it. Until it=E2=80=99s done, and for a = long time after, OAuth 2 is still going to be there and be the right = answer.=20 >=20 > The name isn=E2=80=99t a hill I=E2=80=99m committed to dying alone on, = but I think it sends a :bad: message if we call it something new = entirely. Namely, that we think people :should: abandon the entire world = of OAuth, all of its ideas and implementations. That=E2=80=99s not what = we=E2=80=99re doing with this design, it=E2=80=99s an evolution as I see = things. And as an evolution, a new major revision number makes sense. >=20 > =E2=80=94 Justin >=20 >> On Dec 24, 2019, at 9:54 AM, Brian Campbell = > wrote: >>=20 >> Naming any prospective resulting work here "OAuth 3.0" would = significantly exacerbate confusion in the whole space and would be a = major disservice to the broader community.=20 >>=20 >>=20 >> On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki > wrote: >> I definitely am not trying to discuss specifics of *how* = authentication should be included right now, but I just want to make = sure it's included in the charter so that we can actually talk about it = and it won't be "out of scope" when we eventually do talk about the = specifics. >>=20 >> Aaron >>=20 >>=20 >>=20 >> On Mon, Dec 23, 2019 at 1:51 PM Justin Richer > wrote: >> I=E2=80=99m fine with it being in charter but I do think it should be = a clearly separate layer, much like OIDC/Facebook Connect/GitHub = Login/etc are with OAuth today. In all of these the authorization is = first, and I think that=E2=80=99s the right pattern. So if we do take it = on we=E2=80=99ll just need to be careful how it=E2=80=99s structured in = with everything else. Otherwise, I think the authentication side can = quickly overwhelm and drag down the authorization side. >>=20 >> Good news: A lot of the additional stuff in OIDC is there to patch = holes in core OAuth in a common fashion, and we=E2=80=99ll at least be = in a position to not have to do that again.=20 >>=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Dec 22, 2019, at 10:46 PM, Aaron Parecki > wrote: >>>=20 >>> I do think authentication should be part of the charter from the = outset. Frankly the fact that authentication is intentionally left out = of OAuth and has to be bolted on to the side via OpenID Connect is one = of the exact reasons people get confused about the whole space to begin = with.=20 >>>=20 >>> It's a relatively minor addition to the existing proposed spec to = make it useful as a minimum viable authentication solution, and I'd like = to see that be addressed at the beginning of this work. >>>=20 >>> I think we can do this in a smart way and that authentication should = be included in the charter. >>>=20 >>> Aaron >>>=20 >>>=20 >>>=20 >>>=20 >>> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer > wrote: >>> Hi Justin, >>>=20 >>> =20 >>>=20 >>> I think the charter should mention target use cases. For example, = =E2=80=9Call use cases supported by OAuth 2 will be supported by the new = protocol=E2=80=9D or =E2=80=9Cthe protocol will support at least use = cases X and Y=E2=80=9D. >>>=20 >>> =20 >>>=20 >>> And given the importance of OIDC, we could say something like: = =E2=80=9CThe protocol will allow future extension to support = authentication, in an analogous way to OpenID Connect. However = authentication is explicitly not part of the initial scope.=E2=80=9D >>>=20 >>> =20 >>>=20 >>> Thanks, >>>=20 >>> Yaron >>>=20 >>> =20 >>>=20 >>> From: Txauth > on behalf of Justin Richer = > >>> Date: Saturday, December 21, 2019 at 00:34 >>> To: > >>> Cc: "rdd@cert.org " >, Benjamin Kaduk > >>> Subject: [Txauth] TxAuth Proposed Charter >>>=20 >>> =20 >>>=20 >>> Hi all, >>>=20 >>> =20 >>>=20 >>> As discussed in Singapore, no matter what forum TxAuth takes, its = work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of time to put together a proposed charter text for the TxAuth work: >>>=20 >>> =20 >>>=20 >>> This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 >>>=20 >>> =20 >>>=20 >>> The group will deliver a protocol specification detailing how a = client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>>=20 >>> =20 >>>=20 >>> Additionally, the delegation process will allow for: >>>=20 >>> - Fine-grained specification of resource access >>>=20 >>> - Delegation between multiple users >>>=20 >>> - Web, mobile, single-page, and other client applications >>>=20 >>> =20 >>>=20 >>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>=20 >>> =20 >>>=20 >>> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >>>=20 >>> - User interaction mechanisms including web and non-web methods >>>=20 >>> - Token presentation mechanisms and key bindings >>>=20 >>> =20 >>>=20 >>> The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >>>=20 >>> =20 >>>=20 >>> While this work could be done in within the OAuth working group, I = now believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>>=20 >>> =20 >>>=20 >>> Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing = world. I plan to be engaged in both groups, and I know most of you are = as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>>=20 >>> =20 >>>=20 >>> I=E2=80=99ve published a blog post detailing more of my rationale: >>>=20 >>> =20 >>>=20 >>> = https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-worki= ng-group-d6229ba8e36? = >>> =20 >>>=20 >>> Please suggest changes to the proposed charter text above. It=E2=80=99= s my hope that we can get the chartering process started. >>>=20 >>> =20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>> -- Txauth mailing list Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth = --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>> --=20 >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>>=20 >>=20 >> --=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. --Apple-Mail=_F8540848-EAC6-429E-87FB-6FB4C7F2577E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I hear you about the potential confusion, and believe me = that=E2=80=99s something I want to avoid as well. But I disagree with = you about what kind of confusion this would cause. I also believe that = :not: doing the work and :not: admitting what this work really is would = be a greater disservice than any temporary confusion that would come. = Developers are going to reach for the libraries and tools that solve = their problems, and for a while yet, that=E2=80=99s going to be OAuth 2. = People will move to something else as it both solves what they need and = also is available in their favorite platforms and libraries. Any = successful standard goes through this growth cycle, regardless of what = you call it. We saw some churn between OAuth 1 and 2 but nothing that = was unmanageable. 

I think it=E2=80=99s clear that many existing vendors = aren=E2=80=99t going to be fans of a new protocol. After all, why invest = in building something new if you can keep selling what you=E2=80=99ve = already built? In the end, some will adopt it, some won=E2=80=99t. Just = like there were SAML vendors that implemented OIDC as well, and some = that didn=E2=80=99t. Either of those is fine, though =E2=80=94 = nobody=E2=80=99s forcing anyone to follow along with new work. Those = that did were sometimes dragged into it by customer demand, others were = quick to dive in front of what they saw as a trend. And of course there = were a lot of OIDC vendors who never wrote a SAML implementation in the = first place. All of those decisions amount to managing the marketplace, = and us pretending that the technology world is going to stand still for = the sake of existing implementations isn=E2=80=99t doing anybody any = favors. 

As for = authentication, maybe it=E2=80=99s time that we, as a community, admit = that we=E2=80=99re the source of the confusion. Yes, we=E2=80=99ve been = explaining to people for many years that OAuth isn=E2=80=99t = authentication. Except for when it is, and you call it by a different = name like OIDC (or Facebook Connect, or Sign In With GitHub, etc=E2=80=A6.= ) if you think to, but most developers still call what they=E2=80=99re = doing =E2=80=9Cauthenticating with OAuth=E2=80=9D. So why don=E2=80=99t = we admit that maybe we did it wrong last time around? Even with that in = mind, I still think that the identity/authentication layer should be = separate and on top of the base delegation protocol, since they should = be separable from each other. Maybe the identity layer will even get a = new non-OAuth name, too. That doesn=E2=80=99t mean that they should be = in different working groups, though, and I=E2=80=99d be glad to see them = come together with this work.

Also, note that most of what OIDC had to invent was to patch = holes in OAuth=E2=80=99s core that arguably shouldn=E2=80=99t have been = there in the first place. There=E2=80=99s remarkably little in OIDC that = is required to make the identity protocol portions work, and I think = Aaron P=E2=80=99s pointed out some ways in which that could be slimmed = down even more with this work. 

And finally, I am not at all a fan of = the name =E2=80=9CMOAuth=E2=80=9D, and personally think it=E2=80=99s = even more confusing than just calling this OAuth 3. 

 =E2=80=94 = Justin

On Dec 26, 2019, at 4:29 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:


[doctored image credit: Nishant = Kaushik]

Well, I'm already on record at the Singapore BoF (in a rambling = incoherent jetlagged kind of way but still) as = not supporting progression of this work. Concern around the confusion = it'll cause in the wider community is one of my reasons for that = opposition and I personally think that using the OAuth brand will exacerbate = potential perception issues and confusion. But with that said, while I = don't necessarily agree with you, I do think your arguments hold up for = TXAuth/XYZ as an authorization protocol. However, bringing = identity/authentication into it would broaden the scope beyond the = evolution of an authorization protocol and into the realm of OIDC (and even SAML), which is something we've been fighting to = explain to the world that OAuth isn't for years. The = message that you don't ever do user authentication with OAuth unless it's this particular = version of OAuth would be crazy = confusing. 

So = with all that being said, I'll throw out the strawman name of MOAUTH*, = which is soft of a combination of a portmanteau and a play on word = sounds. It could be taken as "More OAuth" or "More Than OAuth" or "MOre = Auth[n/z]" or similar.. It'd maintain some link to OAuth heritage while = indicating progression/evolution and more easily allowing for a = potentially a broadening scope to include identity and user = authentication.  


* I cannot claim credit for MOAUTH but I = don't know if the person from whom I got the idea wants to be named so = that'll be withheld for the time being 




On Tue, Dec 24, 2019 at 5:21 PM Justin Richer = <jricher@mit.edu> wrote:
Brian, I hear = what you=E2=80=99re saying, but I disagree completely.

Who would be confused by seeing a major = revision to an existing protocol that worked in a different way and did = the same things but also new things? That happens all the = time.

Was = there significant confusion between OAuth 1 and 2, enough to hamper = adoption of either? For the people who deeply invested in OAuth 1 and = didn=E2=80=99t need or want the OAuth 2 newness, they stuck with it = (see: twitter). 

Was OpenID Connect a major disservice to OpenID 2? It was a = disruption, for sure, but people transitioned where it made sense for = them, and in many cases that took years of dual-deployment and = transition. 

I see us walking along the same kind of path here, nearly a = decade later. That=E2=80=99s why I think OAuth 3 makes sense as a name = for the output of this work. Or at the very least, for the core = delegation protocol portion of whatever we make. I think it sends the = right message to implementers and developers: the community that knows = and understands OAuth 2 is working on the next version of that thing, so = when it=E2=80=99s ready, maybe you should look at it. Until it=E2=80=99s = done, and for a long time after, OAuth 2 is still going to be there and = be the right answer. 

The name isn=E2=80=99t a hill I=E2=80=99m committed to dying = alone on, but I think it sends a :bad: message if we call it something = new entirely. Namely, that we think people :should: abandon the entire = world of OAuth, all of its ideas and implementations. That=E2=80=99s not = what we=E2=80=99re doing with this design, it=E2=80=99s an evolution as = I see things. And as an evolution, a new major revision number makes = sense.

 =E2= =80=94 Justin

On Dec 24, 2019, at 9:54 AM, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Naming any prospective resulting work here = "OAuth 3.0" would significantly exacerbate confusion in the whole space = and would be a major disservice to the broader community. 


On Mon, Dec = 23, 2019 at 7:39 PM Aaron Parecki <aaron@parecki.com> wrote:
I definitely am not trying to = discuss specifics of *how* authentication should be included right now, = but I just want to make sure it's included in the charter so that we can = actually talk about it and it won't be "out of scope" when we eventually = do talk about the specifics.

Aaron



On Mon, Dec = 23, 2019 at 1:51 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m fine with it being in charter but I do think it = should be a clearly separate layer, much like OIDC/Facebook = Connect/GitHub Login/etc are with OAuth today. In all of these the = authorization is first, and I think that=E2=80=99s the right pattern. So = if we do take it on we=E2=80=99ll just need to be careful how it=E2=80=99s= structured in with everything else. Otherwise, I think the = authentication side can quickly overwhelm and drag down the = authorization side.

Good news: A lot of the additional stuff in OIDC is there to = patch holes in core OAuth in a common fashion, and we=E2=80=99ll at = least be in a position to not have to do that = again. 


 =E2=80= =94 Justin

On Dec 22, 2019, at 10:46 PM, = Aaron Parecki <aaron@parecki.com> wrote:

I do think = authentication should be part of the charter from the outset. Frankly = the fact that authentication is intentionally left out of OAuth and has = to be bolted on to the side via OpenID Connect is one of the exact = reasons people get confused about the whole space to begin = with. 

It's a relatively minor = addition to the existing proposed spec to make it useful as a minimum = viable authentication solution, and I'd like to see that be addressed at = the beginning of this work.

I think we can do this in = a smart way and that authentication should be included in the = charter.

Aaron




On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

Hi = Justin,

 

I = think the charter should mention target use cases. For example, =E2=80=9Ca= ll use cases supported by OAuth 2 will be supported by the new = protocol=E2=80=9D or =E2=80=9Cthe protocol will support at least use = cases X and Y=E2=80=9D.

 

And given the importance of OIDC, we could say = something like: =E2=80=9CThe protocol will allow future extension to = support authentication, in an analogous way to OpenID Connect. However = authentication is explicitly not part of the initial scope.=E2=80=9D

 

Thanks,

         =        Yaron

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer = <jricher@mit.edu>
Date: Saturday, December 21, = 2019 at 00:34
To: <txauth@ietf.org>
Cc: "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>
Subject: [Txauth] TxAuth = Proposed Charter

 

Hi all,

 

As = discussed in Singapore, no matter what forum TxAuth takes, its work will = require a new charter. With that in mind, I=E2=80=99ve taken a bit of = time to put together a proposed charter text for the TxAuth work:

 

This= group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing = party. 

 

The = group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can = provide delegated access, how an authorized party can authorize = delegated access, and how that authorized access can be communicated to = the resources being protected. These actions will be connected through = an explicit transaction between the client and authorization server, = resulting in an artifact that will allow the client to undertake the = delegated action. 

 

Additionally, the delegation process will allow = for:

- Fine-grained specification of resource access

- Delegation between multiple users

- Web, mobile, single-page, and other client = applications

 

The = group will define extension points for this protocol to allow for = flexibility in areas including:

 

- Cryptographic agility for keys, message = signatures, and proof of possession 

- User = interaction mechanisms including web and non-web methods

- Token presentation mechanisms and key bindings

 

The = artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions. 

 

While = this work could be done in within the OAuth working group, I now believe = that it should be done in a new working group, and that we should try to = get that working group up and running prior to the Vancouver meeting in = March. I think this group should stay here on the TxAuth list, and = it=E2=80=99s my suggestion that the resulting work be called OAuth = 3.0. 

 

Why a = new group? I think that the OAuth working group should remain focused on = extending, patching, and adapting OAuth 2.0 to a changing world. I plan = to be engaged in both groups, and I know most of you are as well, but = that=E2=80=99s not universal. Since OAuth 2.0 is so established already, = there are a LOT of people who aren=E2=80=99t going to be interested in = something new any time soon. But on the other hand, there are a number = of people for whom OAuth 2.0 does not work, or is at the very least a = poor fit, and we=E2=80=99ll want to bring them in at this early stage. = So even with significant overlap, I think there=E2=80=99s enough = disconnect in the community from both sides that warrants a new group. = In addition, I think this is a big enough piece of work that it=E2=80=99s = simply too much for the OAuth working group to be able to focus on. We = wouldn=E2=80=99t be able to get additional meeting time, and OAuth = already has trouble fitting into its two meeting slots as it is.

 

I=E2=80=99= ve published a blog post detailing more of my rationale:

 

https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-= a-new-working-group-d6229ba8e36?

 

Please suggest changes to the proposed charter text = above. It=E2=80=99s my hope that we can get the chartering process = started.

 

 =E2=80= =94 Justin

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
-- 
----
Aaron = Parecki
aaronparecki.com
@aaronpk


-- 
----
Aaron = Parecki
aaronparecki.com
@aaronpk

-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.


CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.

= --Apple-Mail=_F8540848-EAC6-429E-87FB-6FB4C7F2577E-- From nobody Fri Dec 27 08:31:28 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098AC120091 for ; Fri, 27 Dec 2019 08:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=hardjono.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JptXF_WBM-m9 for ; Fri, 27 Dec 2019 08:31:24 -0800 (PST) Received: from gateway34.websitewelcome.com (gateway34.websitewelcome.com [192.185.149.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F4A120019 for ; Fri, 27 Dec 2019 08:31:24 -0800 (PST) Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway34.websitewelcome.com (Postfix) with ESMTP id 20DC13E9B4F1 for ; Fri, 27 Dec 2019 10:29:20 -0600 (CST) Received: from box5207.bluehost.com ([162.241.224.194]) by cmsmtp with SMTP id ksUKiZZT63Qi0ksUKiPI7K; Fri, 27 Dec 2019 10:29:20 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hardjono.net; s=default; h=Content-transfer-encoding:Content-type: Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8+TiHbAhAtSJo6Gec08pEbhdvVFyZVizFSAYuBmZyZc=; b=CmedIj5s3lOsgPakuI5mea01uR HN1YXYCGsU8qhhc0TFcMLZsitIZ8J4enas17XWF7P0eQR/KnCIj482nSfmXRUNlLfC4yHW9AmMsB/ 4FtEoK9PSDbh2/QLV8ruyy7Yw; Received: from c-73-167-220-69.hsd1.ma.comcast.net ([73.167.220.69]:57130 helo=[10.0.0.194]) by box5207.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iksUJ-004A5P-Pz; Fri, 27 Dec 2019 09:29:19 -0700 User-Agent: Microsoft-MacOutlook/10.10.11.191208 Date: Fri, 27 Dec 2019 11:29:17 -0500 From: Thomas Hardjono To: Justin Richer CC: Message-ID: <3191A5CA-4D42-44ED-BB49-8335E18C3CDD@hardjono.net> Thread-Topic: [Txauth] TxAuth Proposed Charter References: <543EBD14-5629-48CA-8FE8-417678DADD97@hardjono.net> <5CC36DBF-4DA0-47FD-952B-2A41FF8342BA@hardjono.net> <887A5D73-9C0D-4BAE-981D-CDB3560E7BB9@mit.edu> In-Reply-To: <887A5D73-9C0D-4BAE-981D-CDB3560E7BB9@mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5207.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hardjono.net X-BWhitelist: no X-Source-IP: 73.167.220.69 X-Source-L: No X-Exim-ID: 1iksUJ-004A5P-Pz X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-73-167-220-69.hsd1.ma.comcast.net ([10.0.0.194]) [73.167.220.69]:57130 X-Source-Auth: ietf-txauth@hardjono.net X-Email-Count: 1 X-Source-Cap: aGFyZGpvbm87aGFyZGpvbm87Ym94NTIwNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 16:31:26 -0000 Justin, >>> So I=E2=80=99d like to put inter-domain security policies out of scope for th= is work. Thoughts? Of course. I'm not proposing that TXauth create a new policy-expression syn= tax. These already exist (e.g. SAML, XACML). What I was suggesting that the = authorization_details (in the PSD2 example from Torsten) needs to have stand= ardized identification (akin to policy-oids) so that both the AS and RS are = referring to the same syntax. This is pretty easy, I think. Re-reading your medium blog and your IETF slides, I get the impression that= you are (we are) skirting around the problem or role-based access control (= RBAC). So why not just express XYZ in those terms while using the OAuth2.0 n= omenclature.=20 If we can define "roles" attached to "permissions" (permission being expres= sed as scopes), then we can solve much of the ambiguities in OAuth2.0 (which= UMA tried to solve to some extent (e.g. the Alice-to-Alice case)). Example: Alice-as-RO-role is giving Alice-as-Requestor-role access to files= at the RS at this location. Alice-as-Requestor-role can indicate intent (as= in the XYZ proposal). Another example: Alice-as-RO-role gives Client-Operator permission (consen= t) to interact with the AS and RS on Alice's behalf. -- thomas -- =EF=BB=BF-----Original Message----- From: Justin Richer Date: Thursday, December 26, 2019 at 5:54 PM To: Thomas Hardjono Cc: Subject: Re: [Txauth] TxAuth Proposed Charter What goes into what draft is, I believe, still largely up for discussion an= d decision by a WG. The charter doesn=E2=80=99t need to decide that ahead of time.= What the charter can do though is decide what=E2=80=99s in and out of scope overa= ll. That said, I think the core will need to define something like XYZ=E2=80=99s =E2=80=9Cr= esources=E2=80=9D structure and how it relates to the rest of the request. It=E2=80=99s = possible that defining the details of what goes in that structure lives else= where, but given how it=E2=80=99s written in XYZ today I don=E2=80=99t think that is a n= ecessary abstraction layer. It=E2=80=99s a separate draft in OAuth just because we= didn=E2=80=99t have it in OAuth 2 to begin with, and look at the mess that=E2=80=99s ca= using with the aud, resource, scope, and other parameters. I think the problem of sharing security policies across security domains is= probably too much for this working group. Just look at everything that=E2=80=99s = happened with XACML and its descendants =E2=80=94 it=E2=80=99s a very, very difficult pr= oblem space, with confusing solutions where any exist at all. That said, I d= on=E2=80=99t see any reason the parts that we define, like the resources block, co= uldn=E2=80=99t be used as part of a separate cross-domain protocol. That=E2=80=99s one o= f the benefits of separating the concerns of the request like this =E2=80=94 but w= ithout the over-engineering and over-abstraction of something like WS-*.=20 So I=E2=80=99d like to put inter-domain security policies out of scope for this w= ork. Thoughts? =E2=80=94 Justin > On Dec 26, 2019, at 11:45 AM, Thomas Hardjono = wrote: >=20 > Correction: TXauth core protocol (not TXT core protocol, as TXT is Truste= d Execution, and also the name of a K-Pop band). >=20 >=20 > =EF=BB=BF-----Original Message----- > From: Thomas Hardjono > Date: Thursday, December 26, 2019 at 11:42 AM > To: Justin Richer , > Subject: Re: [Txauth] TxAuth Proposed Charter >=20 >=20 > I know the proposed charter is still a drafty draft, but I have a couple = of high-level questions. >=20 > (i) Will there be a separate specification for the TXT core protocol and = for the "authorization_details" (Torsten's draft). Is this what the proposae= d Charter refers to as "Fine-grained specification of resource access". >=20 > (ii) Will there be an AS-to-AS mechanism to deliver authorization informa= tion (either in the "authorization_details" format or otherwise). This is re= levant for authorization federation (for ASes in different domains) and for = addressing some of the issues that Annabelle presented at IETF106 (i.e. cont= ext sharing). >=20 >=20 > -- thomas -- >=20 >=20 >=20 > =EF=BB=BF-----Original Message----- > From: Txauth on behalf of Justin Richer > Date: Friday, December 20, 2019 at 5:34 PM > To: > Cc: "rdd@cert.org" , Benjamin Kaduk > Subject: [Txauth] TxAuth Proposed Charter >=20 > Hi all, > As discussed in Singapore, no matter what forum TxAuth takes, its work wi= ll require a new charter. With that in mind, I=E2=80=99ve taken a bit of time to p= ut together a proposed charter text for the TxAuth work: >=20 >=20 > This group is chartered to develop a next-generation transactional author= ization and delegation protocol for HTTP-based APIs and their clients. These= transactions will allow an authorizing party to delegate a right of access = for an API or set of APIs through an authorization server to a software clie= nt acting on behalf of an authorizing party.=20 >=20 > The group will deliver a protocol specification detailing how a client ca= n request and obtain delegated access, how an authorization server can provi= de delegated access, how an authorized party can authorize delegated access,= and how that authorized access can be communicated to the resources being p= rotected. These actions will be connected through an explicit transaction be= tween the client and authorization server, resulting in an artifact that wil= l allow the client to undertake the delegated action.=20 >=20 > Additionally, the delegation process will allow for: > - Fine-grained specification of resource access > - Delegation between multiple users > - Web, mobile, single-page, and other client applications >=20 > The group will define extension points for this protocol to allow for fle= xibility in areas including: >=20 > - Cryptographic agility for keys, message signatures, and proof of posses= sion=20 > - User interaction mechanisms including web and non-web methods > - Token presentation mechanisms and key bindings >=20 > The artifacts for this work are not intended or expected to be backwards-= compatible with OAuth 2.0 and its extensions.=20 >=20 >=20 >=20 > While this work could be done in within the OAuth working group, I now be= lieve that it should be done in a new working group, and that we should try = to get that working group up and running prior to the Vancouver meeting in M= arch. I think this group should stay here on the TxAuth list, and it=E2=80=99s my = suggestion that the resulting work be called OAuth 3.0.=20 >=20 > Why a new group? I think that the OAuth working group should remain focus= ed on extending, patching, and adapting OAuth 2.0 to a changing world. I pla= n to be engaged in both groups, and I know most of you are as well, but that= =E2=80=99s not universal. Since OAuth 2.0 is so established already, there are a L= OT of people who aren=E2=80=99t going to be interested in something new any time s= oon. But on the other hand, there are a number of people for whom OAuth 2.0 = does not work, or is at the very least a poor fit, and we=E2=80=99ll want to bring= them in at this early stage. So even with significant overlap, I think ther= e=E2=80=99s enough disconnect in the community from both sides that warrants a new= group. In addition, I think this is a big enough piece of work that it=E2=80=99s = simply too much for the OAuth working group to be able to focus on. We would= n=E2=80=99t be able to get additional meeting time, and OAuth already has trouble = fitting into its two meeting slots as it is. >=20 > I=E2=80=99ve published a blog post detailing more of my rationale: >=20 > https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-worki= ng-group-d6229ba8e36? >=20 > Please suggest changes to the proposed charter text above. It=E2=80=99s my hope= that we can get the chartering process started. >=20 > =E2=80=94 Justin > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >=20 >=20 >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Fri Dec 27 08:35:11 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454F4120091 for ; Fri, 27 Dec 2019 08:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=hardjono.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzgnKl9S2zaJ for ; Fri, 27 Dec 2019 08:35:07 -0800 (PST) Received: from gateway32.websitewelcome.com (gateway32.websitewelcome.com [192.185.145.182]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE98120019 for ; Fri, 27 Dec 2019 08:35:06 -0800 (PST) Received: from cm11.websitewelcome.com (cm11.websitewelcome.com [100.42.49.5]) by gateway32.websitewelcome.com (Postfix) with ESMTP id 397433FE33F for ; Fri, 27 Dec 2019 10:35:06 -0600 (CST) Received: from box5207.bluehost.com ([162.241.224.194]) by cmsmtp with SMTP id ksZuiM1SviJ43ksZuihfWX; Fri, 27 Dec 2019 10:35:06 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hardjono.net; s=default; h=Content-transfer-encoding:Content-type: Mime-version:In-Reply-To:References:Message-ID:CC:To:From:Subject:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QOvO6Olh2pQmnYZ//apcYqmpBwQiUazJmvCMy7yzsro=; b=I8AHXf3d4r06Ew9cXc5h0G97ib RDMsi9tlfGTiWFGgS5G3JJN1494DHaEN7J8dcOsCtIjWGDfjsROZKlZJ1gaSX2Mb5SfWamJttBoV4 jEuRbCSa1XfdVu6zVvylrGNCh; Received: from c-73-167-220-69.hsd1.ma.comcast.net ([73.167.220.69]:57564 helo=[10.0.0.194]) by box5207.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iksZt-004Bw0-Jy; Fri, 27 Dec 2019 09:35:05 -0700 User-Agent: Microsoft-MacOutlook/10.10.11.191208 Date: Fri, 27 Dec 2019 11:35:03 -0500 From: Thomas Hardjono To: Justin Richer , Brian Campbell CC: Message-ID: Thread-Topic: [Txauth] TxAuth Proposed Charter References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5207.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hardjono.net X-BWhitelist: no X-Source-IP: 73.167.220.69 X-Source-L: No X-Exim-ID: 1iksZt-004Bw0-Jy X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-73-167-220-69.hsd1.ma.comcast.net ([10.0.0.194]) [73.167.220.69]:57564 X-Source-Auth: ietf-txauth@hardjono.net X-Email-Count: 3 X-Source-Cap: aGFyZGpvbm87aGFyZGpvbm87Ym94NTIwNy5ibHVlaG9zdC5jb20= X-Local-Domain: yes Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 16:35:09 -0000 +1 for calling it OAuth3.0. The market will decide. It will stay on OAuth2.0 for some years still (just= as with SAML2.0). -- thomas -- =EF=BB=BF-----Original Message----- From: Txauth on behalf of Justin Richer Date: Thursday, December 26, 2019 at 6:10 PM To: Brian Campbell Cc: "rdd@cert.org" , Yaron Sheffer , B= enjamin Kaduk , Aaron Parecki , Subject: Re: [Txauth] TxAuth Proposed Charter I hear you about the potential confusion, and believe me that=E2=80=99s something= I want to avoid as well. But I disagree with you about what kind of confusi= on this would cause. I also believe that :not: doing the work and :not: admi= tting what this work really is would be a greater disservice than any tempor= ary confusion that would come. Developers are going to reach for the librari= es and tools that solve their problems, and for a while yet, that=E2=80=99s going = to be OAuth 2. People will move to something else as it both solves what the= y need and also is available in their favorite platforms and libraries. Any = successful standard goes through this growth cycle, regardless of what you c= all it. We saw some churn between OAuth 1 and 2 but nothing that was unmanag= eable.=20 I think it=E2=80=99s clear that many existing vendors aren=E2=80=99t going to be fans o= f a new protocol. After all, why invest in building something new if you can= keep selling what you=E2=80=99ve already built? In the end, some will adopt it, s= ome won=E2=80=99t. Just like there were SAML vendors that implemented OIDC as well= , and some that didn=E2=80=99t. Either of those is fine, though =E2=80=94 nobody=E2=80=99s for= cing anyone to follow along with new work. Those that did were sometimes dra= gged into it by customer demand, others were quick to dive in front of what = they saw as a trend. And of course there were a lot of OIDC vendors who neve= r wrote a SAML implementation in the first place. All of those decisions amo= unt to managing the marketplace, and us pretending that the technology world= is going to stand still for the sake of existing implementations isn=E2=80=99t do= ing anybody any favors.=20 As for authentication, maybe it=E2=80=99s time that we, as a community, admit tha= t we=E2=80=99re the source of the confusion. Yes, we=E2=80=99ve been explaining to peopl= e for many years that OAuth isn=E2=80=99t authentication. Except for when it is, a= nd you call it by a different name like OIDC (or Facebook Connect, or Sign I= n With GitHub, etc=E2=80=A6.) if you think to, but most developers still call what= they=E2=80=99re doing =E2=80=9Cauthenticating with OAuth=E2=80=9D. So why don=E2=80=99t we admit th= at maybe we did it wrong last time around? Even with that in mind, I still t= hink that the identity/authentication layer should be separate and on top of= the base delegation protocol, since they should be separable from each othe= r. Maybe the identity layer will even get a new non-OAuth name, too. That do= esn=E2=80=99t mean that they should be in different working groups, though, and I=E2= =80=99d be glad to see them come together with this work. Also, note that most of what OIDC had to invent was to patch holes in OAuth= =E2=80=99s core that arguably shouldn=E2=80=99t have been there in the first place. Ther= e=E2=80=99s remarkably little in OIDC that is required to make the identity protoc= ol portions work, and I think Aaron P=E2=80=99s pointed out some ways in which tha= t could be slimmed down even more with this work.=20 And finally, I am not at all a fan of the name =E2=80=9CMOAuth=E2=80=9D, and personally= think it=E2=80=99s even more confusing than just calling this OAuth 3.=20 =E2=80=94 Justin On Dec 26, 2019, at 4:29 PM, Brian Campbell wr= ote: [doctored image credit: Nishant Kaushik] Well, I'm already on record at the Singapore BoF (in a rambling incoherent = jetlagged kind of way but still) as not supporting progression of this work.= Concern around the confusion it'll cause in the wider community is one of m= y reasons for that opposition and I personally think that using the OAuth br= and will exacerbate potential perception issues and confusion. But with that= said, while I don't necessarily agree with you, I do think your arguments h= old up for TXAuth/XYZ as an authorization protocol. However, bringing identi= ty/authentication into it would broaden the scope beyond the evolution of an= authorization protocol and into the realm of OIDC (and even SAML), which is= something we've been fighting to explain to the world that OAuth isn't for = years. The message that you don't ever do user authentication with OAuth unl= ess it's this particular version of OAuth would be crazy confusing.=20 So with all that being said, I'll throw out the strawman name of MOAUTH*, w= hich is soft of a combination of a portmanteau and a play on word sounds. It= could be taken as "More OAuth" or "More Than OAuth" or "MOre Auth[n/z]" or = similar.. It'd maintain some link to OAuth heritage while indicating progres= sion/evolution and more easily allowing for a potentially a broadening scope= to include identity and user authentication. =20 * I cannot claim credit for MOAUTH but I don't know if the person from whom= I got the idea wants to be named so that'll be withheld for the time being=20 On Tue, Dec 24, 2019 at 5:21 PM Justin Richer wrote: Brian, I hear what you=E2=80=99re saying, but I disagree completely. Who would be confused by seeing a major revision to an existing protocol th= at worked in a different way and did the same things but also new things? Th= at happens all the time. Was there significant confusion between OAuth 1 and 2, enough to hamper ado= ption of either? For the people who deeply invested in OAuth 1 and didn=E2=80=99t = need or want the OAuth 2 newness, they stuck with it (see: twitter).=20 Was OpenID Connect a major disservice to OpenID 2? It was a disruption, for= sure, but people transitioned where it made sense for them, and in many cas= es that took years of dual-deployment and transition.=20 I see us walking along the same kind of path here, nearly a decade later. T= hat=E2=80=99s why I think OAuth 3 makes sense as a name for the output of this wor= k. Or at the very least, for the core delegation protocol portion of whateve= r we make. I think it sends the right message to implementers and developers= : the community that knows and understands OAuth 2 is working on the next ve= rsion of that thing, so when it=E2=80=99s ready, maybe you should look at it. Unti= l it=E2=80=99s done, and for a long time after, OAuth 2 is still going to be there= and be the right answer.=20 The name isn=E2=80=99t a hill I=E2=80=99m committed to dying alone on, but I think it s= ends a :bad: message if we call it something new entirely. Namely, that we t= hink people :should: abandon the entire world of OAuth, all of its ideas and= implementations. That=E2=80=99s not what we=E2=80=99re doing with this design, it=E2=80=99s a= n evolution as I see things. And as an evolution, a new major revision numbe= r makes sense. =E2=80=94 Justin On Dec 24, 2019, at 9:54 AM, Brian Campbell wr= ote: Naming any prospective resulting work here "OAuth 3.0" would significantly = exacerbate confusion in the whole space and would be a major disservice to t= he broader community.=20 On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki wrote: I definitely am not trying to discuss specifics of *how* authentication sho= uld be included right now, but I just want to make sure it's included in the= charter so that we can actually talk about it and it won't be "out of scope= " when we eventually do talk about the specifics. Aaron On Mon, Dec 23, 2019 at 1:51 PM Justin Richer wrote: I=E2=80=99m fine with it being in charter but I do think it should be a clearly s= eparate layer, much like OIDC/Facebook Connect/GitHub Login/etc are with OAu= th today. In all of these the authorization is first, and I think that=E2=80=99s t= he right pattern. So if we do take it on we=E2=80=99ll just need to be careful how= it=E2=80=99s structured in with everything else. Otherwise, I think the authentic= ation side can quickly overwhelm and drag down the authorization side. Good news: A lot of the additional stuff in OIDC is there to patch holes in= core OAuth in a common fashion, and we=E2=80=99ll at least be in a position to no= t have to do that again.=20 =E2=80=94 Justin On Dec 22, 2019, at 10:46 PM, Aaron Parecki wrote: I do think authentication should be part of the charter from the outset. Fr= ankly the fact that authentication is intentionally left out of OAuth and ha= s to be bolted on to the side via OpenID Connect is one of the exact reasons= people get confused about the whole space to begin with.=20 It's a relatively minor addition to the existing proposed spec to make it u= seful as a minimum viable authentication solution, and I'd like to see that = be addressed at the beginning of this work. I think we can do this in a smart way and that authentication should be inc= luded in the charter. Aaron On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer wrote= : Hi Justin, =20 I think the charter should mention target use cases. For example, =E2=80=9Call us= e cases supported by OAuth 2 will be supported by the new protocol=E2=80=9D or =E2=80=9C= the protocol will support at least use cases X and Y=E2=80=9D. =20 And given the importance of OIDC, we could say something like: =E2=80=9CThe proto= col will allow future extension to support authentication, in an analogous w= ay to OpenID Connect. However authentication is explicitly not part of the i= nitial scope.=E2=80=9D =20 Thanks, Yaron =20 From: Txauth on behalf of Justin Richer Date: Saturday, December 21, 2019 at 00:34 To: Cc: "rdd@cert.org" , Benjamin Kaduk Subject: [Txauth] TxAuth Proposed Charter =20 Hi all, =20 As discussed in Singapore, no matter what forum TxAuth takes, its work will= require a new charter. With that in mind, I=E2=80=99ve taken a bit of time to put= together a proposed charter text for the TxAuth work: =20 This group is chartered to develop a next-generation transactional authoriz= ation and delegation protocol for HTTP-based APIs and their clients. These t= ransactions will allow an authorizing party to delegate a right of access fo= r an API or set of APIs through an authorization server to a software client= acting on behalf of an authorizing party.=20 =20 The group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can provide= delegated access, how an authorized party can authorize delegated access, a= nd how that authorized access can be communicated to the resources being pro= tected. These actions will be connected through an explicit transaction betw= een the client and authorization server, resulting in an artifact that will = allow the client to undertake the delegated action.=20 =20 Additionally, the delegation process will allow for: - Fine-grained specification of resource access - Delegation between multiple users - Web, mobile, single-page, and other client applications =20 The group will define extension points for this protocol to allow for flexi= bility in areas including: =20 - Cryptographic agility for keys, message signatures, and proof of possessi= on=20 - User interaction mechanisms including web and non-web methods - Token presentation mechanisms and key bindings =20 The artifacts for this work are not intended or expected to be backwards-co= mpatible with OAuth 2.0 and its extensions.=20 =20 While this work could be done in within the OAuth working group, I now beli= eve that it should be done in a new working group, and that we should try to= get that working group up and running prior to the Vancouver meeting in Mar= ch. I think this group should stay here on the TxAuth list, and it=E2=80=99s my su= ggestion that the resulting work be called OAuth 3.0.=20 =20 Why a new group? I think that the OAuth working group should remain focused= on extending, patching, and adapting OAuth 2.0 to a changing world. I plan = to be engaged in both groups, and I know most of you are as well, but that=E2=80= =99s not universal. Since OAuth 2.0 is so established already, there are a LOT= of people who aren=E2=80=99t going to be interested in something new any time soo= n. But on the other hand, there are a number of people for whom OAuth 2.0 do= es not work, or is at the very least a poor fit, and we=E2=80=99ll want to bring t= hem in at this early stage. So even with significant overlap, I think there=E2= =80=99s enough disconnect in the community from both sides that warrants a new g= roup. In addition, I think this is a big enough piece of work that it=E2=80=99s si= mply too much for the OAuth working group to be able to focus on. We wouldn=E2= =80=99t be able to get additional meeting time, and OAuth already has trouble fi= tting into its two meeting slots as it is. =20 I=E2=80=99ve published a blog post detailing more of my rationale: =20 https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? =20 Please suggest changes to the proposed charter text above. It=E2=80=99s my hope t= hat we can get the chartering process started. =20 =E2=80=94 Justin -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth --=20 ---- Aaron Parecki aaronparecki.com @aaronpk --=20 ---- Aaron Parecki aaronparecki.com @aaronpk --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth CONFIDENTIALITY NOTICE: This email may contain confidential and privileged = material for the sole use of the intended recipient(s). Any review, use, dis= tribution or disclosure by others is strictly prohibited. If you have recei= ved this communication in error, please notify the sender immediately by e-m= ail and delete the message and any file attachments from your computer. Than= k you. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged = material for the sole use of the intended recipient(s). Any review, use, dis= tribution or disclosure by others is strictly prohibited. If you have recei= ved this communication in error, please notify the sender immediately by e-m= ail and delete the message and any file attachments from your computer. Than= k you. --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth From nobody Fri Dec 27 09:48:40 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EE8120B49 for ; Fri, 27 Dec 2019 09:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 58qXjG3Sf8Ox for ; Fri, 27 Dec 2019 09:48:36 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 C965312010C for ; Fri, 27 Dec 2019 09:48:35 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBRHmKKZ003937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Dec 2019 12:48:21 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: <3191A5CA-4D42-44ED-BB49-8335E18C3CDD@hardjono.net> Date: Fri, 27 Dec 2019 12:48:20 -0500 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <543EBD14-5629-48CA-8FE8-417678DADD97@hardjono.net> <5CC36DBF-4DA0-47FD-952B-2A41FF8342BA@hardjono.net> <887A5D73-9C0D-4BAE-981D-CDB3560E7BB9@mit.edu> <3191A5CA-4D42-44ED-BB49-8335E18C3CDD@hardjono.net> To: Thomas Hardjono X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 17:48:39 -0000 We have an identifier field in the RAR draft right now, and I think it = makes sense to have the two structures parallel to each other as much as = we can. I=E2=80=99m not sure they can be exactly parallel though. But please, for the love of everything, no OIDs. =E2=80=94 Justin > On Dec 27, 2019, at 11:29 AM, Thomas Hardjono = wrote: >=20 > Justin, >=20 >>>> So I=E2=80=99d like to put inter-domain security policies out of = scope for this work. Thoughts? >=20 > Of course. I'm not proposing that TXauth create a new = policy-expression syntax. These already exist (e.g. SAML, XACML). What I = was suggesting that the authorization_details (in the PSD2 example from = Torsten) needs to have standardized identification (akin to policy-oids) = so that both the AS and RS are referring to the same syntax. This is = pretty easy, I think. >=20 > Re-reading your medium blog and your IETF slides, I get the impression = that you are (we are) skirting around the problem or role-based access = control (RBAC). So why not just express XYZ in those terms while using = the OAuth2.0 nomenclature.=20 >=20 > If we can define "roles" attached to "permissions" (permission being = expressed as scopes), then we can solve much of the ambiguities in = OAuth2.0 (which UMA tried to solve to some extent (e.g. the = Alice-to-Alice case)). >=20 > Example: Alice-as-RO-role is giving Alice-as-Requestor-role access to = files at the RS at this location. Alice-as-Requestor-role can indicate = intent (as in the XYZ proposal). >=20 > Another example: Alice-as-RO-role gives Client-Operator permission = (consent) to interact with the AS and RS on Alice's behalf. >=20 >=20 > -- thomas -- >=20 >=20 > =EF=BB=BF-----Original Message----- > From: Justin Richer > Date: Thursday, December 26, 2019 at 5:54 PM > To: Thomas Hardjono > Cc: > Subject: Re: [Txauth] TxAuth Proposed Charter >=20 > What goes into what draft is, I believe, still largely up for = discussion and decision by a WG. The charter doesn=E2=80=99t need to = decide that ahead of time. What the charter can do though is decide = what=E2=80=99s in and out of scope overall. >=20 > That said, I think the core will need to define something like XYZ=E2=80= =99s =E2=80=9Cresources=E2=80=9D structure and how it relates to the = rest of the request. It=E2=80=99s possible that defining the details of = what goes in that structure lives elsewhere, but given how it=E2=80=99s = written in XYZ today I don=E2=80=99t think that is a necessary = abstraction layer. It=E2=80=99s a separate draft in OAuth just because = we didn=E2=80=99t have it in OAuth 2 to begin with, and look at the mess = that=E2=80=99s causing with the aud, resource, scope, and other = parameters. >=20 > I think the problem of sharing security policies across security = domains is probably too much for this working group. Just look at = everything that=E2=80=99s happened with XACML and its descendants =E2=80=94= it=E2=80=99s a very, very difficult problem space, with confusing = solutions where any exist at all. That said, I don=E2=80=99t see any = reason the parts that we define, like the resources block, couldn=E2=80=99= t be used as part of a separate cross-domain protocol. That=E2=80=99s = one of the benefits of separating the concerns of the request like this = =E2=80=94 but without the over-engineering and over-abstraction of = something like WS-*.=20 >=20 > So I=E2=80=99d like to put inter-domain security policies out of scope = for this work. Thoughts? >=20 > =E2=80=94 Justin >=20 >> On Dec 26, 2019, at 11:45 AM, Thomas Hardjono = wrote: >>=20 >> Correction: TXauth core protocol (not TXT core protocol, as TXT is = Trusted Execution, and also the name of a K-Pop band). >>=20 >>=20 >> =EF=BB=BF-----Original Message----- >> From: Thomas Hardjono >> Date: Thursday, December 26, 2019 at 11:42 AM >> To: Justin Richer , >> Subject: Re: [Txauth] TxAuth Proposed Charter >>=20 >>=20 >> I know the proposed charter is still a drafty draft, but I have a = couple of high-level questions. >>=20 >> (i) Will there be a separate specification for the TXT core protocol = and for the "authorization_details" (Torsten's draft). Is this what the = proposaed Charter refers to as "Fine-grained specification of resource = access". >>=20 >> (ii) Will there be an AS-to-AS mechanism to deliver authorization = information (either in the "authorization_details" format or otherwise). = This is relevant for authorization federation (for ASes in different = domains) and for addressing some of the issues that Annabelle presented = at IETF106 (i.e. context sharing). >>=20 >>=20 >> -- thomas -- >>=20 >>=20 >>=20 >> =EF=BB=BF-----Original Message----- >> From: Txauth on behalf of Justin Richer = >> Date: Friday, December 20, 2019 at 5:34 PM >> To: >> Cc: "rdd@cert.org" , Benjamin Kaduk >> Subject: [Txauth] TxAuth Proposed Charter >>=20 >> Hi all, >> As discussed in Singapore, no matter what forum TxAuth takes, its = work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of time to put together a proposed charter text for the TxAuth work: >>=20 >>=20 >> This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 >>=20 >> The group will deliver a protocol specification detailing how a = client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>=20 >> Additionally, the delegation process will allow for: >> - Fine-grained specification of resource access >> - Delegation between multiple users >> - Web, mobile, single-page, and other client applications >>=20 >> The group will define extension points for this protocol to allow for = flexibility in areas including: >>=20 >> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >> - User interaction mechanisms including web and non-web methods >> - Token presentation mechanisms and key bindings >>=20 >> The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >>=20 >>=20 >>=20 >> While this work could be done in within the OAuth working group, I = now believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>=20 >> Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing = world. I plan to be engaged in both groups, and I know most of you are = as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>=20 >> I=E2=80=99ve published a blog post detailing more of my rationale: >>=20 >> = https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? >>=20 >> Please suggest changes to the proposed charter text above. It=E2=80=99s= my hope that we can get the chartering process started. >>=20 >> =E2=80=94 Justin >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >>=20 >>=20 >>=20 >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >=20 >=20 >=20 From nobody Fri Dec 27 10:01:56 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B6B120B4C for ; Fri, 27 Dec 2019 10:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 y-qL-Hauvk3D for ; Fri, 27 Dec 2019 10:01:52 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 33487120B52 for ; Fri, 27 Dec 2019 10:01:52 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id 9so21171380lfq.10 for ; Fri, 27 Dec 2019 10:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OJMMfSUJFEIvOaCem+c+4bjs/cf/+fIN13bjNVsjiRA=; b=GShMXeklmA5RkE7bwawG5E6NlnK9U2BJAX4mhXeLdd9IIcoCgZM9WpTjm+dDlx2Kqh vkw1GamJ741h/1Ey11TqfP98bYfVKQ2TOz6PjS1xQOcBe6FqMN8xWBj8nQBhfFemD+R2 ouz6fXVvj0IHMEyzhrwXhEGxNHmAPqjx6ngeijvvyOeJe59Ff9V6pO2s9DTCg178caI3 sOWxHmGnVMf/CwxdY825pseSidzg9D9h055n9JZy88L5jX9rTdpe6jcMh5gjyj6HDmeq 9HZ6KCHJf2dG9YeLtzsHrFMx7Jk0U3xReDOnZRrZOPu9z4Ybzy0FsLG5Ym247VDwpgRz l4vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OJMMfSUJFEIvOaCem+c+4bjs/cf/+fIN13bjNVsjiRA=; b=qffPHSima3g9moV2d/xV3OB/nNwl0Bcuva/oSPLblT/79Mq8bh3KS37mypWK6d6Jqg BWCtLedjMTsOgA8EVWWopTELLmOCviHQTyiGc45kWUfyRP5uOuGW06tlVTaEsZYFfd4n MJSMyM1ritGPXKflCi2Sbcx3ruowDeh6AXVFVS4kL5LRyGPig5oocjSuvDn579g9EUrZ evmdknOkInRXkxuUYEhHhxlhcLnrWq8+qJ2ynWeQT+IIER2fs0ZeqwQog0U0YWINr5x3 V2SCrXXs4AlXdrLbnnXu3VSOLyuVbZ0TAu6ngbKUO0Acv5v4Yj0UHk9Ao5JQB7jD4UTC TWFQ== X-Gm-Message-State: APjAAAXk60Am5DUuATXxnYVZT0ksxUo8STyrmwA9VNlk6CH69DFYeg+d 3dZoe0TygMj7hniG617W2YlnNn1OKKqPLOTNLQG0v53L X-Google-Smtp-Source: APXvYqzmzTNlww+qM3LYXSE7YsV9QUHyM3lBjc5/+veqluy6eH+7tuSoVmJyUV/lUbHUPiCPNltapXFziivozL3xuxs= X-Received: by 2002:ac2:4c98:: with SMTP id d24mr29737159lfl.138.1577469710335; Fri, 27 Dec 2019 10:01:50 -0800 (PST) MIME-Version: 1.0 References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> In-Reply-To: <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> From: Dick Hardt Date: Fri, 27 Dec 2019 10:01:26 -0800 Message-ID: To: Justin Richer Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ba8732059ab349bd" Archived-At: Subject: [Txauth] RS initiated Tx (was: TxAuth Proposed Charter) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 18:01:54 -0000 --000000000000ba8732059ab349bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (changed topic as it is about Justin's proposal on having RS initiate Txx On Sat, Dec 21, 2019 at 4:41 AM Justin Richer wrote: > Even if the client starts at the RS, the client still has to go talk to > the AS. I haven=E2=80=99t built this out, but I see it working somewhat l= ike UMA. > In XYZ=E2=80=99s terms: > > > 1. Client calls the RS trying to Do A Thing > 2. RS calls the AS requesting a Resource Handle (because that=E2=80=99s w= hat the > RS represents, resources) =E2=80=94 at least good enough to cover what th= e client > tried to do, could be more > 3. RS gives the Resource Handle and AS Transaction Endpoint back to the > client > 4. Client calls the AS Transaction Endpoint to start a transaction, > includes the Resource Handle as part of its request (note: doesn=E2=80=99= t have to > be the whole resource section, client can add stuff) > 5. Process continues as normal > Why do you want the RS to request from the AS? This would require the RS to have credentials known to the AS. Why not have the RS provide information about what the Client needs to ask the AS for, and which AS it is? /Dick --000000000000ba8732059ab349bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(changed topic as it is about Justin's proposal o= n having RS initiate Txx

On Sat, Dec 21, 2019 at 4:41 AM Justin Richer <<= a href=3D"mailto:jricher@mit.edu">jricher@mit.edu> wrote:
<snip>
Even if the client starts at the RS, the client still has to go talk to = the AS. I haven=E2=80=99t built this out, but I see it working somewhat lik= e UMA. In XYZ=E2=80=99s terms:


1. C= lient calls the RS trying to Do A Thing
2. RS calls the AS reques= ting a Resource Handle (because that=E2=80=99s what the RS represents, reso= urces) =E2=80=94 at least good enough to cover what the client tried to do,= could be more
3. RS gives the Resource Handle and AS Transaction= Endpoint back to the client
4. Client calls the AS Transaction E= ndpoint to start a transaction, includes the Resource Handle as part of its= request (note: doesn=E2=80=99t have to be the whole resource section, clie= nt can add stuff)
5. Process continues as normal

Why do you want the RS to request from th= e AS? This would require the RS to have credentials known to the AS.
<= div>
Why not have the RS provide information about what the C= lient needs to ask the AS for, and which AS it is?

/Dick
--000000000000ba8732059ab349bd-- From nobody Fri Dec 27 10:11:51 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E1C120832 for ; Fri, 27 Dec 2019 10:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 Sx6jhXfDxEDl for ; Fri, 27 Dec 2019 10:11:46 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 57C1D12013B for ; Fri, 27 Dec 2019 10:11:44 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id u1so27712914ljk.7 for ; Fri, 27 Dec 2019 10:11:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hsu3Q75UmwdURUPW4lrOGENT07vSCPzVZtvGaMgb7bQ=; b=nBgJhVGi5Aobylc7WQSxbCTrYxyHxSrplGfAV55D/IaNgR1KINyGL4ldRDU3k6dwSK XRJbMKresSGpX/EcOsQZN3+mfykAa1MApAWdcLTugWe5ycR7RLKVuVdCVfXXdLIjsrVM nYrSCrdhjSSGolVCxDjSlStkFTnuRwVSzSKYYgV5DD+wZwKemXD+y92i+9td2yr8SAzs BEoinOnb/KC4RatqG+U4igr3Kt7AGz2Y7uzckWuGMYh6EO9lEdouY9a8sG2DzQ8FvLjT pr1CDbOPTnEMeli37T+gdUVHC7zGopOEShlV4d2XqsTmqs8kbcklWNNvKhyICpGf1cNk PChg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hsu3Q75UmwdURUPW4lrOGENT07vSCPzVZtvGaMgb7bQ=; b=hBoj3SueFoT32phMrsUZBmWtJzDznl2tLkpRDHdRrjxrUR0x3eYP7AvuZ9DXbbq3bt BiB3sDG72F9bUZbbGYSFA3Rliq/7YlS6jekvwjFtpJPtWZTcotavhkOpQI9PcgFArTOp GOw4M/eGBPzw3uH6q8LyWSGba0ZijDr61KkJ/ZSSY2Kc7OsXfgPHhMaCBT5ZMZBbFUnE E9CplqlLaY1Vnqx9v5v0vjSa9hYNY+w4mWycCxYQL5syQuqGKR1vzxrM9Y3WSnb+eaJT rj05crfAF1D+pVwiK9/5RpuE3c/cIHPpCXlN24+jzFKbInIgFdIeBLEm7oS/8xF2ir0n RxqA== X-Gm-Message-State: APjAAAUZ1IIUSesWTFqPwdhB0QFARvaOPUFBLDcm5zbUAt/1ygMNkGxo CgQT5koYfJydIzO4eHGYrEUed5JqIyIwlIBCSQo= X-Google-Smtp-Source: APXvYqzOPuBFVhrtUhFduhHLE9BRpDZC4fXDqWel8G/4u6tSwnqMz3Rz3IiCe9UsJoK9CfLj2Des+AtZaUPX8eX/C4M= X-Received: by 2002:a2e:9e03:: with SMTP id e3mr29490718ljk.186.1577470302134; Fri, 27 Dec 2019 10:11:42 -0800 (PST) MIME-Version: 1.0 References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <07AEE8DB-A0EE-4780-9CE7-B578F69948F9@mit.edu> In-Reply-To: <07AEE8DB-A0EE-4780-9CE7-B578F69948F9@mit.edu> From: Dick Hardt Date: Fri, 27 Dec 2019 10:11:18 -0800 Message-ID: To: Justin Richer Cc: Eve Maler , "rdd@cert.org" , txauth@ietf.org, Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000000a96c059ab36daf" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 18:11:49 -0000 --00000000000000a96c059ab36daf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 21, 2019 at 4:47 AM Justin Richer wrote: > On Dec 20, 2019, at 7:13 PM, Dick Hardt wrote: > > > Eve: do you not think the software client is acting on behalf of some > party? Or do you think that software always is acting on behalf of some > party, and the mentioned phrase is redundant? > > > I think what Eve=E2=80=99s saying is that the authorizing party might not= be > interacting with the client. That=E2=80=99s where things get fuzzy =E2=80= =94 if the > authorizing party authorizes the client but someone else is using it, the > authorizing party is really authorizing the requesting party that=E2=80= =99s using > the client, too. This is where UMA=E2=80=99s terminology can be a better = fit here. > Separating the RO and RqP roles could help, but how to express that in > succinct charter text. > Eve clarified that her point was why the extra clarification, not your thoughts. > > Justin: a couple questions > > 1. What is meant by "Delegation between multiple users=E2=80=9D ? > > > See above. > I still don't understand. Is one user delegating to another user? This is a desirable use case for many, but currently not standardized. Is this what you are proposing is in scope? > > > 2. Why do you restrict this to HTTP? > > > Because I want us to use all of the features and benefits of HTTP instead > of having to invent within-protocol functions to replicate them. I don=E2= =80=99t > want SOAP, which pretends to be transport agnostic much to its detriment. > If someone wants to do OAuth 3 on not-HTTP, they can define what that loo= ks > like. This is what happened with the COAP/CORE stuff and OAuth 2. > I agree SOAP was complicated. Which features and benefits of HTTP are you wanting to use? If it was simple to support COAP, why would we not do that? > > > 3. Why is authentication not in scope? > > > It felt, to me, like that might be a bridge too far. > I disagree. But I also think that authentication is the wrong term. Identity* may be a term that maps better, as the Client is wanting to get "identity" data from the AS. * The identity term is super confusing, but authentication implies just knowing it is the same user, where OpenID Connect also provides claims about the user. > If we do decide it=E2=80=99s in scope, then I think it should be clearly = layered > on top of the authorization layer. > Being layered on top is confusing. An OpenID Connect flow where the Client receives an ID token, has not authorization, unless you are counting the UX as authorization -- but that does not seem like a layer. Would you elaborate? > > > 4. When you say "not backwards compatible with OAuth 2.0 and its > extensions", do you expect to define a new standard to replace RFC 6750? > Developers will have to have a new method to call APIs? > > > Kinda. First, it=E2=80=99s more 6749 that I want to step away from. But e= ven then, > I think keeping just the header version of 6750 is OK enough if someone > wants to keep using that. The thing is, won=E2=80=99t someone seeing an O= Auth 2 > header assume the rest of OAuth 2 infrastructure? In some cases this won= =E2=80=99t > matter, but in many that could be really confusing. > > One of the problems, though, is that 6750 has already been clouded by > things like the MTLS binding, where they use =E2=80=9Cbearer=E2=80=9D tok= ens that have to > be bound to the client=E2=80=99s certificate. So =E2=80=A6 not much of a = bearer token > anymore. > So, are you are you proposing that Tx have a new mechanism for API calls? > > Ultimately, I don=E2=80=99t want anything that has an error-fallthrough > compatibility process. That is to say, I try doing OAuth 2, have that fai= l, > and then try it as OAuth 3 =E2=80=94 or vice versa. > Ok. I'm not even sure how that would happen, but ok. > > =E2=80=94 Justin > > > > On Fri, Dec 20, 2019 at 3:27 PM Eve Maler wrote: > >> Re =E2=80=9Cto a software client _acting on behalf of an authorizing par= ty_=E2=80=9D: >> There is a whole lot of philosophy behind whom the delegated access is >> performed on behalf of, unless the scenario is single-user or some "act = as" >> semantic is spelled out on the wire. Does it need to be stated here? Wha= t's >> the consequence if the highlighted phrase were removed? >> >> Eve Maler (sent from my iPad) | cell +1 425 345 6756 >> >> On Dec 20, 2019, at 4:34 PM, Justin Richer wrote: >> >> =EF=BB=BFHi all, >> >> As discussed in Singapore, no matter what forum TxAuth takes, its work >> will require a new charter. With that in mind, I=E2=80=99ve taken a bit = of time to >> put together a proposed charter text for the TxAuth work: >> >> This group is chartered to develop a next-generation transactional >> authorization and delegation protocol for HTTP-based APIs and their >> clients. These transactions will allow an authorizing party to delegate = a >> right of access for an API or set of APIs through an authorization serve= r >> to a software client acting on behalf of an authorizing party. >> >> The group will deliver a protocol specification detailing how a client >> can request and obtain delegated access, how an authorization server can >> provide delegated access, how an authorized party can authorize delegate= d >> access, and how that authorized access can be communicated to the resour= ces >> being protected. These actions will be connected through an explicit >> transaction between the client and authorization server, resulting in an >> artifact that will allow the client to undertake the delegated action. >> >> Additionally, the delegation process will allow for: >> - Fine-grained specification of resource access >> - Delegation between multiple users >> - Web, mobile, single-page, and other client applications >> >> The group will define extension points for this protocol to allow for >> flexibility in areas including: >> >> - Cryptographic agility for keys, message signatures, and proof of >> possession >> - User interaction mechanisms including web and non-web methods >> - Token presentation mechanisms and key bindings >> >> The artifacts for this work are not intended or expected to be >> backwards-compatible with OAuth 2.0 and its extensions. >> >> >> While this work could be done in within the OAuth working group, I now >> believe that it should be done in a new working group, and that we shoul= d >> try to get that working group up and running prior to the Vancouver meet= ing >> in March.. I think this group should stay here on the TxAuth list, and i= t=E2=80=99s >> my suggestion that the resulting work be called OAuth 3.0. >> >> Why a new group? I think that the OAuth working group should remain >> focused on extending, patching, and adapting OAuth 2.0 to a changing wor= ld. >> I plan to be engaged in both groups, and I know most of you are as well, >> but that=E2=80=99s not universal. Since OAuth 2.0 is so established alre= ady, there >> are a LOT of people who aren=E2=80=99t going to be interested in somethi= ng new any >> time soon. But on the other hand, there are a number of people for whom >> OAuth 2.0 does not work, or is at the very least a poor fit, and we=E2= =80=99ll want >> to bring them in at this early stage. So even with significant overlap, = I >> think there=E2=80=99s enough disconnect in the community from both sides= that >> warrants a new group. In addition, I think this is a big enough piece of >> work that it=E2=80=99s simply too much for the OAuth working group to be= able to >> focus on. We wouldn=E2=80=99t be able to get additional meeting time, an= d OAuth >> already has trouble fitting into its two meeting slots as it is. >> >> I=E2=80=99ve published a blog post detailing more of my rationale: >> >> >> https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-work= ing-group-d6229ba8e36? >> >> Please suggest changes to the proposed charter text above. It=E2=80=99s = my hope >> that we can get the chartering process started. >> >> =E2=80=94 Justin >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > --00000000000000a96c059ab36daf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Dec 21, 2019 at 4:47 AM Justi= n Richer <jricher@mit.edu> wro= te:
On Dec 20, 2019, at 7:13 PM, Dick Hardt <= ;dick.hardt@gmail= .com> wrote:

Eve: do you not think the software client is acting o= n behalf of some party? Or do you think that software always is acting on b= ehalf of some party, and the mentioned phrase is redundant?

<= /div>

I think what Eve=E2=80=99= s saying is that the authorizing party might not be interacting with the cl= ient. That=E2=80=99s where things get fuzzy =E2=80=94 if the authorizing pa= rty authorizes the client but someone else is using it, the authorizing par= ty is really authorizing the requesting party that=E2=80=99s using the clie= nt, too. This is where UMA=E2=80=99s terminology can be a better fit here. = Separating the RO and RqP roles could help, but how to express that in succ= inct charter text.

Eve cl= arified that her point was why the extra clarification, not your thoughts.<= /div>
=C2=A0

<= div>
Justin: a couple questions
=

1. What is meant by "Delegation between multiple u= sers=E2=80=9D ?

See= above.

I still don't= understand. Is one user delegating to another user? This is a desirable us= e case for many, but currently not standardized. Is this what you are propo= sing is in scope?
=C2=A0


2. Why do you restrict this to HTTP?
<= div>
Because I want us to use all of the features and benefit= s of HTTP instead of having to invent within-protocol functions to replicat= e them. I don=E2=80=99t want SOAP, which pretends to be transport agnostic = much to its detriment. If someone wants to do OAuth 3 on not-HTTP, they can= define what that looks like. This is what happened with the COAP/CORE stuf= f and OAuth 2.

I agree SO= AP was complicated. Which features and benefits of HTTP are you wanting to = use?=C2=A0

If it was simple to support COAP, why w= ould we not do that?
=C2=A0


<= div>3. Why is authentication not in scope?

It felt, to me, like that might be a bridge too far= .

I disagree. But I also= think that authentication is the wrong term. Identity* may be a term that = maps better, as the Client is wanting to get "identity" data from= the AS.=C2=A0

* The identity term is super confus= ing, but authentication implies just knowing it is the same user, where Ope= nID Connect also provides claims about the user.
=C2=A0
If we do decide it=E2=80=99s in scope, then I think = it should be clearly layered on top of the authorization layer.=C2=A0
=

Being layered on top is confus= ing. An OpenID Connect flow where the Client receives an ID token, has not = authorization, unless you are counting the UX as authorization -- but that = does not seem like a layer. Would you elaborate?
=C2=A0


4. When you say "not backwards compati= ble with OAuth 2.0 and its extensions", do you expect to define a new = standard to replace RFC 6750? Developers will have to have a new method to = call APIs?

Kinda. F= irst, it=E2=80=99s more 6749 that I want to step away from. But even then, = I think keeping just the header version of 6750 is OK enough if someone wan= ts to keep using that. The thing is, won=E2=80=99t someone seeing an OAuth = 2 header assume the rest of OAuth 2 infrastructure? In some cases this won= =E2=80=99t matter, but in many that could be really confusing.=C2=A0
<= div>
One of the problems, though, is that 6750 has already be= en clouded by things like the MTLS binding, where they use =E2=80=9Cbearer= =E2=80=9D tokens that have to be bound to the client=E2=80=99s certificate.= So =E2=80=A6 not much of a bearer token anymore.

So, are you are you proposing that Tx have a new m= echanism for API calls?
=C2=A0
Ultimately, I don=E2=80=99t want anything that has an error-fa= llthrough compatibility process. That is to say, I try doing OAuth 2, have = that fail, and then try it as OAuth 3 =E2=80=94 or vice versa.
<= /div>

Ok. I'm not even sure how that wo= uld happen, but ok.

=C2=A0
=

=C2=A0=E2=80=94 Justin


=

On Fri, Dec 20, 2019 at 3:27 PM Eve Maler <eve@xmlgrrl.com> wrote:
Re =E2=80=9C= to a software client _act= ing on behalf of an authorizing party_=E2=80=9D: There is a whole lot of ph= ilosophy behind whom the delegated access is performed on behalf of, unless= the scenario is single-user or some "act as" semantic is spelled= out on the wire. Does it need to be stated here? What's the consequenc= e if the highlighted phrase were removed?=C2=A0

Eve Maler (sent from my iPad) |=C2= =A0cell +1 425 345 6756
<= /div>

On Dec 20, 2019, at 4:3= 4 PM, Justin Richer <jricher@mit.edu> wrote:

=EF=BB=BFHi all,

As discussed= in Singapore, no matter what forum TxAuth takes, its work will require a n= ew charter. With that in mind, I=E2=80=99ve taken a bit of time to put toge= ther a proposed charter text for the TxAuth work:

This = group is chartered to develop a next-generation transactional authorization= and delegation protocol for HTTP-based APIs and their clients. These trans= actions will allow an authorizing party to delegate a right of access for a= n API or set of APIs through an authorization server to a software client a= cting on behalf of an authorizing party.=C2=A0

The= group will deliver a protocol specification detailing how a client can req= uest and obtain delegated access, how an authorization server can provide d= elegated access, how an authorized party can authorize delegated access, an= d how that authorized access can be communicated to the resources being pro= tected. These actions will be connected through an explicit transaction bet= ween the client and authorization server, resulting in an artifact that wil= l allow the client to undertake the delegated action.=C2=A0

<= /div>
Additionally, the delegation process will allow for:
- = Fine-grained specification of resource access
- Delegation betwee= n multiple users
- Web, mobile, single-page, and other client app= lications

The group will define extension points f= or this protocol to allow for flexibility in areas including:
- Cryptographic agility for keys, message signatures, and proof= of possession=C2=A0
- User interaction mechanisms including web = and non-web methods
- Token presentation mechanisms and key bindi= ngs

The artifacts for this work are not intended o= r expected to be backwards-compatible with OAuth 2.0 and its extensions.=C2= =A0

While this work could be done in = within the OAuth working group, I now believe that it should be done in a n= ew working group, and that we should try to get that working group up and r= unning prior to the Vancouver meeting in March.. I think this group should = stay here on the TxAuth list, and it=E2=80=99s my suggestion that the resul= ting work be called OAuth 3.0.=C2=A0

Why a new gro= up? I think that the OAuth working group should remain focused on extending= , patching, and adapting OAuth 2.0 to a changing world. I plan to be engage= d in both groups, and I know most of you are as well, but that=E2=80=99s no= t universal. Since OAuth 2.0 is so established already, there are a LOT of = people who aren=E2=80=99t going to be interested in something new any time = soon. But on the other hand, there are a number of people for whom OAuth 2.= 0 does not work, or is at the very least a poor fit, and we=E2=80=99ll want= to bring them in at this early stage. So even with significant overlap, I = think there=E2=80=99s enough disconnect in the community from both sides th= at warrants a new group. In addition, I think this is a big enough piece of= work that it=E2=80=99s simply too much for the OAuth working group to be a= ble to focus on. We wouldn=E2=80=99t be able to get additional meeting time= , and OAuth already has trouble fitting into its two meeting slots as it is= .

I=E2=80=99ve published a blog post detailing mor= e of my rationale:


Please = suggest changes to the proposed charter text above. It=E2=80=99s my hope th= at we can get the chartering process started.

=C2= =A0=E2=80=94 Justin
--
Txauth mailing list
Txauth@iet= f.org
https://www.ietf.org/mailman/listinfo/txauth<= /span>
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--00000000000000a96c059ab36daf-- From nobody Fri Dec 27 10:13:29 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CED120806 for ; Fri, 27 Dec 2019 10:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 u6WhMtIYfVoI for ; Fri, 27 Dec 2019 10:13:25 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 20C2A120832 for ; Fri, 27 Dec 2019 10:13:23 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id 9so21191820lfq.10 for ; Fri, 27 Dec 2019 10:13:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wZVkwA4yZKa0U4+z3ePN40zjmGdae794VuZhPy9CZn8=; b=TI1ObImkJWHHzyHKvsbHMNHpFHSFtFVTL09mBD8FGWeYmZGpBLt1JX4EAurYBSBytU U83gJswmNnazDfjVvuXoE6SnkLrr6VYx6OU9k2eUZpFcMW+N1d4Eg4QTDQc+J5Zenxx3 rE0cxHvO3N020w+fvSJFCsuNQ8DsDnNp38EKO5pl5PmVJlZLdXQHjsU+AohAX8mTBzjT pnQWpHyrC10vJeEjDOhmdqa+zJ3HoV+VSEUvTHaowRfO4wi+EyQt2aVzt6o+2pBLKJUj tsYcIf6NAEqK7+2y/G2aHzGpGFNlDaow/Zys/7YWXQ2n78IYz+jWmeCfJR+eDnYYqp1Z lG1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wZVkwA4yZKa0U4+z3ePN40zjmGdae794VuZhPy9CZn8=; b=qdARdt3+fkp5Rk3n+ofyV4H7FklXr22E+bUnMz+hn9VH9y0hH18JXL2LcR9ILyuSV0 3orPbfHxBc4y8gW9XB4btMztfRSkH8d+C6SLZsZ3hTnJUjF5W7UVCJYtfT6Hd5bXC6Zv g5yzfLKCwKYljYuaFg609hA5Y/H/lHd41GQOoxdTQHaolKfConcGSxakodbi4RXNBpVY KnX8C9N841iQTMZ6e1kg0Wd6WZVD4M7s7yIwLuU2IuVeTv/R1UzmX7b/R76jk9nefgU6 CXwUghhWgM0rHiBdRBU2MtZgfsP5ed8BtoLXNf9K7AHUjoWzqzMogpEKw4rz5m2ym5zc aFDA== X-Gm-Message-State: APjAAAUwWLDddZ33y496GdHb49J16Sq2GwC/ja3d/QjdebogBZsjO/QN 36DE/isWiQLOZ9Tv0Q3DeknQay1YRrVyjDkNI2M= X-Google-Smtp-Source: APXvYqwxobjlRlVxRyiWZUHjC0hzT2MPaL2FQcya6P134MYk3TJkkEsXjrFa6e9kPDAD1bRCpPcQhA7hGUUdqPYy14s= X-Received: by 2002:ac2:59dd:: with SMTP id x29mr28891508lfn.95.1577470401273; Fri, 27 Dec 2019 10:13:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Fri, 27 Dec 2019 10:12:57 -0800 Message-ID: To: Aaron Parecki Cc: Yaron Sheffer , "rdd@cert.org" , Benjamin Kaduk , Justin Richer , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000e966f8059ab3724c" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 18:13:28 -0000 --000000000000e966f8059ab3724c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for the reasons Aaron stated -- user confusion -- which is one of the motivations of this work -- simplifying the cognitive load for developers, and helping them get security right. As noted in a separate message, we may want to call this "identity" On Sun, Dec 22, 2019 at 7:46 PM Aaron Parecki wrote: > I do think authentication should be part of the charter from the outset. > Frankly the fact that authentication is intentionally left out of OAuth a= nd > has to be bolted on to the side via OpenID Connect is one of the exact > reasons people get confused about the whole space to begin with. > > It's a relatively minor addition to the existing proposed spec to make it > useful as a minimum viable authentication solution, and I'd like to see > that be addressed at the beginning of this work. > > I think we can do this in a smart way and that authentication should be > included in the charter. > > Aaron > > > > > On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer > wrote: > >> Hi Justin, >> >> >> >> I think the charter should mention target use cases. For example, =E2=80= =9Call >> use cases supported by OAuth 2 will be supported by the new protocol=E2= =80=9D or >> =E2=80=9Cthe protocol will support at least use cases X and Y=E2=80=9D. >> >> >> >> And given the importance of OIDC, we could say something like: =E2=80=9C= The >> protocol will allow future extension to support authentication, in an >> analogous way to OpenID Connect. However authentication is explicitly no= t >> part of the initial scope.=E2=80=9D >> >> >> >> Thanks, >> >> Yaron >> >> >> >> *From: *Txauth on behalf of Justin Richer < >> jricher@mit.edu> >> *Date: *Saturday, December 21, 2019 at 00:34 >> *To: * >> *Cc: *"rdd@cert.org " , Benjamin Kaduk < >> kaduk@mit.edu> >> *Subject: *[Txauth] TxAuth Proposed Charter >> >> >> >> Hi all, >> >> >> >> As discussed in Singapore, no matter what forum TxAuth takes, its work >> will require a new charter. With that in mind, I=E2=80=99ve taken a bit = of time to >> put together a proposed charter text for the TxAuth work: >> >> >> >> This group is chartered to develop a next-generation transactional >> authorization and delegation protocol for HTTP-based APIs and their >> clients. These transactions will allow an authorizing party to delegate = a >> right of access for an API or set of APIs through an authorization serve= r >> to a software client acting on behalf of an authorizing party. >> >> >> >> The group will deliver a protocol specification detailing how a client >> can request and obtain delegated access, how an authorization server can >> provide delegated access, how an authorized party can authorize delegate= d >> access, and how that authorized access can be communicated to the resour= ces >> being protected. These actions will be connected through an explicit >> transaction between the client and authorization server, resulting in an >> artifact that will allow the client to undertake the delegated action. >> >> >> >> Additionally, the delegation process will allow for: >> >> - Fine-grained specification of resource access >> >> - Delegation between multiple users >> >> - Web, mobile, single-page, and other client applications >> >> >> >> The group will define extension points for this protocol to allow for >> flexibility in areas including: >> >> >> >> - Cryptographic agility for keys, message signatures, and proof of >> possession >> >> - User interaction mechanisms including web and non-web methods >> >> - Token presentation mechanisms and key bindings >> >> >> >> The artifacts for this work are not intended or expected to be >> backwards-compatible with OAuth 2.0 and its extensions. >> >> >> >> While this work could be done in within the OAuth working group, I now >> believe that it should be done in a new working group, and that we shoul= d >> try to get that working group up and running prior to the Vancouver meet= ing >> in March. I think this group should stay here on the TxAuth list, and it= =E2=80=99s >> my suggestion that the resulting work be called OAuth 3.0. >> >> >> >> Why a new group? I think that the OAuth working group should remain >> focused on extending, patching, and adapting OAuth 2.0 to a changing wor= ld. >> I plan to be engaged in both groups, and I know most of you are as well, >> but that=E2=80=99s not universal. Since OAuth 2.0 is so established alre= ady, there >> are a LOT of people who aren=E2=80=99t going to be interested in somethi= ng new any >> time soon. But on the other hand, there are a number of people for whom >> OAuth 2.0 does not work, or is at the very least a poor fit, and we=E2= =80=99ll want >> to bring them in at this early stage. So even with significant overlap, = I >> think there=E2=80=99s enough disconnect in the community from both sides= that >> warrants a new group. In addition, I think this is a big enough piece of >> work that it=E2=80=99s simply too much for the OAuth working group to be= able to >> focus on. We wouldn=E2=80=99t be able to get additional meeting time, an= d OAuth >> already has trouble fitting into its two meeting slots as it is. >> >> >> >> I=E2=80=99ve published a blog post detailing more of my rationale: >> >> >> >> >> https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-work= ing-group-d6229ba8e36? >> >> >> >> Please suggest changes to the proposed charter text above. It=E2=80=99s = my hope >> that we can get the chartering process started. >> >> >> >> =E2=80=94 Justin >> >> -- Txauth mailing list Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000e966f8059ab3724c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for the reasons Aaron stated -- user confusion=C2=A0-- = which is one of the motivations of this work -- simplifying the cognitive l= oad for developers, and helping them get security right.

=
As noted in a separate message, we may want to call this "identit= y"


On Sun, Dec 22, 2019 at 7:46 PM Aaron Parecki= <aaron@parecki.com> wrote:<= br>
I do think authentication should be part of the charter from the out= set. Frankly the fact that authentication is intentionally left out of OAut= h and has to be bolted on to the side via OpenID Connect is one of the exac= t reasons people get confused about the whole space to begin with.=C2=A0

It's a relativel= y minor addition to the existing proposed spec to make it useful as a minim= um viable authentication solution, and I'd like to see that be addresse= d at the beginning of this work.

I think we can do this in a smart way and that authentication sho= uld be included in the charter.

Aaron




On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer= <yaronf.ietf= @gmail..com> wrote:

Hi Justin,

=C2=A0

I think the charter should mention target use cases. For example, = =E2=80=9Call use cases supported by OAuth 2 will be supported by the new pr= otocol=E2=80=9D or =E2=80=9Cthe protocol will support at least use cases X = and Y=E2=80=9D.

=C2=A0

And given the importance of OIDC, we could say = something like: =E2=80=9CThe protocol will allow future extension to suppor= t authentication, in an analogous way to OpenID Connect. However authentica= tion is explicitly not part of the initial scope.=E2=80=9D

=C2=A0

Than= ks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

From: Txauth <txauth-bounces@ietf.org&g= t; on behalf of Justin Richer <jricher@mit.edu>
Date: Saturday, December 21, = 2019 at 00:34
To: <txauth@ietf.org>
Cc: "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <= kaduk@mit.edu>Subject: [Txauth] TxAuth Proposed Charter

<= /div>

=C2=A0

Hi all,

=C2= =A0

As discussed in Singapore, = no matter what forum TxAuth takes, its work will require a new charter. Wit= h that in mind, I=E2=80=99ve taken a bit of time to put together a proposed= charter text for the TxAuth work:

=C2=A0

This group is chartered t= o develop a next-generation transactional authorization and delegation prot= ocol for HTTP-based APIs and their clients. These transactions will allow a= n authorizing party to delegate a right of access for an API or set of APIs= through an authorization server to a software client acting on behalf of a= n authorizing party.=C2=A0

=C2=A0

The group will= deliver a protocol specification detailing how a client can request and ob= tain delegated access, how an authorization server can provide delegated ac= cess, how an authorized party can authorize delegated access, and how that = authorized access can be communicated to the resources being protected. The= se actions will be connected through an explicit transaction between the cl= ient and authorization server, resulting in an artifact that will allow the= client to undertake the delegated action.=C2=A0

=C2=A0

Additionally, the delegation process will allow for:<= /p>

- Fine-grained specification of resour= ce access

- Delegation b= etween multiple users

- = Web, mobile, single-page, and other client applications

=C2=A0

The group will define extension points for this protocol to = allow for flexibility in areas including:

=C2=A0

- Cryptographic agility for keys, message signatures, and proof of possess= ion=C2=A0

- User interac= tion mechanisms including web and non-web methods

- Token presentation mechanisms and key bindings<= u>

=C2=A0

=

The artifacts for this work are not inten= ded or expected to be backwards-compatible with OAuth 2.0 and its extension= s.=C2=A0

=C2=A0

While this work cou= ld be done in within the OAuth working group, I now believe that it should = be done in a new working group, and that we should try to get that working = group up and running prior to the Vancouver meeting in March. I think this = group should stay here on the TxAuth list, and it=E2=80=99s my suggestion t= hat the resulting work be called OAuth 3.0.=C2=A0

=C2=A0

Why a new group? I think that the OAuth working group should remai= n focused on extending, patching, and adapting OAuth 2.0 to a changing worl= d. I plan to be engaged in both groups, and I know most of you are as well,= but that=E2=80=99s not universal. Since OAuth 2.0 is so established alread= y, there are a LOT of people who aren=E2=80=99t going to be interested in s= omething new any time soon. But on the other hand, there are a number of pe= ople for whom OAuth 2.0 does not work, or is at the very least a poor fit, = and we=E2=80=99ll want to bring them in at this early stage. So even with s= ignificant overlap, I think there=E2=80=99s enough disconnect in the commun= ity from both sides that warrants a new group. In addition, I think this is= a big enough piece of work that it=E2=80=99s simply too much for the OAuth= working group to be able to focus on. We wouldn=E2=80=99t be able to get a= dditional meeting time, and OAuth already has trouble fitting into its two = meeting slots as it is.

= =C2=A0

I=E2=80=99ve publ= ished a blog post detailing more of my rationale:

=C2=A0

=C2=A0=

Please suggest changes to the pro= posed charter text above. It=E2=80=99s my hope that we can get the charteri= ng process started.

<= /u>=C2=A0

=C2=A0=E2=80=94 Justi= n

-- Txauth mailing list Txauth@ietf.org https:= //www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
----
Aaron = Parecki

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000e966f8059ab3724c-- From nobody Fri Dec 27 10:17:11 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A434D120018 for ; Fri, 27 Dec 2019 10:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 ADwBc36ar3sF for ; Fri, 27 Dec 2019 10:17:06 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 CEAA212013B for ; Fri, 27 Dec 2019 10:17:05 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id a13so27729953ljm.10 for ; Fri, 27 Dec 2019 10:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R4UaTniZYlBP0/HgEp2PlTpC/yFQEMv8PlKZyOzTcU0=; b=mGeWHoXLD1bLAK7fmNoZ48p9CQzoPNWtukUAAH9rWaGlfa/CTZr3/oubxvui7oNCrz 78XOfthS5FAFrCfGzhgYlFPNoinnweVtPP8nDTD3OFLWMVZ58xAQIlcjf9BqtOZAyop+ 0ZWrWk+d03vLdyS72rSEA2oXyKGUqldEYdt3UhaYfu/AXvpCl0E/gsAQ9sExDerLl53D Te+krn0v/9t+NpK/5KqoVGyn0TY16HqwAFTc5G7ibFAGEbjXpt6a8pOID0ieKv4rJzNQ 4YgpV1k9W0+Ke0boAuGQeMxbyMa4xUY9NuFfP3KXC3gzKBQsaS34EslEZKfUJmQV9QIB orRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R4UaTniZYlBP0/HgEp2PlTpC/yFQEMv8PlKZyOzTcU0=; b=WDBxm073C6R2gIR/Nst2oZj6fQz1Y0cA0FrBpTxES5Ta4nHn/rG0waSwZVPfdLNukw Lr24azQtdkC5lTr68jeUli3inqunsCUWUHkDt3hxi2Es0cCJYDVWVamAZ0OO1h/s3MnZ qb6pypuWqZB6ShWGuT0Jzo3Ha6kuxQJX+X3FfDmG6X3CYo+MQftOuLtKvzF23Ta+PLk2 6j/QzeOgW4GLbUW3ac//GbO3C4T/P4eibxbN7ik06aZHHUt+4NBJ9cI/EtkwLT/ypj4M IDeXhPazaAe7sLJ8BsQ5c3wvrik/1CrGvg5Nx05fyOJ4o/yHKwVPc2wKsEPUCf3r+eyk a2zQ== X-Gm-Message-State: APjAAAUOk+UjYK88nKfJZx2koV95ivQ6CyQnVMW2CwJqnPusmke8CFAv c1SCk479xG61haIa9kdpWteuoGNGoZGzM7ydUqY= X-Google-Smtp-Source: APXvYqxIO7IDg7isE9kxk3+yieP9v3Qm6m9tBMlPdPm0ShL/J0DPRojfUP80A87LeEgoNn8Vka5LXvqgYW+iWA6Bu3w= X-Received: by 2002:a05:651c:204f:: with SMTP id t15mr30050159ljo.240.1577470623889; Fri, 27 Dec 2019 10:17:03 -0800 (PST) MIME-Version: 1.0 References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> <949341AE-C72B-4645-8F20-699F14529FFB@mit.edu> <78FA3EB7-C72F-4543-95A8-03123F4E40A1@amazon.com> In-Reply-To: <78FA3EB7-C72F-4543-95A8-03123F4E40A1@amazon.com> From: Dick Hardt Date: Fri, 27 Dec 2019 10:16:40 -0800 Message-ID: To: "Richard Backman, Annabelle" Cc: Justin Richer , Eve Maler , "rdd@cert.org" , "txauth@ietf.org" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="0000000000002e3dba059ab380fc" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 18:17:10 -0000 --0000000000002e3dba059ab380fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I concur with Annabelle. Pretty much all large systems have a clear separation between different functions to provide resiliency and improved security (separation of duties) Ideally we can do this without adding complexity for deployments that don't require it. On Sun, Dec 22, 2019 at 8:52 PM Richard Backman, Annabelle < richanna@amazon.com> wrote: > My example demonstrates an architecture where the TX Endpoint, > authentication system, and token issuer aren=E2=80=99t simply different m= icro > services, they=E2=80=99re completely independent systems in different tru= st > boundaries, possibly have different domains and different keys. This has > implications for protocol design. For example, it would no longer be > sufficient to have a single jwks_uri, as OAuth 2.0 has. > > If we want to support this kind of =E2=80=9Cdecomposed AS=E2=80=9D model,= then we need to > make sure that=E2=80=99s supported by the charter and keep it in mind as = we design > the protocol. We can also decide it is out of scope, but we should be > intentional about that decision. > > To my mind, this role decomposition is the next logical step after the > channel decomposition that TxAuth already does. I see a lot of potential = in > it and think we should at minimum avoid closing the door on it. > > On Dec 22, 2019, at 5:35 PM, Justin Richer wrote: > > =EF=BB=BF I think you=E2=80=99re conflating the *roles* that different co= mponents play, > in regard to the other components, with the potential deployment of those > components. The spec needs to be written in terms of the roles. While the > roles do need to consider what potential deployments might be, it=E2=80= =99s > important that we write things in in terms of how they interact with each > other and not in terms of how they might look under the covers. > > So from the clients perspective, the TX Endpoint :is: the AS. The client > doesn=E2=80=99t care that it=E2=80=99s a =E2=80=9Cglorified message queue= =E2=80=9D or if it=E2=80=99s a massive > server farm. The client doesn=E2=80=99t care if there=E2=80=99s a TLS rev= erse proxy or if > it=E2=80=99s talking directly to the application layer. The only thing th= e client > cares about is if the TX Endpoint does the things that a TX Endpoint is > supposed to do, and we define that to be the function of the AS. > > What=E2=80=99s important in your scenario below is that the client would = have to > talk to the RS first every time. That=E2=80=99s one of the problems that = UMA has, > and I think something we should avoid. I think RS-first is an interesting > pattern but AS-first ought to drive this. > > With your hypothetical layout below, it really sounds like the TX Endpoin= t > is a function of the IDP, which is fine. The client doesn=E2=80=99t care = that it=E2=80=99s > deployed using some externalized cloud service. The only weird thing goin= g > on is the push from the AS back to the client. The client would need to > register that with the AS (or through the AS more specifically) as part o= f > its transaction request. This would be part of its interaction mechanism, > because =E2=80=9Chow you get messages and updates back to the client=E2= =80=9D is part of > the interaction model. > > So for an RS-first transaction, the client calls the RS: > > GET /foo > > The RS returns a resource handle, but the client doesn=E2=80=99t care whe= re that > came from. The RS could talk to the AS to get it. Probably a new endpoint > of some kind, can probably use the same kinds of key binding that the TX > Endpoint has. Or the RS can make one up that the TX Endpoint can recogniz= e. > Or it calls the IdP to get one. The client doesn=E2=80=99t care, and that= =E2=80=99s the key > point. > > WWW-Authenticate tx_endpoint=3D=E2=80=9Chttp://server//tx > =E2=80=9D resource: =E2=80=9Casdf1234=E2=80=9D > > The client calls the TX endpoint like a normal transaction: > > POST /tx > > { > resources: [ =E2=80=9Casdf1234=E2=80=9D ], > interact: { > redirect: true, > push: =E2=80=9Chttp://client/push/9876=E2=80=9D > } > } > > The AS (which is to say the TX Endpoint) tells the client to send the use= r > agent to the IdP > > { > interact_url: =E2=80=9Chttp://idp/login=E2=80=9D, > handle: { value: =E2=80=9Chjkl=E2=80=9D, type: bearer } > } > > Now the client could poll the TX Endpoint but it could also just sit and > wait for an update to be pushed in. > > There are probably things that need to be tied together for this to be > secure, but I think the basic pattern still fits. Importantly, the client > doesn=E2=80=99t care whereby of that stuff came from =E2=80=94 as far as = it=E2=80=99s concerned, > it=E2=80=99s talking to the AS. > > Remember, the =E2=80=9CAS=E2=80=9D is a logical construct, not a physical= one. Just like > the =E2=80=9Cclient=E2=80=9D could be a cluster of applications and the = =E2=80=9CRS=E2=80=9D could be a > suite of APIs tied behind a gateway. > > =E2=80=94 Justin > > > On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle < > richanna@amazon.com> wrote: > > > On Dec 21, 2019, at 4:42 AM, Justin Richer wrote: > > > Even if the client starts at the RS, the client still has to go talk to > the AS. I haven=E2=80=99t built this out, but I see it working somewhat l= ike UMA. > In XYZ=E2=80=99s terms: > > > 1. Client calls the RS trying to Do A Thing > 2. RS calls the AS requesting a Resource Handle (because that=E2=80=99s w= hat the > RS represents, resources) =E2=80=94 at least good enough to cover what th= e client > tried to do, could be more > 3. RS gives the Resource Handle and AS Transaction Endpoint back to the > client > 4. Client calls the AS Transaction Endpoint to start a transaction, > includes the Resource Handle as part of its request (note: doesn=E2=80=99= t have to > be the whole resource section, client can add stuff) > 5. Process continues as normal > > > It depends on what you consider the =E2=80=9CAS=E2=80=9D. Consider the fo= llowing > hypothetical architecture: > > =E2=80=A2 The RS, client, and tx endpoint are on the public Internet. > =E2=80=A2 The tx endpoint returns interaction urls that point to an IdP t= hat is > inaccessible from the public Internet. > =E2=80=A2 The user agent can reach the IdP, but none of the other systems= can. > =E2=80=A2 When the UA is redirected to the IdP, the IdP calls the tx endp= oint > system to retrieve transaction details. > =E2=80=A2 When authorization is granted, the IdP pushes artifacts directl= y to an > endpoint provided by the client. > > In this example, the client only interacts with the RS and the tx > endpoint. It seems odd to me to consider the system hosting the tx endpoi= nt > to be the AS (or at least part of the AS), as its a glorified message que= ue > with essentially no authority in this architecture. > > We could go a step further and remove the client=E2=80=99s interaction wi= th the tx > endpoint by having the RS return the interaction url directly (you=E2=80= =99d need > to secure the client nonce if you want to hide it from the RS, but that= =E2=80=99s > not that hard). > > Is the meaning of =E2=80=9Cauthorization server=E2=80=9D (or the phrase = =E2=80=9Cthrough an > authorization server=E2=80=9D) flexible enough to accommodate these cases= ? Or are > they considered out of scope for TxAuth? > > =E2=80=94 Justin > > > As I said, maybe I=E2=80=99m being too literal. > > =E1=90=A7 > On Fri, Dec 20, 2019 at 5:08 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >> I=E2=80=99m not sure if this is what Eve had in mind, but consider an au= tomated >> system in an enterprise context that has been authorized by an >> administrator. The automated system isn=E2=80=99t acting as or on behalf= of the >> administrator, and the administrator hasn=E2=80=99t =E2=80=9Cdelegated a= ccess=E2=80=9D; they=E2=80=99ve >> *granted* access, just as they do when they assign permissions to >> users/groups/roles/etc. >> >> Maybe I=E2=80=99m being too literal, but =E2=80=9Cthrough an authorizati= on server=E2=80=9D in >> paragraph 1 implies a specific context/information/request flow to me. >> Given that one of TxAuth=E2=80=99s features is decoupling the different >> communication channels, we should not suggest that the client or >> authorizing party is directly interacting with the AS. >> >> >> >> =E2=80=93 >> >> Annabelle Richard Backman >> >> AWS Identity >> >> >> >> >> >> *From: *Txauth on behalf of Dick Hardt < >> dick.hardt@gmail.com> >> *Date: *Friday, December 20, 2019 at 4:14 PM >> *To: *Eve Maler >> *Cc: *"rdd@cert.org" , "txauth@ietf.org" = , >> Justin Richer , Benjamin Kaduk >> *Subject: *Re: [Txauth] TxAuth Proposed Charter >> >> >> >> Eve: do you not think the software client is acting on behalf of some >> party? Or do you think that software always is acting on behalf of some >> party, and the mentioned phrase is redundant? >> >> >> >> Justin: a couple questions >> >> >> >> 1. What is meant by "Delegation between multiple users" ? >> >> >> >> 2. Why do you restrict this to HTTP? >> >> >> >> 3. Why is authentication not in scope? >> >> >> >> 4. When you say "not backwards compatible with OAuth 2.0 and its >> extensions", do you expect to define a new standard to replace RFC 6750? >> Developers will have to have a new method to call APIs? >> >> >> >> >> >> On Fri, Dec 20, 2019 at 3:27 PM Eve Maler wrote: >> >> Re =E2=80=9Cto a software client _acting on behalf of an authorizing par= ty_=E2=80=9D: >> There is a whole lot of philosophy behind whom the delegated access is >> performed on behalf of, unless the scenario is single-user or some "act = as" >> semantic is spelled out on the wire. Does it need to be stated here? Wha= t's >> the consequence if the highlighted phrase were removed? >> >> Eve Maler (sent from my iPad) | cell +1 425 345 6756 >> >> >> >> On Dec 20, 2019, at 4:34 PM, Justin Richer wrote: >> >> Hi all, >> >> >> >> As discussed in Singapore, no matter what forum TxAuth takes, its work >> will require a new charter. With that in mind, I=E2=80=99ve taken a bit = of time to >> put together a proposed charter text for the TxAuth work: >> >> >> >> This group is chartered to develop a next-generation transactional >> authorization and delegation protocol for HTTP-based APIs and their >> clients. These transactions will allow an authorizing party to delegate = a >> right of access for an API or set of APIs through an authorization serve= r >> to a software client acting on behalf of an authorizing party. >> >> >> >> The group will deliver a protocol specification detailing how a client >> can request and obtain delegated access, how an authorization server can >> provide delegated access, how an authorized party can authorize delegate= d >> access, and how that authorized access can be communicated to the resour= ces >> being protected. These actions will be connected through an explicit >> transaction between the client and authorization server, resulting in an >> artifact that will allow the client to undertake the delegated action. >> >> >> >> Additionally, the delegation process will allow for: >> >> - Fine-grained specification of resource access >> >> - Delegation between multiple users >> >> - Web, mobile, single-page, and other client applications >> >> >> >> The group will define extension points for this protocol to allow for >> flexibility in areas including: >> >> >> >> - Cryptographic agility for keys, message signatures, and proof of >> possession >> >> - User interaction mechanisms including web and non-web methods >> >> - Token presentation mechanisms and key bindings >> >> >> >> The artifacts for this work are not intended or expected to be >> backwards-compatible with OAuth 2.0 and its extensions. >> >> >> >> While this work could be done in within the OAuth working group, I now >> believe that it should be done in a new working group, and that we shoul= d >> try to get that working group up and running prior to the Vancouver meet= ing >> in March.. I think this group should stay here on the TxAuth list, and i= t=E2=80=99s >> my suggestion that the resulting work be called OAuth 3.0. >> >> >> >> Why a new group? I think that the OAuth working group should remain >> focused on extending, patching, and adapting OAuth 2.0 to a changing wor= ld. >> I plan to be engaged in both groups, and I know most of you are as well, >> but that=E2=80=99s not universal. Since OAuth 2.0 is so established alre= ady, there >> are a LOT of people who aren=E2=80=99t going to be interested in somethi= ng new any >> time soon. But on the other hand, there are a number of people for whom >> OAuth 2.0 does not work, or is at the very least a poor fit, and we=E2= =80=99ll want >> to bring them in at this early stage. So even with significant overlap, = I >> think there=E2=80=99s enough disconnect in the community from both sides= that >> warrants a new group. In addition, I think this is a big enough piece of >> work that it=E2=80=99s simply too much for the OAuth working group to be= able to >> focus on. We wouldn=E2=80=99t be able to get additional meeting time, an= d OAuth >> already has trouble fitting into its two meeting slots as it is. >> >> >> >> I=E2=80=99ve published a blog post detailing more of my rationale: >> >> >> >> >> https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-work= ing-group-d6229ba8e36? >> >> >> >> Please suggest changes to the proposed charter text above. It=E2=80=99s = my hope >> that we can get the chartering process started. >> >> >> >> =E2=80=94 Justin >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> > > --0000000000002e3dba059ab380fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I concur=C2=A0with Annabelle. Pretty much all large system= s have a clear separation between different functions to provide resiliency= and improved security (separation of duties)

Ideally we= can do this without adding complexity for deployments that don't requi= re it.


On Sun, Dec 22, 2019 at 8:52 PM Richard Backman,= Annabelle <richanna@amazon.com> wrote:
My example demonstrates an architecture wh= ere the TX Endpoint, authentication system, and token issuer aren=E2=80=99t= simply different micro services, they=E2=80=99re completely independent sy= stems in different trust boundaries, possibly have different domains and different keys. This= has implications for protocol design. For example, it would no longer be s= ufficient to have a single jwks_uri, as OAuth 2.0 has.

If we want to support this kind of =E2= =80=9Cdecomposed AS=E2=80=9D model, then we need to make sure that=E2=80=99= s supported by the charter and keep it in mind as we design the protocol. W= e can also decide it is out of scope, but we should be intentional about that decision.

To my mind, this role decomposition is the next logical st= ep after the channel decomposition that TxAuth already does. I see a lot of= potential in it and think we should at minimum avoid closing the door on i= t.
=EF=BB=BF I think you=E2=80=99re conflating the roles=C2=A0that different components play, in regard to the other components, = with the potential deployment of those components. The spec needs to be wri= tten in terms of the roles. While the roles do need to consider what potential deployments might be, it=E2=80=99s importa= nt that we write things in in terms of how they interact with each other an= d not in terms of how they might look under the covers.

So from the clients perspective, the TX Endpoint :is: the AS. The clie= nt doesn=E2=80=99t care that it=E2=80=99s a =E2=80=9Cglorified message queu= e=E2=80=9D or if it=E2=80=99s a massive server farm. The client doesn=E2=80= =99t care if there=E2=80=99s a TLS reverse proxy or if it=E2=80=99s talking= directly to the application layer. The only thing the client cares about is if the TX = Endpoint does the things that a TX Endpoint is supposed to do, and we defin= e that to be the function of the AS.=C2=A0

What=E2=80=99s important in your scenario below is that the client wou= ld have to talk to the RS first every time. That=E2=80=99s one of the probl= ems that UMA has, and I think something we should avoid. I think RS-first i= s an interesting pattern but AS-first ought to drive this.=C2=A0

With your hypothetical layout below, it really sounds like the TX Endp= oint is a function of the IDP, which is fine. The client doesn=E2=80=99t ca= re that it=E2=80=99s deployed using some externalized cloud service. The on= ly weird thing going on is the push from the AS back to the client. The client would need to register that with the= AS (or through the AS more specifically) as part of its transaction reques= t. This would be part of its interaction mechanism, because =E2=80=9Chow yo= u get messages and updates back to the client=E2=80=9D is part of the interaction model.=C2=A0

So for an RS-first transaction, the client calls the RS:

GET /foo

The RS returns a resource handle, but the client doesn=E2=80=99t care = where that came from. The RS could talk to the AS to get it. Probably a new= endpoint of some kind, can probably use the same kinds of key binding that= the TX Endpoint has. Or the RS can make one up that the TX Endpoint can recognize. Or it calls the IdP to= get one. The client doesn=E2=80=99t care, and that=E2=80=99s the key point= .=C2=A0

WWW-Authenticate tx_endpoint=3D=E2=80=9Chttp://server//tx=E2=80=9D resource: =E2=80= =9Casdf1234=E2=80=9D

The client calls the TX endpoint like a normal transaction:

POST /tx

{
=C2=A0 resources: [ =E2=80=9Casdf1234=E2=80=9D ],
=C2=A0 interact: {
=C2=A0 =C2=A0 redirect: true,
=C2=A0 =C2=A0 push: =E2=80=9Chttp://client/push/9876=E2=80=9D
=C2=A0 }
}

The AS (which is to say the TX Endpoint) tells the client to send the = user agent to the IdP

{
=C2=A0 interact_url: =E2=80=9Chttp://idp/login=E2=80=9D,
=C2=A0 handle: { value: =E2=80=9Chjkl=E2=80=9D, type: bearer }
}

Now the client could poll the TX Endpoint but it could also just sit a= nd wait for an update to be pushed in.=C2=A0

There are probably things that need to be tied together for this to be= secure, but I think the basic pattern still fits. Importantly, the client = doesn=E2=80=99t care whereby of that stuff came from =E2=80=94 as far as it= =E2=80=99s concerned, it=E2=80=99s talking to the AS.=C2=A0

Remember, the =E2=80=9CAS=E2=80=9D is a logical construct, not a physi= cal one. Just like the =E2=80=9Cclient=E2=80=9D could be a cluster of appli= cations and the =E2=80=9CRS=E2=80=9D could be a suite of APIs tied behind a= gateway.

=C2=A0=E2=80=94 Justin


On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle <richanna@amazon.com> = wrote:


On Dec 21, 2019, at 4:42 AM, Justin Richer <jricher@mit.edu> = wrote:

Even if the client starts at the RS, the client still has to go talk t= o the AS. I haven=E2=80=99t built this out, but I see it working somewhat l= ike UMA. In XYZ=E2=80=99s terms:


1. Client calls the RS trying to Do A Thing
2. RS calls the AS requesting a Resource Handle (because that=E2=80=99= s what the RS represents, resources) =E2=80=94 at least good enough to cove= r what the client tried to do, could be more
3. RS gives the Resource Handle and AS Transaction Endpoint back to th= e client
4. Client calls the AS Transaction Endpoint to start a transaction, in= cludes the Resource Handle as part of its request (note: doesn=E2=80=99t ha= ve to be the whole resource section, client can add stuff)
5. Process continues as normal

It depends on what you consider the =E2=80=9CAS=E2=80=9D. Consider the= following hypothetical architecture:

=E2=80=A2 The RS, client, and tx endpoint are on the public Internet.<= /div>
=E2=80=A2 The tx endpoint returns interaction urls that point to an Id= P that is inaccessible from the public Internet.
=E2=80=A2 The user agent can reach the IdP, but none of the other syst= ems can.
=E2=80=A2 When the UA is redirected to the IdP, the IdP calls the tx e= ndpoint system to retrieve transaction details.
=E2=80=A2 When authorization is granted, the IdP pushes artifacts dire= ctly to an endpoint provided by the client.

In this example, the client only interacts with the RS and the tx endp= oint. It seems odd to me to consider the system hosting the tx endpoint to = be the AS (or at least part of the AS), as its a glorified message queue wi= th essentially no authority in this architecture.=C2=A0

We could go a step further and remove the client=E2=80=99s interaction= with the tx endpoint by having the RS return the interaction url directly = (you=E2=80=99d need to secure the client nonce if you want to hide it from = the RS, but that=E2=80=99s not that hard).

Is the meaning of =E2=80=9Cauthorization server=E2=80=9D (or the phras= e =E2=80=9Cthrough an authorization server=E2=80=9D) flexible enough to acc= ommodate these cases? Or are they considered out of scope for TxAuth?

=C2=A0=E2=80=94 Justin


As I said, maybe I=E2=80=99m being too literal.

3D""=E1=90=A7
On Fri, Dec 20, 2019 at 5:08 PM Richa= rd Backman, Annabelle <richanna@amazon.com> wrote:

I=E2=80=99m not sure if this is what Eve had in mind= , but consider an automated system in an enterprise context that has been a= uthorized by an administrator. The automated system isn=E2=80=99t acting as= or on behalf of the administrator, and the administrator hasn=E2=80=99t =E2=80=9Cdelegated access=E2=80=9D; they=E2=80=99ve gran= ted access, just as they do when they assign permissions to users/group= s/roles/etc.

Maybe I=E2=80=99m being too literal, but =E2=80=9Cth= rough an authorization server=E2=80=9D in paragraph 1 implies a specific co= ntext/information/request flow to me. Given that one of TxAuth=E2=80=99s fe= atures is decoupling the different communication channels, we should not suggest that the client or authorizing party is directly interacting w= ith the AS.

=C2=A0

=E2=80=93=C2=A0

Annabelle Richard Bac= kman

AWS Identity

=C2=A0

=C2=A0

From: Txauth <txauth-bounces@ietf.org> on behalf o= f Dick Hardt <= dick.hardt@gmail.com>
Date: Friday, December 20, 2019 at 4:14 PM
To: Eve Maler <eve@xmlgrrl.com>
Cc: "rdd@cert= .org" <rdd@ce= rt.org>, "= txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jri= cher@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: [Txauth] TxAuth Proposed Charter

=C2=A0

Eve: do you not think the software client is acting = on behalf of some party? Or do you think that software always is acting on = behalf of some party, and the mentioned phrase is redundant?

=C2=A0

Justin: a couple questions

=C2=A0

1. What is meant by "Delegation between multipl= e users" ?

=C2=A0

2. Why do you restrict this to HTTP?

=C2=A0

3. Why is authentication not in scope?=

=C2=A0

4. When you say "not backwards compatible with = OAuth 2.0 and its extensions", do you expect to define a new standard = to replace RFC 6750? Developers will have to have a new method to call APIs= ?

=C2=A0

=C2=A0

On Fri, Dec 20, 2019 at 3:27 PM Eve Maler <eve@xmlgrrl.com> wrot= e:

Re =E2=80=9Cto a software client _acting on behalf of an au= thorizing party_=E2=80=9D: There is a whole lot of philosophy behind whom the delegated access is performed on behalf = of, unless the scenario is single-user or some "act as" semantic = is spelled out on the wire. Does it need to be stated here? What's the = consequence if the highlighted phrase were removed?=C2=A0<= /u>

Eve Maler (sent from = my iPad) |=C2=A0cell +1 425 345 6756



On Dec 20, 2019, at 4:3= 4 PM, Justin Richer <jricher@mit.edu> wrote:

Hi all,

=C2=A0

As discussed in Singapore, no matter what forum TxAu= th takes, its work will require a new charter. With that in mind, I=E2=80= =99ve taken a bit of time to put together a proposed charter text for the T= xAuth work:

=C2=A0

This group is chartered to develop a next-generation= transactional authorization and delegation protocol for HTTP-based APIs an= d their clients. These transactions will allow an authorizing party to dele= gate a right of access for an API or set of APIs through an authorization server to a software client acting= on behalf of an authorizing party.=C2=A0

=C2=A0

The group will deliver a protocol specification deta= iling how a client can request and obtain delegated access, how an authoriz= ation server can provide delegated access, how an authorized party can auth= orize delegated access, and how that authorized access can be communicated to the resources being protected. Th= ese actions will be connected through an explicit transaction between the c= lient and authorization server, resulting in an artifact that will allow th= e client to undertake the delegated action.=C2=A0

=C2=A0

Additionally, the delegation process will allow for:=

- Fine-grained specification of resource access

- Delegation between multiple users

- Web, mobile, single-page, and other client applica= tions

=C2=A0

The group will define extension points for this prot= ocol to allow for flexibility in areas including:

=C2=A0

- Cryptographic agility for keys, message signatures= , and proof of possession=C2=A0

- User interaction mechanisms including web and non-= web methods

- Token presentation mechanisms and key bindings<= /u>

=C2=A0

The artifacts for this work are not intended or expe= cted to be backwards-compatible with OAuth 2.0 and its extensions.=C2=A0=

=C2=A0

While this work could be done in within the OAuth wo= rking group, I now believe that it should be done in a new working group, a= nd that we should try to get that working group up and running prior to the= Vancouver meeting in March.. I think this group should stay here on the TxAuth list, and it=E2=80=99s my sugges= tion that the resulting work be called OAuth 3.0.=C2=A0

=C2=A0

Why a new group? I think that the OAuth working grou= p should remain focused on extending, patching, and adapting OAuth 2.0 to a= changing world. I plan to be engaged in both groups, and I know most of yo= u are as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so established already, there are a LOT of people who a= ren=E2=80=99t going to be interested in something new any time soon. But on= the other hand, there are a number of people for whom OAuth 2.0 does not w= ork, or is at the very least a poor fit, and we=E2=80=99ll want to bring them in at this early stage. So even with = significant overlap, I think there=E2=80=99s enough disconnect in the commu= nity from both sides that warrants a new group. In addition, I think this i= s a big enough piece of work that it=E2=80=99s simply too much for the OAuth working group to be able to focus on. We wouldn=E2=80= =99t be able to get additional meeting time, and OAuth already has trouble = fitting into its two meeting slots as it is.

=C2=A0

I=E2=80=99ve published a blog post detailing more of= my rationale:

=C2=A0

=C2=A0

Please suggest changes to the proposed charter text = above. It=E2=80=99s my hope that we can get the chartering process started.=

=C2=A0

=C2=A0=E2=80=94 Justin

--
Txauth mailing list
Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth



--0000000000002e3dba059ab380fc-- From nobody Fri Dec 27 10:28:01 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A4C120274 for ; Fri, 27 Dec 2019 10:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 IzVcHVmwKkRC for ; Fri, 27 Dec 2019 10:27:57 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 D738512013B for ; Fri, 27 Dec 2019 10:27:56 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id l18so13037785lfc.1 for ; Fri, 27 Dec 2019 10:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rAk7xBKOfldEk9DOAu69yZS+RZzKvhwmCJAH6dXpqJw=; b=DDbconVrgD/gr/q3GnmHavrXMTGwB179rOTe9VriE+Pm2g05KOt7Llz+TkZy/gA3fA Tf98t5A0SZTFeM9ASvjLjF9JC9PbcQrDj9RyprJKqLb75gUVK9A/mctHpQRinpkYZT9H cqwJ55/Y/a1e31j/iU0na4lFDV44avuQhBOlUSJPPHMo8ojYk2N4IdZAATuYlhMH9fsy nPr8SD9xwWQhBvvuaVksqsby2CxipGZS30YEb9q08iUk26V3yD/RCGXxFC0PfcFwxSno 8cpl3QQOfXP+fWtd7RoYkb4Juf1PaJW8QYr5AXUWJrrRNv2yyrajKQ19IyB1eyNwjCm4 Cm/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rAk7xBKOfldEk9DOAu69yZS+RZzKvhwmCJAH6dXpqJw=; b=pbXqpNfYIwu78Two6L7lIWefPxZ93Kqp3ohH6D9Ia11eYzjLBB4OGxe3PRUamOzFpg 3MebKehau+fZN3gajmfdVMUAo4Jvmbxo6Oq3D4CJ/xZGFBrqeJRruNyrWH5lfLS5kuf0 rMSb2jrVFiRRLWcxR8ndBhoEqpylIs/Z4/+JsDv/A9f5OyTKDpY5vPc/19tXE5ZlgSr2 AQgGWRymrka6qOM81vp9JnnXFx7ACthyJOwAdm4GoY7Kkf3M5a/TCCY4oerAtHTgOXMn qMBuHnph/VKubHkOGhLWfVOtdkkLr19PTLGGpS8r0SsgsNcEyuU/vBdwp6mr43EvmJPL jLyA== X-Gm-Message-State: APjAAAXuhCqyb5U24Zfgh/RguLGPsGy57qFtp1kAjjcFOfh9v9Fj2Yl4 TSdqZbGlixG9icnaMM8rD2l16AtKztptyupzXEY= X-Google-Smtp-Source: APXvYqw3C3H5zhCXD4v83kNJ1bHHRAwZiVQB1LVcmagDXum+GZzITIoCOxJHa29jDRaQmP+GNHHpWs1zk2VHg67sEIc= X-Received: by 2002:a19:784:: with SMTP id 126mr29315271lfh.191.1577471274905; Fri, 27 Dec 2019 10:27:54 -0800 (PST) MIME-Version: 1.0 References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> In-Reply-To: <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> From: Dick Hardt Date: Fri, 27 Dec 2019 10:27:31 -0800 Message-ID: To: Justin Richer Cc: Brian Campbell , "rdd@cert.org" , Yaron Sheffer , Benjamin Kaduk , Aaron Parecki , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000fbf61e059ab3a6e3" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2019 18:28:00 -0000 --000000000000fbf61e059ab3a6e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Brian. Developers such as large enterprise customers are going to be confused when they hear there is an OAuth 3 in the works. Some will push pause on projects because they worry that it will be outdated when it is released. They won't know which to deploy, even though OAuth 3 is not available. Also, if what we are working on includes authentication / identity -- it no longer is just delegated authorization See inline comments below. On Tue, Dec 24, 2019 at 4:22 PM Justin Richer wrote: > Brian, I hear what you=E2=80=99re saying, but I disagree completely. > > Who would be confused by seeing a major revision to an existing protocol > that worked in a different way and did the same things but also new thing= s? > That happens all the time. > And it causes market confusion all the time. Conservative organizations stop doing things when it is not clear what the future will be. > > Was there significant confusion between OAuth 1 and 2, enough to hamper > adoption of either? For the people who deeply invested in OAuth 1 and > didn=E2=80=99t need or want the OAuth 2 newness, they stuck with it (see:= twitter). > Twitter stuck with OAuth 1 because they did not like bearer tokens. Yes, there was lots of confusion between OAuth 1 and 2. Erin did not want what became OAuth 2 to be called OAuth because of the confusion. Hence it was called WRAP early. The actual name of the WG is "Web Authorization Protocol" > > Was OpenID Connect a major disservice to OpenID 2? It was a disruption, > for sure, but people transitioned where it made sense for them, and in ma= ny > cases that took years of dual-deployment and transition. > The work that was being done on OpenID 3 was killed because a large platform company that starts with G did not want to confuse their customers about a new version. > > I see us walking along the same kind of path here, nearly a decade later. > That=E2=80=99s why I think OAuth 3 makes sense as a name for the output o= f this > work. Or at the very least, for the core delegation protocol portion of > whatever we make. I think it sends the right message to implementers and > developers: the community that knows and understands OAuth 2 is working o= n > the next version of that thing, so when it=E2=80=99s ready, maybe you sho= uld look > at it. Until it=E2=80=99s done, and for a long time after, OAuth 2 is sti= ll going > to be there and be the right answer. > I agree that people may be confused if it is called something else that OAuth, but if it is broader than OAuth, then that is confusing as well. > > The name isn=E2=80=99t a hill I=E2=80=99m committed to dying alone on, bu= t I think it > sends a :bad: message if we call it something new entirely. Namely, that = we > think people :should: abandon the entire world of OAuth, all of its ideas > and implementations. That=E2=80=99s not what we=E2=80=99re doing with thi= s design, it=E2=80=99s an > evolution as I see things. And as an evolution, a new major revision numb= er > makes sense. > > =E2=80=94 Justin > > On Dec 24, 2019, at 9:54 AM, Brian Campbell > wrote: > > Naming any prospective resulting work here "OAuth 3.0" would significantl= y > exacerbate confusion in the whole space and would be a major disservice t= o > the broader community. > > > On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki wrote: > >> I definitely am not trying to discuss specifics of *how* authentication >> should be included right now, but I just want to make sure it's included= in >> the charter so that we can actually talk about it and it won't be "out o= f >> scope" when we eventually do talk about the specifics. >> >> Aaron >> >> >> >> On Mon, Dec 23, 2019 at 1:51 PM Justin Richer wrote: >> >>> I=E2=80=99m fine with it being in charter but I do think it should be a= clearly >>> separate layer, much like OIDC/Facebook Connect/GitHub Login/etc are wi= th >>> OAuth today. In all of these the authorization is first, and I think th= at=E2=80=99s >>> the right pattern. So if we do take it on we=E2=80=99ll just need to be= careful how >>> it=E2=80=99s structured in with everything else. Otherwise, I think the >>> authentication side can quickly overwhelm and drag down the authorizati= on >>> side. >>> >>> Good news: A lot of the additional stuff in OIDC is there to patch hole= s >>> in core OAuth in a common fashion, and we=E2=80=99ll at least be in a p= osition to >>> not have to do that again. >>> >>> >>> =E2=80=94 Justin >>> >>> On Dec 22, 2019, at 10:46 PM, Aaron Parecki wrote: >>> >>> I do think authentication should be part of the charter from the outset= . >>> Frankly the fact that authentication is intentionally left out of OAuth= and >>> has to be bolted on to the side via OpenID Connect is one of the exact >>> reasons people get confused about the whole space to begin with. >>> >>> It's a relatively minor addition to the existing proposed spec to make >>> it useful as a minimum viable authentication solution, and I'd like to = see >>> that be addressed at the beginning of this work. >>> >>> I think we can do this in a smart way and that authentication should be >>> included in the charter. >>> >>> Aaron >>> >>> >>> >>> >>> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer >>> wrote: >>> >>>> Hi Justin, >>>> >>>> >>>> >>>> I think the charter should mention target use cases. For example, =E2= =80=9Call >>>> use cases supported by OAuth 2 will be supported by the new protocol= =E2=80=9D or >>>> =E2=80=9Cthe protocol will support at least use cases X and Y=E2=80=9D= . >>>> >>>> >>>> >>>> And given the importance of OIDC, we could say something like: =E2=80= =9CThe >>>> protocol will allow future extension to support authentication, in an >>>> analogous way to OpenID Connect. However authentication is explicitly = not >>>> part of the initial scope.=E2=80=9D >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Yaron >>>> >>>> >>>> >>>> *From: *Txauth on behalf of Justin Richer < >>>> jricher@mit.edu> >>>> *Date: *Saturday, December 21, 2019 at 00:34 >>>> *To: * >>>> *Cc: *"rdd@cert.org" , Benjamin Kaduk >>>> *Subject: *[Txauth] TxAuth Proposed Charter >>>> >>>> >>>> >>>> Hi all, >>>> >>>> >>>> >>>> As discussed in Singapore, no matter what forum TxAuth takes, its work >>>> will require a new charter. With that in mind, I=E2=80=99ve taken a bi= t of time to >>>> put together a proposed charter text for the TxAuth work: >>>> >>>> >>>> >>>> This group is chartered to develop a next-generation transactional >>>> authorization and delegation protocol for HTTP-based APIs and their >>>> clients. These transactions will allow an authorizing party to delegat= e a >>>> right of access for an API or set of APIs through an authorization ser= ver >>>> to a software client acting on behalf of an authorizing party. >>>> >>>> >>>> >>>> The group will deliver a protocol specification detailing how a client >>>> can request and obtain delegated access, how an authorization server c= an >>>> provide delegated access, how an authorized party can authorize delega= ted >>>> access, and how that authorized access can be communicated to the reso= urces >>>> being protected. These actions will be connected through an explicit >>>> transaction between the client and authorization server, resulting in = an >>>> artifact that will allow the client to undertake the delegated action. >>>> >>>> >>>> >>>> Additionally, the delegation process will allow for: >>>> >>>> - Fine-grained specification of resource access >>>> >>>> - Delegation between multiple users >>>> >>>> - Web, mobile, single-page, and other client applications >>>> >>>> >>>> >>>> The group will define extension points for this protocol to allow for >>>> flexibility in areas including: >>>> >>>> >>>> >>>> - Cryptographic agility for keys, message signatures, and proof of >>>> possession >>>> >>>> - User interaction mechanisms including web and non-web methods >>>> >>>> - Token presentation mechanisms and key bindings >>>> >>>> >>>> >>>> The artifacts for this work are not intended or expected to be >>>> backwards-compatible with OAuth 2.0 and its extensions. >>>> >>>> >>>> >>>> While this work could be done in within the OAuth working group, I now >>>> believe that it should be done in a new working group, and that we sho= uld >>>> try to get that working group up and running prior to the Vancouver me= eting >>>> in March. I think this group should stay here on the TxAuth list, and = it=E2=80=99s >>>> my suggestion that the resulting work be called OAuth 3.0. >>>> >>>> >>>> >>>> Why a new group? I think that the OAuth working group should remain >>>> focused on extending, patching, and adapting OAuth 2.0 to a changing w= orld. >>>> I plan to be engaged in both groups, and I know most of you are as wel= l, >>>> but that=E2=80=99s not universal. Since OAuth 2.0 is so established al= ready, there >>>> are a LOT of people who aren=E2=80=99t going to be interested in somet= hing new any >>>> time soon. But on the other hand, there are a number of people for who= m >>>> OAuth 2.0 does not work, or is at the very least a poor fit, and we=E2= =80=99ll want >>>> to bring them in at this early stage. So even with significant overlap= , I >>>> think there=E2=80=99s enough disconnect in the community from both sid= es that >>>> warrants a new group. In addition, I think this is a big enough piece = of >>>> work that it=E2=80=99s simply too much for the OAuth working group to = be able to >>>> focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth >>>> already has trouble fitting into its two meeting slots as it is. >>>> >>>> >>>> >>>> I=E2=80=99ve published a blog post detailing more of my rationale: >>>> >>>> >>>> >>>> >>>> https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-w= orking-group-d6229ba8e36? >>>> >>>> >>>> >>>> >>>> Please suggest changes to the proposed charter text above. It=E2=80=99= s my hope >>>> that we can get the chartering process started. >>>> >>>> >>>> >>>> =E2=80=94 Justin >>>> >>>> -- Txauth mailing list Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> -- >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>> >>> >>> -- >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.* > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000fbf61e059ab3a6e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Brian. Deve= lopers such as large enterprise customers are going=C2=A0to be confused whe= n they hear there is an OAuth 3 in the works. Some will push pause on proje= cts because they worry that it will be outdated when it is released. They w= on't know which to deploy, even though OAuth 3 is not available.=C2=A0<= div>
Also, if what we are working on includes authentication = / identity -- it no longer is just delegated authorization
See inline comments below.


On Tue, Dec 24, 2019 at 4:22 PM Justin Richer <jricher@mit.edu> wrote:
Brian, I hear what you=E2=80=99re saying, but I disagree completely.
Who would be confused by seeing a major revision to an ex= isting protocol that worked in a different way and did the same things but = also new things? That happens all the time.
And it causes market confusion all the time. Conservative orga= nizations stop doing things when it is not clear what the future will be.
=C2=A0

Was there signifi= cant confusion between OAuth 1 and 2, enough to hamper adoption of either? = For the people who deeply invested in OAuth 1 and didn=E2=80=99t need or wa= nt the OAuth 2 newness, they stuck with it (see: twitter).=C2=A0

Twitter stuck with OAuth 1 because they d= id not like bearer tokens.=C2=A0

Yes, there was lo= ts of confusion between OAuth 1 and 2. Erin did not want what became OAuth = 2 to be called OAuth because of the confusion. Hence it was called WRAP ear= ly. The actual name of the WG is "Web Authorization Protocol"

=C2=A0

Wa= s OpenID Connect a major disservice to OpenID 2? It was a disruption, for s= ure, but people transitioned where it made sense for them, and in many case= s that took years of dual-deployment and transition.=C2=A0

The work that was being done on OpenID 3 was ki= lled because a large platform company that starts with G did not want to co= nfuse their customers about a new version.
=C2=A0

I see us walking along the same kind of path her= e, nearly a decade later. That=E2=80=99s why I think OAuth 3 makes sense as= a name for the output of this work. Or at the very least, for the core del= egation protocol portion of whatever we make. I think it sends the right me= ssage to implementers and developers: the community that knows and understa= nds OAuth 2 is working on the next version of that thing, so when it=E2=80= =99s ready, maybe you should look at it. Until it=E2=80=99s done, and for a= long time after, OAuth 2 is still going to be there and be the right answe= r.=C2=A0

I agree that people ma= y be confused if it is called something else that OAuth, but if it is broad= er than OAuth, then that is confusing as well.
=C2=A0

The name isn=E2=80=99t a hill I=E2=80=99m co= mmitted to dying alone on, but I think it sends a :bad: message if we call = it something new entirely. Namely, that we think people :should: abandon th= e entire world of OAuth, all of its ideas and implementations. That=E2=80= =99s not what we=E2=80=99re doing with this design, it=E2=80=99s an evoluti= on as I see things. And as an evolution, a new major revision number makes = sense.

=C2=A0=E2=80=94 Justin

On Dec 24, 2019, at 9:54 AM, Brian Campbell <bcampbell@pingi= dentity.com> wrote:

Naming any p= rospective resulting work here "OAuth 3.0" would significantly ex= acerbate confusion in the whole space and would be a major disservice to th= e broader community.


On Mon, Dec 23, 2019 at = 7:39 PM Aaron Parecki <aaron@parecki.com> wrote:
I definitely am not trying to= discuss specifics of *how* authentication should be included right now, bu= t I just want to make sure it's included in the charter so that we can = actually talk about it and it won't be "out of scope" when we= eventually do talk about the specifics.

<= /div>
Aaron



On Mon, Dec 23, 2019 at 1:51 PM Justin Richer <jricher@mit.edu> wrote= :
I=E2=80= =99m fine with it being in charter but I do think it should be a clearly se= parate layer, much like OIDC/Facebook Connect/GitHub Login/etc are with OAu= th today. In all of these the authorization is first, and I think that=E2= =80=99s the right pattern. So if we do take it on we=E2=80=99ll just need t= o be careful how it=E2=80=99s structured in with everything else. Otherwise= , I think the authentication side can quickly overwhelm and drag down the a= uthorization side.

Good news: A lot of the additional st= uff in OIDC is there to patch holes in core OAuth in a common fashion, and = we=E2=80=99ll at least be in a position to not have to do that again.=C2=A0=


=C2=A0=E2=80=94 Justin

On Dec 22, 2019, at 10:46 PM, Aaron Pa= recki <aaron@pare= cki.com> wrote:

I do think auth= entication should be part of the charter from the outset. Frankly the fact = that authentication is intentionally left out of OAuth and has to be bolted= on to the side via OpenID Connect is one of the exact reasons people get c= onfused about the whole space to begin with.=C2=A0

It's a relatively minor addition to th= e existing proposed spec to make it useful as a minimum viable authenticati= on solution, and I'd like to see that be addressed at the beginning of = this work.

I think we ca= n do this in a smart way and that authentication should be included in the = charter.

Aaron



<= /div>

On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:<= br>

Hi Justin,

=C2=A0

I think the charter = should mention target use cases. For example, =E2=80=9Call use cases suppor= ted by OAuth 2 will be supported by the new protocol=E2=80=9D or =E2=80=9Ct= he protocol will support at least use cases X and Y=E2=80=9D.=

=C2=A0

A= nd given the importance of OIDC, we could say something like: =E2=80=9CThe = protocol will allow future extension to support authentication, in an analo= gous way to OpenID Connect. However authentication is explicitly not part o= f the initial scope.=E2=80=9D

=C2=A0

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

From: Txauth <txauth-bounces@ietf.org> on behalf of Justin Rich= er <jricher@mit.edu= >
Date: Saturday, December 21, 2019 at 00:34
To: <txauth@ietf.org>
Cc: "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>
Subject: [Txauth] TxAu= th Proposed Charter

=C2=A0

Hi all,

=C2=A0

As discussed in Singapore, no matter what forum TxAuth tak= es, its work will require a new charter. With that in mind, I=E2=80=99ve ta= ken a bit of time to put together a proposed charter text for the TxAuth wo= rk:

=C2=A0=

This group is chartered to develop a next-generation tra= nsactional authorization and delegation protocol for HTTP-based APIs and th= eir clients. These transactions will allow an authorizing party to delegate= a right of access for an API or set of APIs through an authorization serve= r to a software client acting on behalf of an authorizing party.=C2=A0

=C2=A0

The group will deliver a protocol specificati= on detailing how a client can request and obtain delegated access, how an a= uthorization server can provide delegated access, how an authorized party c= an authorize delegated access, and how that authorized access can be commun= icated to the resources being protected. These actions will be connected th= rough an explicit transaction between the client and authorization server, = resulting in an artifact that will allow the client to undertake the delega= ted action.=C2=A0

=C2=A0

Additionally, the deleg= ation process will allow for:

- Fine-grained specification of resource access

- Delegation between multiple users=

- Web, mobile, single-page, and o= ther client applications

=C2=A0

The group will d= efine extension points for this protocol to allow for flexibility in areas = including:

=C2=A0=

- Cryptographic agility for ke= ys, message signatures, and proof of possession=C2=A0

- User interaction mechanisms including web a= nd non-web methods

- Tok= en presentation mechanisms and key bindings

=C2=A0

The artifacts for this work are not intended or expected to be backwards= -compatible with OAuth 2.0 and its extensions.=C2=A0

=C2=A0

While this work could be done in within the OAuth = working group, I now believe that it should be done in a new working group,= and that we should try to get that working group up and running prior to t= he Vancouver meeting in March. I think this group should stay here on the T= xAuth list, and it=E2=80=99s my suggestion that the resulting work be calle= d OAuth 3.0.=C2=A0

=C2=A0

Why a new group? I thi= nk that the OAuth working group should remain focused on extending, patchin= g, and adapting OAuth 2.0 to a changing world. I plan to be engaged in both= groups, and I know most of you are as well, but that=E2=80=99s not univers= al. Since OAuth 2.0 is so established already, there are a LOT of people wh= o aren=E2=80=99t going to be interested in something new any time soon. But= on the other hand, there are a number of people for whom OAuth 2.0 does no= t work, or is at the very least a poor fit, and we=E2=80=99ll want to bring= them in at this early stage. So even with significant overlap, I think the= re=E2=80=99s enough disconnect in the community from both sides that warran= ts a new group. In addition, I think this is a big enough piece of work tha= t it=E2=80=99s simply too much for the OAuth working group to be able to fo= cus on. We wouldn=E2=80=99t be able to get additional meeting time, and OAu= th already has trouble fitting into its two meeting slots as it is.<= u>

=C2=A0

<= div>

I=E2=80=99ve published a blog post detailing mor= e of my rationale:

=C2=A0

https://medium..com/@justinsecurity/the-case-fo= r-oauth-3-0-why-a-new-working-group-d6229ba8e36?

=C2=A0

Please suggest changes to the proposed charter text above. It= =E2=80=99s my hope that we can get the chartering process started.

=C2=A0

=C2=A0=E2=80=94 Justin

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listi= nfo/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
----
Aaron = Parecki


-- =
----
Aaron Parecki
@aaronpk

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000fbf61e059ab3a6e3-- From nobody Sat Dec 28 09:07:26 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83682120130 for ; Sat, 28 Dec 2019 09:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ntLvR8m_Wnl5 for ; Sat, 28 Dec 2019 09:07:20 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2A91F120131 for ; Sat, 28 Dec 2019 09:07:19 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBSH7BiD029135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 28 Dec 2019 12:07:12 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_27B08B23-EC86-4128-868E-2046E6A33ECE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 28 Dec 2019 12:07:11 -0500 In-Reply-To: Cc: Brian Campbell , "rdd@cert.org" , Yaron Sheffer , Benjamin Kaduk , Aaron Parecki , txauth@ietf.org To: Dick Hardt References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 17:07:24 -0000 --Apple-Mail=_27B08B23-EC86-4128-868E-2046E6A33ECE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is going to be the case whatever we call this new work. Progress is = going to continue to happen, and if a large enterprise decides to wait = for the new shiny thing 3 years from now, then that=E2=80=99s on them.=20= In my experience, it=E2=80=99s more likely that a large enterprise is = going to shy away from the new shiny thing and go with what they can buy = in a supported package off the shelf. And I think that=E2=80=99s the = kind of timescale that=E2=80=99s going to drive most of the developers = decisions around whether to track the new work or use what=E2=80=99s out = there =E2=80=94 they need to ask =E2=80=9Cwhat do I need?=E2=80=9D And = =E2=80=9Cwhen do I need it?=E2=80=9D But these are :always: the questions that you need to ask when starting = a project and choosing technologies.=20 I still contend that the name OAuth 3 does a better job at communicating = what=E2=80=99s going on here. =E2=80=94 Justin > On Dec 27, 2019, at 1:27 PM, Dick Hardt wrote: >=20 > I agree with Brian. Developers such as large enterprise customers are = going to be confused when they hear there is an OAuth 3 in the works. = Some will push pause on projects because they worry that it will be = outdated when it is released. They won't know which to deploy, even = though OAuth 3 is not available.=20 >=20 > Also, if what we are working on includes authentication / identity -- = it no longer is just delegated authorization >=20 > See inline comments below. >=20 >=20 > On Tue, Dec 24, 2019 at 4:22 PM Justin Richer > wrote: > Brian, I hear what you=E2=80=99re saying, but I disagree completely. >=20 > Who would be confused by seeing a major revision to an existing = protocol that worked in a different way and did the same things but also = new things? That happens all the time. >=20 > And it causes market confusion all the time. Conservative = organizations stop doing things when it is not clear what the future = will be. > =20 >=20 > Was there significant confusion between OAuth 1 and 2, enough to = hamper adoption of either? For the people who deeply invested in OAuth 1 = and didn=E2=80=99t need or want the OAuth 2 newness, they stuck with it = (see: twitter).=20 >=20 > Twitter stuck with OAuth 1 because they did not like bearer tokens.=20 >=20 > Yes, there was lots of confusion between OAuth 1 and 2. Erin did not = want what became OAuth 2 to be called OAuth because of the confusion. = Hence it was called WRAP early. The actual name of the WG is "Web = Authorization Protocol" >=20 > =20 >=20 > Was OpenID Connect a major disservice to OpenID 2? It was a = disruption, for sure, but people transitioned where it made sense for = them, and in many cases that took years of dual-deployment and = transition.=20 >=20 > The work that was being done on OpenID 3 was killed because a large = platform company that starts with G did not want to confuse their = customers about a new version. > =20 >=20 > I see us walking along the same kind of path here, nearly a decade = later. That=E2=80=99s why I think OAuth 3 makes sense as a name for the = output of this work. Or at the very least, for the core delegation = protocol portion of whatever we make. I think it sends the right message = to implementers and developers: the community that knows and understands = OAuth 2 is working on the next version of that thing, so when it=E2=80=99s= ready, maybe you should look at it. Until it=E2=80=99s done, and for a = long time after, OAuth 2 is still going to be there and be the right = answer.=20 >=20 > I agree that people may be confused if it is called something else = that OAuth, but if it is broader than OAuth, then that is confusing as = well. > =20 >=20 > The name isn=E2=80=99t a hill I=E2=80=99m committed to dying alone on, = but I think it sends a :bad: message if we call it something new = entirely. Namely, that we think people :should: abandon the entire world = of OAuth, all of its ideas and implementations. That=E2=80=99s not what = we=E2=80=99re doing with this design, it=E2=80=99s an evolution as I see = things. And as an evolution, a new major revision number makes sense. >=20 > =E2=80=94 Justin >=20 >> On Dec 24, 2019, at 9:54 AM, Brian Campbell = > wrote: >>=20 >> Naming any prospective resulting work here "OAuth 3.0" would = significantly exacerbate confusion in the whole space and would be a = major disservice to the broader community.=20 >>=20 >>=20 >> On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki > wrote: >> I definitely am not trying to discuss specifics of *how* = authentication should be included right now, but I just want to make = sure it's included in the charter so that we can actually talk about it = and it won't be "out of scope" when we eventually do talk about the = specifics. >>=20 >> Aaron >>=20 >>=20 >>=20 >> On Mon, Dec 23, 2019 at 1:51 PM Justin Richer > wrote: >> I=E2=80=99m fine with it being in charter but I do think it should be = a clearly separate layer, much like OIDC/Facebook Connect/GitHub = Login/etc are with OAuth today. In all of these the authorization is = first, and I think that=E2=80=99s the right pattern. So if we do take it = on we=E2=80=99ll just need to be careful how it=E2=80=99s structured in = with everything else. Otherwise, I think the authentication side can = quickly overwhelm and drag down the authorization side. >>=20 >> Good news: A lot of the additional stuff in OIDC is there to patch = holes in core OAuth in a common fashion, and we=E2=80=99ll at least be = in a position to not have to do that again.=20 >>=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Dec 22, 2019, at 10:46 PM, Aaron Parecki > wrote: >>>=20 >>> I do think authentication should be part of the charter from the = outset. Frankly the fact that authentication is intentionally left out = of OAuth and has to be bolted on to the side via OpenID Connect is one = of the exact reasons people get confused about the whole space to begin = with.=20 >>>=20 >>> It's a relatively minor addition to the existing proposed spec to = make it useful as a minimum viable authentication solution, and I'd like = to see that be addressed at the beginning of this work. >>>=20 >>> I think we can do this in a smart way and that authentication should = be included in the charter. >>>=20 >>> Aaron >>>=20 >>>=20 >>>=20 >>>=20 >>> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer > wrote: >>> Hi Justin, >>>=20 >>> =20 >>>=20 >>> I think the charter should mention target use cases. For example, = =E2=80=9Call use cases supported by OAuth 2 will be supported by the new = protocol=E2=80=9D or =E2=80=9Cthe protocol will support at least use = cases X and Y=E2=80=9D. >>>=20 >>> =20 >>>=20 >>> And given the importance of OIDC, we could say something like: = =E2=80=9CThe protocol will allow future extension to support = authentication, in an analogous way to OpenID Connect. However = authentication is explicitly not part of the initial scope.=E2=80=9D >>>=20 >>> =20 >>>=20 >>> Thanks, >>>=20 >>> Yaron >>>=20 >>> =20 >>>=20 >>> From: Txauth > on behalf of Justin Richer = > >>> Date: Saturday, December 21, 2019 at 00:34 >>> To: > >>> Cc: "rdd@cert.org " >, Benjamin Kaduk > >>> Subject: [Txauth] TxAuth Proposed Charter >>>=20 >>> =20 >>>=20 >>> Hi all, >>>=20 >>> =20 >>>=20 >>> As discussed in Singapore, no matter what forum TxAuth takes, its = work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of time to put together a proposed charter text for the TxAuth work: >>>=20 >>> =20 >>>=20 >>> This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 >>>=20 >>> =20 >>>=20 >>> The group will deliver a protocol specification detailing how a = client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>>=20 >>> =20 >>>=20 >>> Additionally, the delegation process will allow for: >>>=20 >>> - Fine-grained specification of resource access >>>=20 >>> - Delegation between multiple users >>>=20 >>> - Web, mobile, single-page, and other client applications >>>=20 >>> =20 >>>=20 >>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>=20 >>> =20 >>>=20 >>> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >>>=20 >>> - User interaction mechanisms including web and non-web methods >>>=20 >>> - Token presentation mechanisms and key bindings >>>=20 >>> =20 >>>=20 >>> The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >>>=20 >>> =20 >>>=20 >>> While this work could be done in within the OAuth working group, I = now believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>>=20 >>> =20 >>>=20 >>> Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing = world. I plan to be engaged in both groups, and I know most of you are = as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>>=20 >>> =20 >>>=20 >>> I=E2=80=99ve published a blog post detailing more of my rationale: >>>=20 >>> =20 >>>=20 >>> = https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-worki= ng-group-d6229ba8e36? = >>> =20 >>>=20 >>> Please suggest changes to the proposed charter text above. It=E2=80=99= s my hope that we can get the chartering process started. >>>=20 >>> =20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>> -- Txauth mailing list Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth = --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>> --=20 >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>>=20 >>=20 >> --=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_27B08B23-EC86-4128-868E-2046E6A33ECE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = is going to be the case whatever we call this new work. Progress is = going to continue to happen, and if a large enterprise decides to wait = for the new shiny thing 3 years from now, then that=E2=80=99s on = them. 

In my = experience, it=E2=80=99s more likely that a large enterprise is going to = shy away from the new shiny thing and go with what they can buy in a = supported package off the shelf. And I think that=E2=80=99s the kind of = timescale that=E2=80=99s going to drive most of the developers decisions = around whether to track the new work or use what=E2=80=99s out there =E2=80= =94 they need to ask =E2=80=9Cwhat do I need?=E2=80=9D And =E2=80=9Cwhen = do I need it?=E2=80=9D

But these are :always: the questions that you need to ask = when starting a project and choosing technologies. 

I still contend that the = name OAuth 3 does a better job at communicating what=E2=80=99s going on = here.

 =E2=80= =94 Justin

On Dec 27, 2019, at 1:27 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:

I agree with Brian. Developers such as large = enterprise customers are going to be confused when they hear there = is an OAuth 3 in the works. Some will push pause on projects because = they worry that it will be outdated when it is released. They won't know = which to deploy, even though OAuth 3 is not available. 

Also, if what we are = working on includes authentication / identity -- it no longer is just = delegated authorization

See inline comments below.


On Tue, Dec = 24, 2019 at 4:22 PM Justin Richer <jricher@mit.edu> wrote:
Brian, I hear what you=E2=80=99re saying, but I = disagree completely.

Who would be confused by seeing a major revision to an = existing protocol that worked in a different way and did the same things = but also new things? That happens all the = time.

And it causes market confusion all the time. Conservative = organizations stop doing things when it is not clear what the future = will be.
 

Was there significant confusion between OAuth 1 and 2, enough = to hamper adoption of either? For the people who deeply invested in = OAuth 1 and didn=E2=80=99t need or want the OAuth 2 newness, they stuck = with it (see: twitter). 

Twitter stuck with OAuth 1 because they = did not like bearer tokens. 

Yes, there was lots of confusion = between OAuth 1 and 2. Erin did not want what became OAuth 2 to be = called OAuth because of the confusion. Hence it was called WRAP early. = The actual name of the WG is "Web Authorization Protocol"

 

Was OpenID Connect a major disservice to OpenID 2? It was a = disruption, for sure, but people transitioned where it made sense for = them, and in many cases that took years of dual-deployment and = transition. 

The work that was being done on OpenID = 3 was killed because a large platform company that starts with G did not = want to confuse their customers about a new version.
 

I see us walking along the same kind of path here, nearly a = decade later. That=E2=80=99s why I think OAuth 3 makes sense as a name = for the output of this work. Or at the very least, for the core = delegation protocol portion of whatever we make. I think it sends the = right message to implementers and developers: the community that knows = and understands OAuth 2 is working on the next version of that thing, so = when it=E2=80=99s ready, maybe you should look at it. Until it=E2=80=99s = done, and for a long time after, OAuth 2 is still going to be there and = be the right answer. 

I agree that people may be confused if = it is called something else that OAuth, but if it is broader than OAuth, = then that is confusing as well.
 

The name isn=E2=80=99t a hill I=E2=80=99m committed to dying = alone on, but I think it sends a :bad: message if we call it something = new entirely. Namely, that we think people :should: abandon the entire = world of OAuth, all of its ideas and implementations. That=E2=80=99s not = what we=E2=80=99re doing with this design, it=E2=80=99s an evolution as = I see things. And as an evolution, a new major revision number makes = sense.

 =E2= =80=94 Justin

On Dec 24, 2019, at 9:54 AM, = Brian Campbell <bcampbell@pingidentity.com> = wrote:

Naming any prospective resulting work here = "OAuth 3.0" would significantly exacerbate confusion in the whole space = and would be a major disservice to the broader community.


On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki = <aaron@parecki.com> wrote:
I definitely am not trying to discuss specifics of *how* = authentication should be included right now, but I just want to make = sure it's included in the charter so that we can actually talk about it = and it won't be "out of scope" when we eventually do talk about the = specifics.

Aaron



On Mon, Dec = 23, 2019 at 1:51 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m fine with = it being in charter but I do think it should be a clearly separate = layer, much like OIDC/Facebook Connect/GitHub Login/etc are with OAuth = today. In all of these the authorization is first, and I think that=E2=80=99= s the right pattern. So if we do take it on we=E2=80=99ll just need to = be careful how it=E2=80=99s structured in with everything else. = Otherwise, I think the authentication side can quickly overwhelm and = drag down the authorization side.

Good news: A lot of the additional stuff in OIDC is there to = patch holes in core OAuth in a common fashion, and we=E2=80=99ll at = least be in a position to not have to do that = again. 


 =E2=80= =94 Justin

On Dec 22, 2019, at 10:46 PM, = Aaron Parecki <aaron@parecki.com> wrote:

I do think = authentication should be part of the charter from the outset. Frankly = the fact that authentication is intentionally left out of OAuth and has = to be bolted on to the side via OpenID Connect is one of the exact = reasons people get confused about the whole space to begin = with. 

It's a relatively minor = addition to the existing proposed spec to make it useful as a minimum = viable authentication solution, and I'd like to see that be addressed at = the beginning of this work.

I think we can do this in = a smart way and that authentication should be included in the = charter.

Aaron




On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

Hi Justin,

 

I think the charter should = mention target use cases. For example, =E2=80=9Call use cases supported = by OAuth 2 will be supported by the new protocol=E2=80=9D or =E2=80=9Cthe = protocol will support at least use cases X and Y=E2=80=9D.

 

And = given the importance of OIDC, we could say something like: =E2=80=9CThe = protocol will allow future extension to support authentication, in an = analogous way to OpenID Connect. However authentication is explicitly = not part of the initial scope.=E2=80=9D

 

Thanks,

         =        Yaron

 

From: = Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer = <jricher@mit.edu>
Date: = Saturday, December 21, 2019 at 00:34
To: = <txauth@ietf.org>
Cc: = "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>
Subject: = [Txauth] TxAuth Proposed Charter

 

Hi= all,

 

As = discussed in Singapore, no matter what forum TxAuth takes, its work will = require a new charter. With that in mind, I=E2=80=99ve taken a bit of = time to put together a proposed charter text for the TxAuth work:

 

This group is chartered to develop a next-generation = transactional authorization and delegation protocol for HTTP-based APIs = and their clients. These transactions will allow an authorizing party to = delegate a right of access for an API or set of APIs through an = authorization server to a software client acting on behalf of an = authorizing party. 

 

The = group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can = provide delegated access, how an authorized party can authorize = delegated access, and how that authorized access can be communicated to = the resources being protected. These actions will be connected through = an explicit transaction between the client and authorization server, = resulting in an artifact that will allow the client to undertake the = delegated action. 

 

Additionally, the delegation process will allow = for:

- Fine-grained specification of resource access

- Delegation between multiple users

- Web, mobile, single-page, and other client = applications

 

The = group will define extension points for this protocol to allow for = flexibility in areas including:

 

- Cryptographic agility for keys, message = signatures, and proof of possession 

- User = interaction mechanisms including web and non-web methods

- Token presentation mechanisms and key bindings

 

The = artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions. 

 

While = this work could be done in within the OAuth working group, I now believe = that it should be done in a new working group, and that we should try to = get that working group up and running prior to the Vancouver meeting in = March. I think this group should stay here on the TxAuth list, and = it=E2=80=99s my suggestion that the resulting work be called OAuth = 3.0. 

 

Why a = new group? I think that the OAuth working group should remain focused on = extending, patching, and adapting OAuth 2.0 to a changing world. I plan = to be engaged in both groups, and I know most of you are as well, but = that=E2=80=99s not universal. Since OAuth 2.0 is so established already, = there are a LOT of people who aren=E2=80=99t going to be interested in = something new any time soon. But on the other hand, there are a number = of people for whom OAuth 2.0 does not work, or is at the very least a = poor fit, and we=E2=80=99ll want to bring them in at this early stage. = So even with significant overlap, I think there=E2=80=99s enough = disconnect in the community from both sides that warrants a new group. = In addition, I think this is a big enough piece of work that it=E2=80=99s = simply too much for the OAuth working group to be able to focus on. We = wouldn=E2=80=99t be able to get additional meeting time, and OAuth = already has trouble fitting into its two meeting slots as it is.

 

I=E2=80=99= ve published a blog post detailing more of my rationale:

 

https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-= a-new-working-group-d6229ba8e36?

 

Please suggest changes to the proposed charter text = above. It=E2=80=99s my hope that we can get the chartering process = started.

 

 =E2=80= =94 Justin

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
----
Aaron = Parecki
aaronparecki.com
@aaronpk


--
----
Aaron Parecki
aaronparecki.com
@aaronpk

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
= --Apple-Mail=_27B08B23-EC86-4128-868E-2046E6A33ECE-- From nobody Sat Dec 28 09:07:51 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A7F120130 for ; Sat, 28 Dec 2019 09:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.097 X-Spam-Level: X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Iah-L-UQ3GOt for ; Sat, 28 Dec 2019 09:07:45 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 1B27E12011E for ; Sat, 28 Dec 2019 09:07:44 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBSH7BiE029135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 28 Dec 2019 12:07:39 -0500 From: Justin Richer Message-Id: <20A699D9-C2A2-4B88-8F64-454D83BB0221@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_21D647A4-7DCA-4C3A-84E0-AC1E2CBF0DC6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 28 Dec 2019 12:07:39 -0500 In-Reply-To: Cc: "Richard Backman, Annabelle" , Eve Maler , "rdd@cert.org" , "txauth@ietf.org" , Benjamin Kaduk To: Dick Hardt References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> <949341AE-C72B-4645-8F20-699F14529FFB@mit.edu> <78FA3EB7-C72F-4543-95A8-03123F4E40A1@amazon.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 17:07:50 -0000 --Apple-Mail=_21D647A4-7DCA-4C3A-84E0-AC1E2CBF0DC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99d argue that it=E2=80=99s actually essential that the complex = deployments don=E2=80=99t add complexity to the simple ones. =E2=80=94 Justin > On Dec 27, 2019, at 1:16 PM, Dick Hardt wrote: >=20 > I concur with Annabelle. Pretty much all large systems have a clear = separation between different functions to provide resiliency and = improved security (separation of duties) >=20 > Ideally we can do this without adding complexity for deployments that = don't require it. >=20 >=20 > On Sun, Dec 22, 2019 at 8:52 PM Richard Backman, Annabelle = > wrote: > My example demonstrates an architecture where the TX Endpoint, = authentication system, and token issuer aren=E2=80=99t simply different = micro services, they=E2=80=99re completely independent systems in = different trust boundaries, possibly have different domains and = different keys. This has implications for protocol design. For example, = it would no longer be sufficient to have a single jwks_uri, as OAuth 2.0 = has. >=20 > If we want to support this kind of =E2=80=9Cdecomposed AS=E2=80=9D = model, then we need to make sure that=E2=80=99s supported by the charter = and keep it in mind as we design the protocol. We can also decide it is = out of scope, but we should be intentional about that decision. >=20 > To my mind, this role decomposition is the next logical step after the = channel decomposition that TxAuth already does. I see a lot of potential = in it and think we should at minimum avoid closing the door on it. >=20 >> On Dec 22, 2019, at 5:35 PM, Justin Richer > wrote: >>=20 >> =EF=BB=BF I think you=E2=80=99re conflating the roles that different = components play, in regard to the other components, with the potential = deployment of those components. The spec needs to be written in terms of = the roles. While the roles do need to consider what potential = deployments might be, it=E2=80=99s important that we write things in in = terms of how they interact with each other and not in terms of how they = might look under the covers.=20 >>=20 >> So from the clients perspective, the TX Endpoint :is: the AS. The = client doesn=E2=80=99t care that it=E2=80=99s a =E2=80=9Cglorified = message queue=E2=80=9D or if it=E2=80=99s a massive server farm. The = client doesn=E2=80=99t care if there=E2=80=99s a TLS reverse proxy or if = it=E2=80=99s talking directly to the application layer. The only thing = the client cares about is if the TX Endpoint does the things that a TX = Endpoint is supposed to do, and we define that to be the function of the = AS.=20 >>=20 >> What=E2=80=99s important in your scenario below is that the client = would have to talk to the RS first every time. That=E2=80=99s one of the = problems that UMA has, and I think something we should avoid. I think = RS-first is an interesting pattern but AS-first ought to drive this.=20 >>=20 >> With your hypothetical layout below, it really sounds like the TX = Endpoint is a function of the IDP, which is fine. The client doesn=E2=80=99= t care that it=E2=80=99s deployed using some externalized cloud service. = The only weird thing going on is the push from the AS back to the = client. The client would need to register that with the AS (or through = the AS more specifically) as part of its transaction request. This would = be part of its interaction mechanism, because =E2=80=9Chow you get = messages and updates back to the client=E2=80=9D is part of the = interaction model.=20 >>=20 >> So for an RS-first transaction, the client calls the RS: >>=20 >> GET /foo >>=20 >> The RS returns a resource handle, but the client doesn=E2=80=99t care = where that came from. The RS could talk to the AS to get it. Probably a = new endpoint of some kind, can probably use the same kinds of key = binding that the TX Endpoint has. Or the RS can make one up that the TX = Endpoint can recognize. Or it calls the IdP to get one. The client = doesn=E2=80=99t care, and that=E2=80=99s the key point.=20 >>=20 >> WWW-Authenticate tx_endpoint=3D=E2=80=9Chttp://server//tx = =E2=80=9D resource: =E2=80=9Casdf1234=E2=80=9D >>=20 >> The client calls the TX endpoint like a normal transaction: >>=20 >> POST /tx >>=20 >> { >> resources: [ =E2=80=9Casdf1234=E2=80=9D ], >> interact: { >> redirect: true, >> push: =E2=80=9Chttp://client/push/9876 = =E2=80=9D >> } >> } >>=20 >> The AS (which is to say the TX Endpoint) tells the client to send the = user agent to the IdP >>=20 >> { >> interact_url: =E2=80=9Chttp://idp/login =E2=80=9D, >> handle: { value: =E2=80=9Chjkl=E2=80=9D, type: bearer } >> } >>=20 >> Now the client could poll the TX Endpoint but it could also just sit = and wait for an update to be pushed in.=20 >>=20 >> There are probably things that need to be tied together for this to = be secure, but I think the basic pattern still fits. Importantly, the = client doesn=E2=80=99t care whereby of that stuff came from =E2=80=94 as = far as it=E2=80=99s concerned, it=E2=80=99s talking to the AS.=20 >>=20 >> Remember, the =E2=80=9CAS=E2=80=9D is a logical construct, not a = physical one. Just like the =E2=80=9Cclient=E2=80=9D could be a cluster = of applications and the =E2=80=9CRS=E2=80=9D could be a suite of APIs = tied behind a gateway. >>=20 >> =E2=80=94 Justin >>=20 >>=20 >>> On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle = > wrote: >>>=20 >>>=20 >>>> On Dec 21, 2019, at 4:42 AM, Justin Richer > wrote: >>>=20 >>>> Even if the client starts at the RS, the client still has to go = talk to the AS. I haven=E2=80=99t built this out, but I see it working = somewhat like UMA. In XYZ=E2=80=99s terms: >>>>=20 >>>>=20 >>>> 1. Client calls the RS trying to Do A Thing >>>> 2. RS calls the AS requesting a Resource Handle (because that=E2=80=99= s what the RS represents, resources) =E2=80=94 at least good enough to = cover what the client tried to do, could be more >>>> 3. RS gives the Resource Handle and AS Transaction Endpoint back to = the client >>>> 4. Client calls the AS Transaction Endpoint to start a transaction, = includes the Resource Handle as part of its request (note: doesn=E2=80=99t= have to be the whole resource section, client can add stuff) >>>> 5. Process continues as normal >>>=20 >>> It depends on what you consider the =E2=80=9CAS=E2=80=9D. Consider = the following hypothetical architecture: >>>=20 >>> =E2=80=A2 The RS, client, and tx endpoint are on the public = Internet. >>> =E2=80=A2 The tx endpoint returns interaction urls that point to an = IdP that is inaccessible from the public Internet. >>> =E2=80=A2 The user agent can reach the IdP, but none of the other = systems can. >>> =E2=80=A2 When the UA is redirected to the IdP, the IdP calls the tx = endpoint system to retrieve transaction details. >>> =E2=80=A2 When authorization is granted, the IdP pushes artifacts = directly to an endpoint provided by the client. >>>=20 >>> In this example, the client only interacts with the RS and the tx = endpoint. It seems odd to me to consider the system hosting the tx = endpoint to be the AS (or at least part of the AS), as its a glorified = message queue with essentially no authority in this architecture.=20 >>>=20 >>> We could go a step further and remove the client=E2=80=99s = interaction with the tx endpoint by having the RS return the interaction = url directly (you=E2=80=99d need to secure the client nonce if you want = to hide it from the RS, but that=E2=80=99s not that hard). >>>=20 >>> Is the meaning of =E2=80=9Cauthorization server=E2=80=9D (or the = phrase =E2=80=9Cthrough an authorization server=E2=80=9D) flexible = enough to accommodate these cases? Or are they considered out of scope = for TxAuth? >>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>>=20 >>>>> As I said, maybe I=E2=80=99m being too literal. >>>>>=20 >>>>>> =E1=90=A7 >>>>>> On Fri, Dec 20, 2019 at 5:08 PM Richard Backman, Annabelle = > wrote: >>>>>> I=E2=80=99m not sure if this is what Eve had in mind, but = consider an automated system in an enterprise context that has been = authorized by an administrator. The automated system isn=E2=80=99t = acting as or on behalf of the administrator, and the administrator = hasn=E2=80=99t =E2=80=9Cdelegated access=E2=80=9D; they=E2=80=99ve = granted access, just as they do when they assign permissions to = users/groups/roles/etc. >>>>>>=20 >>>>>> Maybe I=E2=80=99m being too literal, but =E2=80=9Cthrough an = authorization server=E2=80=9D in paragraph 1 implies a specific = context/information/request flow to me. Given that one of TxAuth=E2=80=99s= features is decoupling the different communication channels, we should = not suggest that the client or authorizing party is directly interacting = with the AS. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =E2=80=93=20 >>>>>>=20 >>>>>> Annabelle Richard Backman >>>>>>=20 >>>>>> AWS Identity >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> From: Txauth > on behalf of Dick Hardt = > >>>>>> Date: Friday, December 20, 2019 at 4:14 PM >>>>>> To: Eve Maler > >>>>>> Cc: "rdd@cert.org " >, "txauth@ietf.org " = >, Justin Richer = >, Benjamin Kaduk = > >>>>>> Subject: Re: [Txauth] TxAuth Proposed Charter >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Eve: do you not think the software client is acting on behalf of = some party? Or do you think that software always is acting on behalf of = some party, and the mentioned phrase is redundant? >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Justin: a couple questions >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> 1. What is meant by "Delegation between multiple users" ? >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> 2. Why do you restrict this to HTTP? >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> 3. Why is authentication not in scope? >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> 4. When you say "not backwards compatible with OAuth 2.0 and its = extensions", do you expect to define a new standard to replace RFC 6750? = Developers will have to have a new method to call APIs? >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> On Fri, Dec 20, 2019 at 3:27 PM Eve Maler > wrote: >>>>>>=20 >>>>>> Re =E2=80=9Cto a software client _acting on behalf of an = authorizing party_=E2=80=9D: There is a whole lot of philosophy behind = whom the delegated access is performed on behalf of, unless the scenario = is single-user or some "act as" semantic is spelled out on the wire. = Does it need to be stated here? What's the consequence if the = highlighted phrase were removed?=20 >>>>>>=20 >>>>>> Eve Maler (sent from my iPad) | cell +1 425 345 6756 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Dec 20, 2019, at 4:34 PM, Justin Richer > wrote: >>>>>>=20 >>>>>> Hi all, >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> As discussed in Singapore, no matter what forum TxAuth takes, its = work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of time to put together a proposed charter text for the TxAuth work: >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> This group is chartered to develop a next-generation = transactional authorization and delegation protocol for HTTP-based APIs = and their clients. These transactions will allow an authorizing party to = delegate a right of access for an API or set of APIs through an = authorization server to a software client acting on behalf of an = authorizing party.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> The group will deliver a protocol specification detailing how a = client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Additionally, the delegation process will allow for: >>>>>>=20 >>>>>> - Fine-grained specification of resource access >>>>>>=20 >>>>>> - Delegation between multiple users >>>>>>=20 >>>>>> - Web, mobile, single-page, and other client applications >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> - Cryptographic agility for keys, message signatures, and proof = of possession=20 >>>>>>=20 >>>>>> - User interaction mechanisms including web and non-web methods >>>>>>=20 >>>>>> - Token presentation mechanisms and key bindings >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> While this work could be done in within the OAuth working group, = I now believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March.. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Why a new group? I think that the OAuth working group should = remain focused on extending, patching, and adapting OAuth 2.0 to a = changing world. I plan to be engaged in both groups, and I know most of = you are as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> I=E2=80=99ve published a blog post detailing more of my = rationale: >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> = https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? = >>>>>> =20 >>>>>>=20 >>>>>> Please suggest changes to the proposed charter text above. It=E2=80= =99s my hope that we can get the chartering process started. >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> =E2=80=94 Justin >>>>>>=20 >>>>>> --=20 >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>>> --=20 >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 --Apple-Mail=_21D647A4-7DCA-4C3A-84E0-AC1E2CBF0DC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99d argue that it=E2=80=99s actually essential that the complex = deployments don=E2=80=99t add complexity to the simple ones.

 =E2=80=94 = Justin

On Dec 27, 2019, at 1:16 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:

I concur with Annabelle. = Pretty much all large systems have a clear separation between different = functions to provide resiliency and improved security (separation of = duties)

Ideally we = can do this without adding complexity for deployments that don't require = it.


On Sun, Dec = 22, 2019 at 8:52 PM Richard Backman, Annabelle <richanna@amazon.com>= wrote:
My example demonstrates an architecture = where the TX Endpoint, authentication system, and token issuer aren=E2=80=99= t simply different micro services, they=E2=80=99re completely = independent systems in different trust boundaries, possibly have different domains and different keys. = This has implications for protocol design. For example, it would no = longer be sufficient to have a single jwks_uri, as OAuth 2.0 has.

If we want to support = this kind of =E2=80=9Cdecomposed AS=E2=80=9D model, then we need to make = sure that=E2=80=99s supported by the charter and keep it in mind as we = design the protocol. We can also decide it is out of scope, but we should be intentional about that decision.

To my mind, this role decomposition is the = next logical step after the channel decomposition that TxAuth already = does. I see a lot of potential in it and think we should at minimum = avoid closing the door on it.

On Dec 22, 2019, at 5:35 PM, Justin = Richer <jricher@mit.edu> wrote:

=EF=BB=BF I think you=E2=80=99re conflating = the roles that different components play, in = regard to the other components, with the potential deployment of those = components. The spec needs to be written in terms of the roles. While = the roles do need to consider what potential deployments might be, it=E2=80=99s = important that we write things in in terms of how they interact with = each other and not in terms of how they might look under the covers.

So from the clients perspective, the TX Endpoint :is: = the AS. The client doesn=E2=80=99t care that it=E2=80=99s a =E2=80=9Cglori= fied message queue=E2=80=9D or if it=E2=80=99s a massive server farm. = The client doesn=E2=80=99t care if there=E2=80=99s a TLS reverse proxy = or if it=E2=80=99s talking directly to the application layer. The only thing the client cares about is if the = TX Endpoint does the things that a TX Endpoint is supposed to do, and we = define that to be the function of the AS. 

What=E2=80=99s important in your scenario below is that = the client would have to talk to the RS first every time. That=E2=80=99s = one of the problems that UMA has, and I think something we should avoid. = I think RS-first is an interesting pattern but AS-first ought to drive this. 

With your hypothetical layout below, it really sounds = like the TX Endpoint is a function of the IDP, which is fine. The client = doesn=E2=80=99t care that it=E2=80=99s deployed using some externalized = cloud service. The only weird thing going on is the push from the AS back to the client. The client would need to register that with = the AS (or through the AS more specifically) as part of its transaction = request. This would be part of its interaction mechanism, because =E2=80=9C= how you get messages and updates back to the client=E2=80=9D is part of the interaction model. 

So for an RS-first transaction, the client calls the = RS:

GET /foo

The RS returns a resource handle, but the client = doesn=E2=80=99t care where that came from. The RS could talk to the AS = to get it. Probably a new endpoint of some kind, can probably use the = same kinds of key binding that the TX Endpoint has. Or the RS can make one up that the TX Endpoint can recognize. Or it calls the IdP = to get one. The client doesn=E2=80=99t care, and that=E2=80=99s the key = point. 

WWW-Authenticate tx_endpoint=3D=E2=80=9Chttp://server//tx=E2=80=9D resource: =E2=80=9Casdf1234=E2=80= =9D

The client calls the TX endpoint like a normal = transaction:

POST /tx

{
  resources: [ =E2=80=9Casdf1234=E2=80=9D ],
  interact: {
    redirect: true,
    push: =E2=80=9Chttp://client/push/9876=E2=80=9D
  }
}

The AS (which is to say the TX Endpoint) tells the = client to send the user agent to the IdP

{
  interact_url: =E2=80=9Chttp://idp/login=E2=80=9D,
  handle: { value: =E2=80=9Chjkl=E2=80=9D, type: = bearer }
}

Now the client could poll the TX Endpoint but it could = also just sit and wait for an update to be pushed in. 

There are probably things that need to be tied together = for this to be secure, but I think the basic pattern still fits. = Importantly, the client doesn=E2=80=99t care whereby of that stuff came = from =E2=80=94 as far as it=E2=80=99s concerned, it=E2=80=99s talking to = the AS. 

Remember, the =E2=80=9CAS=E2=80=9D is a logical = construct, not a physical one. Just like the =E2=80=9Cclient=E2=80=9D = could be a cluster of applications and the =E2=80=9CRS=E2=80=9D could be = a suite of APIs tied behind a gateway.

 =E2=80=94 Justin


On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle = <richanna@amazon.com> wrote:


On Dec 21, 2019, at 4:42 AM, Justin = Richer <jricher@mit.edu> wrote:

Even if the client starts at the RS, the client still = has to go talk to the AS. I haven=E2=80=99t built this out, but I see it = working somewhat like UMA. In XYZ=E2=80=99s terms:


1. Client calls the RS trying to Do A Thing
2. RS calls the AS requesting a Resource Handle (because = that=E2=80=99s what the RS represents, resources) =E2=80=94 at least = good enough to cover what the client tried to do, could be more
3. RS gives the Resource Handle and AS Transaction = Endpoint back to the client
4. Client calls the AS Transaction Endpoint to start a = transaction, includes the Resource Handle as part of its request (note: = doesn=E2=80=99t have to be the whole resource section, client can add = stuff)
5. Process continues as normal

It depends on what you consider the =E2=80=9CAS=E2=80=9D. = Consider the following hypothetical architecture:

=E2=80=A2 The RS, client, and tx endpoint are on the = public Internet.
=E2=80=A2 The tx endpoint returns interaction urls that = point to an IdP that is inaccessible from the public Internet.
=E2=80=A2 The user agent can reach the IdP, but none of = the other systems can.
=E2=80=A2 When the UA is redirected to the IdP, the IdP = calls the tx endpoint system to retrieve transaction details.
=E2=80=A2 When authorization is granted, the IdP pushes = artifacts directly to an endpoint provided by the client.

In this example, the client only interacts with the RS = and the tx endpoint. It seems odd to me to consider the system hosting = the tx endpoint to be the AS (or at least part of the AS), as its a = glorified message queue with essentially no authority in this architecture. 

We could go a step further and remove the client=E2=80=99s= interaction with the tx endpoint by having the RS return the = interaction url directly (you=E2=80=99d need to secure the client nonce = if you want to hide it from the RS, but that=E2=80=99s not that = hard).

Is the meaning of =E2=80=9Cauthorization server=E2=80=9D = (or the phrase =E2=80=9Cthrough an authorization server=E2=80=9D) = flexible enough to accommodate these cases? Or are they considered out = of scope for TxAuth?

 =E2=80=94 Justin


As I said, maybe I=E2=80=99m being too literal.

3D""=E1=90=A7
On Fri, Dec 20, 2019 at 5:08 PM = Richard Backman, Annabelle <richanna@amazon.com> wrote:

I=E2=80=99m not sure if this is = what Eve had in mind, but consider an automated system in an enterprise = context that has been authorized by an administrator. The automated = system isn=E2=80=99t acting as or on behalf of the administrator, and = the administrator hasn=E2=80=99t =E2=80=9Cdelegated access=E2=80=9D; they=E2=80=99ve granted access, just as they do when they assign = permissions to users/groups/roles/etc.

Maybe I=E2=80=99m being too = literal, but =E2=80=9Cthrough an authorization server=E2=80=9D in = paragraph 1 implies a specific context/information/request flow to me. = Given that one of TxAuth=E2=80=99s features is decoupling the different = communication channels, we should not suggest that the client or authorizing party is directly = interacting with the AS.

 

=E2=80=93 

Annabelle Richard Backman

AWS Identity

 

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Dick Hardt = <dick.hardt@gmail.com>
Date: Friday, December 20, 2019 at 4:14 PM
To: Eve Maler <eve@xmlgrrl.com>
Cc: "rdd@cert.org" <rdd@cert.org>, "txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jricher@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: [Txauth] TxAuth Proposed Charter

 

Eve: do you not think the = software client is acting on behalf of some party? Or do you think that = software always is acting on behalf of some party, and the mentioned = phrase is redundant?

 

Justin: a couple questions

 

1. What is meant by "Delegation = between multiple users" ?

 

2. Why do you restrict this to = HTTP?

 

3. Why is authentication not in = scope?

 

4. When you say "not backwards = compatible with OAuth 2.0 and its extensions", do you expect to define a = new standard to replace RFC 6750? Developers will have to have a new = method to call APIs?

 

 

On Fri, Dec 20, 2019 at 3:27 PM = Eve Maler <eve@xmlgrrl.com> wrote:

Re = =E2=80=9Cto a software = client _acting on behalf of an authorizing party_=E2=80=9D: There is a = whole lot of philosophy behind whom the delegated access is performed on = behalf of, unless the scenario is single-user or some "act as" semantic = is spelled out on the wire. Does it need to be stated here? What's the = consequence if the highlighted phrase were removed? 

Eve Maler (sent from my iPad) | cell +1 425 345 = 6756



On Dec 20, 2019, at = 4:34 PM, Justin Richer <jricher@mit.edu> wrote:

Hi all,

 

As discussed in Singapore, no = matter what forum TxAuth takes, its work will require a new charter. = With that in mind, I=E2=80=99ve taken a bit of time to put together a = proposed charter text for the TxAuth work:

 

This group is chartered to = develop a next-generation transactional authorization and delegation = protocol for HTTP-based APIs and their clients. These transactions will = allow an authorizing party to delegate a right of access for an API or set of APIs through an authorization server to a software client = acting on behalf of an authorizing party. 

 

The group will deliver a protocol = specification detailing how a client can request and obtain delegated = access, how an authorization server can provide delegated access, how an = authorized party can authorize delegated access, and how that authorized access can be communicated to the resources being protected. = These actions will be connected through an explicit transaction between = the client and authorization server, resulting in an artifact that will = allow the client to undertake the delegated action. 

 

Additionally, the delegation = process will allow for:

- Fine-grained specification of = resource access

- Delegation between multiple = users

- Web, mobile, single-page, and = other client applications

 

The group will define extension = points for this protocol to allow for flexibility in areas including:

 

- Cryptographic agility for keys, = message signatures, and proof of possession 

- User interaction mechanisms = including web and non-web methods

- Token presentation mechanisms = and key bindings

 

The artifacts for this work are = not intended or expected to be backwards-compatible with OAuth 2.0 and = its extensions. 

 

While this work could be done in = within the OAuth working group, I now believe that it should be done in = a new working group, and that we should try to get that working group up = and running prior to the Vancouver meeting in March.. I think this group should stay here on the TxAuth list, and it=E2=80=99s my = suggestion that the resulting work be called OAuth 3.0. 

 

Why a new group? I think that the = OAuth working group should remain focused on extending, patching, and = adapting OAuth 2.0 to a changing world. I plan to be engaged in both = groups, and I know most of you are as well, but that=E2=80=99s not = universal. Since OAuth 2.0 is so established already, there are a LOT of people = who aren=E2=80=99t going to be interested in something new any time = soon. But on the other hand, there are a number of people for whom OAuth = 2.0 does not work, or is at the very least a poor fit, and we=E2=80=99ll want to bring them in at this early stage. So even = with significant overlap, I think there=E2=80=99s enough disconnect in = the community from both sides that warrants a new group. In addition, I = think this is a big enough piece of work that it=E2=80=99s simply too much for the OAuth working group to be able to focus on. We wouldn=E2=80=99= t be able to get additional meeting time, and OAuth already has trouble = fitting into its two meeting slots as it is.

 

I=E2=80=99ve published a blog = post detailing more of my rationale:

 

https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a= -new-working-group-d6229ba8e36?

 

Please suggest changes to the = proposed charter text above. It=E2=80=99s my hope that we can get the = chartering process started.

 

 =E2=80=94 Justin

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth




= --Apple-Mail=_21D647A4-7DCA-4C3A-84E0-AC1E2CBF0DC6-- From nobody Sat Dec 28 09:17:19 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9550120131 for ; Sat, 28 Dec 2019 09:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 aahbb_d-fSJu for ; Sat, 28 Dec 2019 09:17:14 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 C7618120130 for ; Sat, 28 Dec 2019 09:17:13 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBSHH99t031160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 28 Dec 2019 12:17:10 -0500 From: Justin Richer Message-Id: <68CA5C79-10AB-42E6-B4A9-06A594CA436C@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_5F41FD35-DE6C-4E38-83DF-C49676AC8220" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 28 Dec 2019 12:17:08 -0500 In-Reply-To: Cc: Eve Maler , "rdd@cert.org" , txauth@ietf.org, Benjamin Kaduk To: Dick Hardt References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <07AEE8DB-A0EE-4780-9CE7-B578F69948F9@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 17:17:18 -0000 --Apple-Mail=_5F41FD35-DE6C-4E38-83DF-C49676AC8220 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> 1. What is meant by "Delegation between multiple users=E2=80=9D ? >=20 > See above. >=20 > I still don't understand. Is one user delegating to another user? This = is a desirable use case for many, but currently not standardized. Is = this what you are proposing is in scope? > =20 I=E2=80=99m proposing that in our model, the person using the client = application and the person approving the process can be different = parties, depending on the nature of interaction that the client is = capable of. Again, this goes into the different roles that people play. = I do think that this is in scope, with the condition that in the case = where they=E2=80=99r the same person (IE, the OAuth case), this = collapses cleanly into a simpler case. UMA doesn=E2=80=99t do that very = well, because of the nature of OAuth=E2=80=99s redirect-first model. We = can do better here. >=20 >>=20 >> 2. Why do you restrict this to HTTP? >=20 > Because I want us to use all of the features and benefits of HTTP = instead of having to invent within-protocol functions to replicate them. = I don=E2=80=99t want SOAP, which pretends to be transport agnostic much = to its detriment. If someone wants to do OAuth 3 on not-HTTP, they can = define what that looks like. This is what happened with the COAP/CORE = stuff and OAuth 2. >=20 > I agree SOAP was complicated. Which features and benefits of HTTP are = you wanting to use?=20 >=20 Well so far we=E2=80=99ve got headers, URLs, methods, data payload = types, and the whole array of technologies that we can rely on working = together along with HTTP. > If it was simple to support COAP, why would we not do that? Because it=E2=80=99s not just COAP =E2=80=94 you=E2=80=99ve got a = different set of assumptions for the lower layer protocols, and you=E2=80=99= ve got lots of considerations about how the different components can = talk to each other in the embedded space.=20 In my experience, it=E2=80=99s much more successful to have a protocol = strongly integrated with its transport mechanism and then translated out = to other mechanisms, instead of trying to come up with one universal = interlingua of a protocol that just get shunted along. This is why SOAP = can=E2=80=99t use HTTP verbs to communicate things, and why the only = signatures it can use are internal. When you do that kind of system, you = almost always end up having people just use it with one transport = anyway, like SOAP over HTTP. > =20 >=20 >>=20 >> 3. Why is authentication not in scope? >=20 > It felt, to me, like that might be a bridge too far. >=20 > I disagree. But I also think that authentication is the wrong term. = Identity* may be a term that maps better, as the Client is wanting to = get "identity" data from the AS.=20 >=20 > * The identity term is super confusing, but authentication implies = just knowing it is the same user, where OpenID Connect also provides = claims about the user. I=E2=80=99m coming around to this view, but I would still like it to be = separate. > =20 > If we do decide it=E2=80=99s in scope, then I think it should be = clearly layered on top of the authorization layer.=20 >=20 > Being layered on top is confusing. An OpenID Connect flow where the = Client receives an ID token, has not authorization, unless you are = counting the UX as authorization -- but that does not seem like a layer. = Would you elaborate? > =20 What you=E2=80=99re doing in OIDC is authorizing the application to know = who you are =E2=80=94 to get your identity information. That key insight = is what makes the combination of OAuth and OIDC work as well as it does. = And, importantly, once you authorize identity access, you can authorize = other stuff as well. And it=E2=80=99s the =E2=80=9Cand other stuff=E2=80=9D= that people really, really, really like about OIDC. Nobody ever wants = just authorization, in practice.=20 >=20 >>=20 >> 4. When you say "not backwards compatible with OAuth 2.0 and its = extensions", do you expect to define a new standard to replace RFC 6750? = Developers will have to have a new method to call APIs? >=20 > Kinda. First, it=E2=80=99s more 6749 that I want to step away from. = But even then, I think keeping just the header version of 6750 is OK = enough if someone wants to keep using that. The thing is, won=E2=80=99t = someone seeing an OAuth 2 header assume the rest of OAuth 2 = infrastructure? In some cases this won=E2=80=99t matter, but in many = that could be really confusing.=20 >=20 > One of the problems, though, is that 6750 has already been clouded by = things like the MTLS binding, where they use =E2=80=9Cbearer=E2=80=9D = tokens that have to be bound to the client=E2=80=99s certificate. So =E2=80= =A6 not much of a bearer token anymore. >=20 > So, are you are you proposing that Tx have a new mechanism for API = calls? Yes, I think there will be new mechanisms for different kinds of = key-bound tokens. > =20 >=20 > Ultimately, I don=E2=80=99t want anything that has an = error-fallthrough compatibility process. That is to say, I try doing = OAuth 2, have that fail, and then try it as OAuth 3 =E2=80=94 or vice = versa. >=20 > Ok. I'm not even sure how that would happen, but ok. So in OAuth 2 the token parameter was originally called = =E2=80=9Coauth_token=E2=80=9D, which is the same as in OAuth 1. But the = difference is that in OAuth 2 there=E2=80=99s no = =E2=80=9Coauth_token_signature=E2=80=9D field, so to support both = you=E2=80=99d need to try to do OAuth 1, then fail, and then try to do = OAuth 2. Since the nature of the tokens is completely different, I see = that as a problem. However, with this (and with how XYZ=E2=80=99s started things), we=E2=80=99= ve got an opportunity to say things like =E2=80=9Cif you see this type = of token response, use it with the RS according to RFC6750=E2=80=9D or = =E2=80=9Caccording to this new RFC we just made up=E2=80=9D or whatever. >=20 > =20 >=20 > =E2=80=94 Justin >=20 >>=20 >>=20 >> On Fri, Dec 20, 2019 at 3:27 PM Eve Maler > wrote: >> Re =E2=80=9Cto a software client _acting on behalf of an authorizing = party_=E2=80=9D: There is a whole lot of philosophy behind whom the = delegated access is performed on behalf of, unless the scenario is = single-user or some "act as" semantic is spelled out on the wire. Does = it need to be stated here? What's the consequence if the highlighted = phrase were removed?=20 >>=20 >> Eve Maler (sent from my iPad) | cell +1 425 345 6756 >>=20 >>> On Dec 20, 2019, at 4:34 PM, Justin Richer > wrote: >>>=20 >>> =EF=BB=BFHi all, >>>=20 >>> As discussed in Singapore, no matter what forum TxAuth takes, its = work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of time to put together a proposed charter text for the TxAuth work: >>>=20 >>> This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 >>>=20 >>> The group will deliver a protocol specification detailing how a = client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>>=20 >>> Additionally, the delegation process will allow for: >>> - Fine-grained specification of resource access >>> - Delegation between multiple users >>> - Web, mobile, single-page, and other client applications >>>=20 >>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>=20 >>> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >>> - User interaction mechanisms including web and non-web methods >>> - Token presentation mechanisms and key bindings >>>=20 >>> The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >>>=20 >>> While this work could be done in within the OAuth working group, I = now believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March.. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>>=20 >>> Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing = world. I plan to be engaged in both groups, and I know most of you are = as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>>=20 >>> I=E2=80=99ve published a blog post detailing more of my rationale: >>>=20 >>> = https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-workin= g-group-d6229ba8e36? = >>>=20 >>> Please suggest changes to the proposed charter text above. It=E2=80=99= s my hope that we can get the chartering process started. >>>=20 >>> =E2=80=94 Justin >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_5F41FD35-DE6C-4E38-83DF-C49676AC8220 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
1. What is meant by "Delegation between = multiple users=E2=80=9D ?

See = above.

I still don't understand. Is one user = delegating to another user? This is a desirable use case for many, but = currently not standardized. Is this what you are proposing is in = scope?
 

I=E2=80=99m proposing that in our model, the = person using the client application and the person approving the process = can be different parties, depending on the nature of interaction that = the client is capable of. Again, this goes into the different roles that = people play. I do think that this is in scope, with the condition that = in the case where they=E2=80=99r the same person (IE, the OAuth case), = this collapses cleanly into a simpler case. UMA doesn=E2=80=99t do that = very well, because of the nature of OAuth=E2=80=99s redirect-first = model. We can do better here.



2. Why do you restrict this to = HTTP?

Because I want us to use all of the = features and benefits of HTTP instead of having to invent = within-protocol functions to replicate them. I don=E2=80=99t want SOAP, = which pretends to be transport agnostic much to its detriment. If = someone wants to do OAuth 3 on not-HTTP, they can define what that looks = like. This is what happened with the COAP/CORE stuff and OAuth = 2.

I agree SOAP was complicated. Which features and benefits of = HTTP are you wanting to use? 


Well so far we=E2=80=99ve got headers, URLs, = methods, data payload types, and the whole array of technologies that we = can rely on working together along with HTTP.


If it was simple to support COAP, why would we not do = that?

Because it=E2=80=99s not just COAP =E2=80=94 = you=E2=80=99ve got a different set of assumptions for the lower layer = protocols, and you=E2=80=99ve got lots of considerations about how the = different components can talk to each other in the embedded = space. 

In my experience, = it=E2=80=99s much more successful to have a protocol strongly integrated = with its transport mechanism and then translated out to other = mechanisms, instead of trying to come up with one universal interlingua = of a protocol that just get shunted along. This is why SOAP can=E2=80=99t = use HTTP verbs to communicate things, and why the only signatures it can = use are internal. When you do that kind of system, you almost always end = up having people just use it with one transport anyway, like SOAP over = HTTP.

 


3. Why is authentication not in = scope?

It felt, to me, like that might be a = bridge too far.

I disagree. But I also think that = authentication is the wrong term. Identity* may be a term that maps = better, as the Client is wanting to get "identity" data from the = AS. 

* = The identity term is super confusing, but authentication implies just = knowing it is the same user, where OpenID Connect also provides claims = about the user.

I=E2=80=99m coming around to this view, but I = would still like it to be separate.

 
If we do decide = it=E2=80=99s in scope, then I think it should be clearly layered on top = of the authorization layer. 

Being layered on top is = confusing. An OpenID Connect flow where the Client receives an ID token, = has not authorization, unless you are counting the UX as authorization = -- but that does not seem like a layer. Would you elaborate?
 

What you=E2=80=99re doing in OIDC is authorizing = the application to know who you are =E2=80=94 to get your identity = information. That key insight is what makes the combination of OAuth and = OIDC work as well as it does. And, importantly, once you authorize = identity access, you can authorize other stuff as well. And it=E2=80=99s = the =E2=80=9Cand other stuff=E2=80=9D that people really, really, really = like about OIDC. Nobody ever wants just authorization, in = practice. 



4. When you say "not backwards compatible with OAuth 2.0 and = its extensions", do you expect to define a new standard to replace RFC = 6750? Developers will have to have a new method to call = APIs?

Kinda. First, it=E2=80=99s more 6749 = that I want to step away from. But even then, I think keeping just the = header version of 6750 is OK enough if someone wants to keep using that. = The thing is, won=E2=80=99t someone seeing an OAuth 2 header assume the = rest of OAuth 2 infrastructure? In some cases this won=E2=80=99t matter, = but in many that could be really confusing. 
One of the problems, though, is that = 6750 has already been clouded by things like the MTLS binding, where = they use =E2=80=9Cbearer=E2=80=9D tokens that have to be bound to the = client=E2=80=99s certificate. So =E2=80=A6 not much of a bearer token = anymore.

So, are you are you proposing that Tx = have a new mechanism for API = calls?

Yes, I think there will be new mechanisms for = different kinds of key-bound tokens.

 

Ultimately, I don=E2=80=99t want = anything that has an error-fallthrough compatibility process. That is to = say, I try doing OAuth 2, have that fail, and then try it as OAuth 3 =E2=80= =94 or vice versa.

Ok. I'm not even sure how that would = happen, but ok.

So in OAuth 2 the token parameter was originally = called =E2=80=9Coauth_token=E2=80=9D, which is the same as in OAuth 1. = But the difference is that in OAuth 2 there=E2=80=99s no = =E2=80=9Coauth_token_signature=E2=80=9D field, so to support both = you=E2=80=99d need to try to do OAuth 1, then fail, and then try to do = OAuth 2. Since the nature of the tokens is completely different, I see = that as a problem.

However, with = this (and with how XYZ=E2=80=99s started things), we=E2=80=99ve got an = opportunity to say things like =E2=80=9Cif you see this type of token = response, use it with the RS according to RFC6750=E2=80=9D or = =E2=80=9Caccording to this new RFC we just made up=E2=80=9D or = whatever.



 

 =E2=80=94 Justin



On Fri, Dec = 20, 2019 at 3:27 PM Eve Maler <eve@xmlgrrl.com> wrote:
Re = =E2=80=9Cto = a software client _acting on behalf of an authorizing party_=E2=80=9D: = There is a whole lot of philosophy behind whom the delegated access is = performed on behalf of, unless the scenario is single-user or some "act = as" semantic is spelled out on the wire. Does it need to be stated here? = What's the consequence if the highlighted phrase were = removed? 

Eve = Maler (sent from my iPad) | cell +1 425 345 6756

On Dec = 20, 2019, at 4:34 PM, Justin Richer <jricher@mit.edu> wrote:

=EF=BB=BFHi all,
As discussed in Singapore, no matter = what forum TxAuth takes, its work will require a new charter. With that = in mind, I=E2=80=99ve taken a bit of time to put together a proposed = charter text for the TxAuth work:

This group is = chartered to develop a next-generation transactional authorization and = delegation protocol for HTTP-based APIs and their clients. These = transactions will allow an authorizing party to delegate a right of = access for an API or set of APIs through an authorization server to a = software client acting on behalf of an authorizing = party. 

The= group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can = provide delegated access, how an authorized party can authorize = delegated access, and how that authorized access can be communicated to = the resources being protected. These actions will be connected through = an explicit transaction between the client and authorization server, = resulting in an artifact that will allow the client to undertake the = delegated action. 

Additionally, the delegation process will allow = for:
- Fine-grained specification of resource = access
- Delegation between multiple = users
- Web, mobile, single-page, and other client = applications

The= group will define extension points for this protocol to allow for = flexibility in areas including:

- Cryptographic agility for keys, = message signatures, and proof of possession 
- = User interaction mechanisms including web and non-web methods
- Token presentation mechanisms and key bindings

The artifacts for this = work are not intended or expected to be backwards-compatible with OAuth = 2.0 and its extensions. 

While this work could be done in within = the OAuth working group, I now believe that it should be done in a new = working group, and that we should try to get that working group up and = running prior to the Vancouver meeting in March.. I think this group = should stay here on the TxAuth list, and it=E2=80=99s my suggestion that = the resulting work be called OAuth 3.0. 

Why a new group? I think that the OAuth = working group should remain focused on extending, patching, and adapting = OAuth 2.0 to a changing world. I plan to be engaged in both groups, and = I know most of you are as well, but that=E2=80=99s not universal. Since = OAuth 2.0 is so established already, there are a LOT of people who = aren=E2=80=99t going to be interested in something new any time soon. = But on the other hand, there are a number of people for whom OAuth 2.0 = does not work, or is at the very least a poor fit, and we=E2=80=99ll = want to bring them in at this early stage. So even with significant = overlap, I think there=E2=80=99s enough disconnect in the community from = both sides that warrants a new group. In addition, I think this is a big = enough piece of work that it=E2=80=99s simply too much for the OAuth = working group to be able to focus on. We wouldn=E2=80=99t be able to get = additional meeting time, and OAuth already has trouble fitting into its = two meeting slots as it is.

I=E2=80=99ve published a blog post detailing more of my = rationale:

https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a= -new-working-group-d6229ba8e36?

Please suggest changes to the proposed = charter text above. It=E2=80=99s my hope that we can get the chartering = process started.

 =E2=80=94 Justin
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=


= --Apple-Mail=_5F41FD35-DE6C-4E38-83DF-C49676AC8220-- From nobody Sat Dec 28 09:20:11 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF470120131 for ; Sat, 28 Dec 2019 09:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 nGKW4eRSCSyZ for ; Sat, 28 Dec 2019 09:20:08 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CB087120130 for ; Sat, 28 Dec 2019 09:20:07 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBSHK5Jn031667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 28 Dec 2019 12:20:05 -0500 From: Justin Richer Message-Id: <8A6A7A34-707E-49A2-9A20-5EC4BBC3D181@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_F51B7530-33F8-486D-A0CA-A07229EBAE8B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 28 Dec 2019 12:20:05 -0500 In-Reply-To: Cc: "txauth@ietf.org" To: Dick Hardt References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] RS initiated Tx (was: TxAuth Proposed Charter) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2019 17:20:10 -0000 --Apple-Mail=_F51B7530-33F8-486D-A0CA-A07229EBAE8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 27, 2019, at 1:01 PM, Dick Hardt wrote: >=20 > (changed topic as it is about Justin's proposal on having RS initiate = Txx >=20 > On Sat, Dec 21, 2019 at 4:41 AM Justin Richer > wrote: > > Even if the client starts at the RS, the client still has to go talk = to the AS. I haven=E2=80=99t built this out, but I see it working = somewhat like UMA. In XYZ=E2=80=99s terms: >=20 >=20 > 1. Client calls the RS trying to Do A Thing > 2. RS calls the AS requesting a Resource Handle (because that=E2=80=99s = what the RS represents, resources) =E2=80=94 at least good enough to = cover what the client tried to do, could be more > 3. RS gives the Resource Handle and AS Transaction Endpoint back to = the client > 4. Client calls the AS Transaction Endpoint to start a transaction, = includes the Resource Handle as part of its request (note: doesn=E2=80=99t= have to be the whole resource section, client can add stuff) > 5. Process continues as normal >=20 > Why do you want the RS to request from the AS? This would require the = RS to have credentials known to the AS. Yes, I would picture the RS in this case having its own key to protect = this call. It would also use that key to do introspection style calls. >=20 > Why not have the RS provide information about what the Client needs to = ask the AS for, and which AS it is? >=20 If the RS can do that in a way that the AS can understand, without = talking to the AS, then it can do that. It could be pre-configured (like = an HTTP Auth Realm) or it could come from some internal calculation that = the AS can verify. The client ultimately doesn=E2=80=99t care =E2=80=94 = from its perspective, it gets a resource handle that=E2=80=99s at least = good enough to do the thing it=E2=80=99s trying to do at the RS, and an = AS pointer (the transaction endpoint URL). Everything else flows out = from those bits of information. I think there=E2=80=99s a lot of value in having the RS be able to = request, at runtime, a dynamic resource handle that the client can = present to the AS. That=E2=80=99s a difference for the RS though, not = the client. =E2=80=94 Justin= --Apple-Mail=_F51B7530-33F8-486D-A0CA-A07229EBAE8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 27, 2019, at 1:01 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

(changed topic as = it is about Justin's proposal on having RS initiate Txx

On Sat, Dec 21, 2019 at 4:41 AM Justin Richer = <jricher@mit.edu> = wrote:
<snip>
Even if the = client starts at the RS, the client still has to go talk to the AS. I = haven=E2=80=99t built this out, but I see it working somewhat like UMA. = In XYZ=E2=80=99s terms:


1. Client calls the RS = trying to Do A Thing
2. RS calls the AS requesting = a Resource Handle (because that=E2=80=99s what the RS represents, = resources) =E2=80=94 at least good enough to cover what the client tried = to do, could be more
3. RS gives the Resource = Handle and AS Transaction Endpoint back to the client
4. Client calls the AS Transaction Endpoint to start a = transaction, includes the Resource Handle as part of its request (note: = doesn=E2=80=99t have to be the whole resource section, client can add = stuff)
5. Process continues as = normal

Why do you want the RS to request from = the AS? This would require the RS to have credentials known to the = AS.

Yes, I would picture the RS in this case having = its own key to protect this call. It would also use that key to do = introspection style calls.


Why not have the RS provide information about what the Client = needs to ask the AS for, and which AS it is?


If the RS can do that in a way that the AS can = understand, without talking to the AS, then it can do that. It could be = pre-configured (like an HTTP Auth Realm) or it could come from some = internal calculation that the AS can verify. The client ultimately = doesn=E2=80=99t care =E2=80=94 from its perspective, it gets a resource = handle that=E2=80=99s at least good enough to do the thing it=E2=80=99s = trying to do at the RS, and an AS pointer (the transaction endpoint = URL). Everything else flows out from those bits of = information.

I think there=E2=80=99s = a lot of value in having the RS be able to request, at runtime, a = dynamic resource handle that the client can present to the AS. That=E2=80=99= s a difference for the RS though, not the client.

 =E2=80=94 Justin
= --Apple-Mail=_F51B7530-33F8-486D-A0CA-A07229EBAE8B-- From nobody Mon Dec 30 15:25:40 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91332120B3B for ; Mon, 30 Dec 2019 15:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 DEnxOzTCqWok for ; Mon, 30 Dec 2019 15:25:34 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268901200C1 for ; Mon, 30 Dec 2019 15:25:34 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id a13so34828253ljm.10 for ; Mon, 30 Dec 2019 15:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kj4DeWu3fLOESsoIRkm4Nt0GE+IW4aUtl0P1+WMbkRc=; b=e4QILjNBz5lUCiXhY/TH9YQdeqZzIEAh5f/g3S/RrD315l5odIcZGRGGaS1jCdj4Mt 6RixlfJsLJAotKXOBY09Q+PIeGDvtGLY0FBamBdwiD2HDDlDoyf5taDcTu4tY4Lgu9O2 cxxl4YTVSpTftM5X7N/SpnA7JeRLbWg67/gMlX+dpEFD914c72ntere18O2UwOgzwNX7 GHTgQ7JlfQYzVSAbMdpbOfY1C5z6ns69hGnQr8CFKx/H3ra8a/tZdF2JcDImIdJ18SxY DaRBzei1I/m+yN21gpxgQiEvYcbz8tgLxaT7QNE15fVI+HvstZfKH6cF7xcpxfz6/8ty Ep6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kj4DeWu3fLOESsoIRkm4Nt0GE+IW4aUtl0P1+WMbkRc=; b=ADfxQcflbClPph+SYdfWVX6fZRol2ujy9vpnkt/VmkmXVWvEqBdYzJTflnjPrcr3f6 nyxXYU5ZBA8rLv8rBmoAmm2gLGaWPHtZ4LHHbbL/muWdzeVJLU3FxUB8Qhp4XFNFfTtY AKpFPfwKc2PJPYuWyed28CLxJqVVCZEBRJ4Zkdk57b76OK3DrsxyQnyjsWpF4Y2/UFRI LMTEwnoyGEcIzuswQcTOeoZkBhQQi1KZRLvOJf+ZZSMjsB4tbGJqNRdr+FdwAlvg04G6 uS08ofeZqBdUvbUxcxG2Oiof1iDRcbkencDaLraqlu1eOTjmirKAUg424pabO6usAIZF CQig== X-Gm-Message-State: APjAAAXKtY/krkmsQ0tw3Hj7pgQUjHGCOzUygUbxJir9YK6p82ofCnma w0QrIkmJ6oSoQKlSCfJeQJIO10dW0zjNNFfShak= X-Google-Smtp-Source: APXvYqw0PwQbjeBHuI0TgoXIEpSjkdFwEFsDSxxoBrpxsCXtoUc8cJQIsTiRZIeFoqT9HKMNhgDUh2SwBhd4OOJUt9g= X-Received: by 2002:a2e:a48a:: with SMTP id h10mr40371042lji.254.1577748332202; Mon, 30 Dec 2019 15:25:32 -0800 (PST) MIME-Version: 1.0 References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> In-Reply-To: From: Dick Hardt Date: Mon, 30 Dec 2019 15:25:19 -0800 Message-ID: To: Justin Richer Cc: Brian Campbell , "rdd@cert.org" , Yaron Sheffer , Benjamin Kaduk , Aaron Parecki , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000e2d187059af428a9" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2019 23:25:38 -0000 --000000000000e2d187059af428a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I significant difference in this case is that OAuth 3 is NOT backward compatible with OAuth 2. HTTP 2 was backwards compatible, as is HTTP 3 from what I understand. This has enterprises question what they should do, and the safe answer is do nothing. I think this is what Brian was getting at on confusion. People are confused on what they should do. OAuth 3 not being backward compatible implies work done with OAuth 2 may have to be thrown away. On Sat, Dec 28, 2019 at 9:07 AM Justin Richer wrote: > This is going to be the case whatever we call this new work. Progress is > going to continue to happen, and if a large enterprise decides to wait fo= r > the new shiny thing 3 years from now, then that=E2=80=99s on them. > > In my experience, it=E2=80=99s more likely that a large enterprise is goi= ng to shy > away from the new shiny thing and go with what they can buy in a supporte= d > package off the shelf. And I think that=E2=80=99s the kind of timescale t= hat=E2=80=99s > going to drive most of the developers decisions around whether to track t= he > new work or use what=E2=80=99s out there =E2=80=94 they need to ask =E2= =80=9Cwhat do I need?=E2=80=9D And > =E2=80=9Cwhen do I need it?=E2=80=9D > > But these are :always: the questions that you need to ask when starting a > project and choosing technologies. > > I still contend that the name OAuth 3 does a better job at communicating > what=E2=80=99s going on here. > > =E2=80=94 Justin > > On Dec 27, 2019, at 1:27 PM, Dick Hardt wrote: > > I agree with Brian. Developers such as large enterprise customers are > going to be confused when they hear there is an OAuth 3 in the works. Som= e > will push pause on projects because they worry that it will be outdated > when it is released. They won't know which to deploy, even though OAuth 3 > is not available. > > Also, if what we are working on includes authentication / identity -- it > no longer is just delegated authorization > > See inline comments below. > > > On Tue, Dec 24, 2019 at 4:22 PM Justin Richer wrote: > >> Brian, I hear what you=E2=80=99re saying, but I disagree completely. >> >> Who would be confused by seeing a major revision to an existing protocol >> that worked in a different way and did the same things but also new thin= gs? >> That happens all the time. >> > > And it causes market confusion all the time. Conservative organizations > stop doing things when it is not clear what the future will be. > > >> >> Was there significant confusion between OAuth 1 and 2, enough to hamper >> adoption of either? For the people who deeply invested in OAuth 1 and >> didn=E2=80=99t need or want the OAuth 2 newness, they stuck with it (see= : twitter). >> > > Twitter stuck with OAuth 1 because they did not like bearer tokens. > > Yes, there was lots of confusion between OAuth 1 and 2. Erin did not want > what became OAuth 2 to be called OAuth because of the confusion. Hence it > was called WRAP early. The actual name of the WG is "Web Authorization > Protocol" > > > >> >> Was OpenID Connect a major disservice to OpenID 2? It was a disruption, >> for sure, but people transitioned where it made sense for them, and in m= any >> cases that took years of dual-deployment and transition. >> > > The work that was being done on OpenID 3 was killed because a large > platform company that starts with G did not want to confuse their custome= rs > about a new version. > > >> >> I see us walking along the same kind of path here, nearly a decade later= . >> That=E2=80=99s why I think OAuth 3 makes sense as a name for the output = of this >> work. Or at the very least, for the core delegation protocol portion of >> whatever we make. I think it sends the right message to implementers and >> developers: the community that knows and understands OAuth 2 is working = on >> the next version of that thing, so when it=E2=80=99s ready, maybe you sh= ould look >> at it. Until it=E2=80=99s done, and for a long time after, OAuth 2 is st= ill going >> to be there and be the right answer. >> > > I agree that people may be confused if it is called something else that > OAuth, but if it is broader than OAuth, then that is confusing as well. > > >> >> The name isn=E2=80=99t a hill I=E2=80=99m committed to dying alone on, b= ut I think it >> sends a :bad: message if we call it something new entirely. Namely, that= we >> think people :should: abandon the entire world of OAuth, all of its idea= s >> and implementations. That=E2=80=99s not what we=E2=80=99re doing with th= is design, it=E2=80=99s an >> evolution as I see things. And as an evolution, a new major revision num= ber >> makes sense. >> >> =E2=80=94 Justin >> >> On Dec 24, 2019, at 9:54 AM, Brian Campbell >> wrote: >> >> Naming any prospective resulting work here "OAuth 3.0" would >> significantly exacerbate confusion in the whole space and would be a maj= or >> disservice to the broader community. >> >> >> On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki wrote: >> >>> I definitely am not trying to discuss specifics of *how* authentication >>> should be included right now, but I just want to make sure it's include= d in >>> the charter so that we can actually talk about it and it won't be "out = of >>> scope" when we eventually do talk about the specifics. >>> >>> Aaron >>> >>> >>> >>> On Mon, Dec 23, 2019 at 1:51 PM Justin Richer wrote: >>> >>>> I=E2=80=99m fine with it being in charter but I do think it should be = a clearly >>>> separate layer, much like OIDC/Facebook Connect/GitHub Login/etc are w= ith >>>> OAuth today. In all of these the authorization is first, and I think t= hat=E2=80=99s >>>> the right pattern. So if we do take it on we=E2=80=99ll just need to b= e careful how >>>> it=E2=80=99s structured in with everything else. Otherwise, I think th= e >>>> authentication side can quickly overwhelm and drag down the authorizat= ion >>>> side. >>>> >>>> Good news: A lot of the additional stuff in OIDC is there to patch >>>> holes in core OAuth in a common fashion, and we=E2=80=99ll at least be= in a >>>> position to not have to do that again. >>>> >>>> >>>> =E2=80=94 Justin >>>> >>>> On Dec 22, 2019, at 10:46 PM, Aaron Parecki wrote: >>>> >>>> I do think authentication should be part of the charter from the >>>> outset. Frankly the fact that authentication is intentionally left out= of >>>> OAuth and has to be bolted on to the side via OpenID Connect is one of= the >>>> exact reasons people get confused about the whole space to begin with. >>>> >>>> It's a relatively minor addition to the existing proposed spec to make >>>> it useful as a minimum viable authentication solution, and I'd like to= see >>>> that be addressed at the beginning of this work. >>>> >>>> I think we can do this in a smart way and that authentication should b= e >>>> included in the charter. >>>> >>>> Aaron >>>> >>>> >>>> >>>> >>>> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer >>>> wrote: >>>> >>>>> Hi Justin, >>>>> >>>>> >>>>> >>>>> I think the charter should mention target use cases. For example, =E2= =80=9Call >>>>> use cases supported by OAuth 2 will be supported by the new protocol= =E2=80=9D or >>>>> =E2=80=9Cthe protocol will support at least use cases X and Y=E2=80= =9D. >>>>> >>>>> >>>>> >>>>> And given the importance of OIDC, we could say something like: =E2=80= =9CThe >>>>> protocol will allow future extension to support authentication, in an >>>>> analogous way to OpenID Connect. However authentication is explicitly= not >>>>> part of the initial scope.=E2=80=9D >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yaron >>>>> >>>>> >>>>> >>>>> *From: *Txauth on behalf of Justin Richer < >>>>> jricher@mit.edu> >>>>> *Date: *Saturday, December 21, 2019 at 00:34 >>>>> *To: * >>>>> *Cc: *"rdd@cert.org" , Benjamin Kaduk >>>>> *Subject: *[Txauth] TxAuth Proposed Charter >>>>> >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> >>>>> >>>>> As discussed in Singapore, no matter what forum TxAuth takes, its wor= k >>>>> will require a new charter. With that in mind, I=E2=80=99ve taken a b= it of time to >>>>> put together a proposed charter text for the TxAuth work: >>>>> >>>>> >>>>> >>>>> This group is chartered to develop a next-generation transactional >>>>> authorization and delegation protocol for HTTP-based APIs and their >>>>> clients. These transactions will allow an authorizing party to delega= te a >>>>> right of access for an API or set of APIs through an authorization se= rver >>>>> to a software client acting on behalf of an authorizing party. >>>>> >>>>> >>>>> >>>>> The group will deliver a protocol specification detailing how a clien= t >>>>> can request and obtain delegated access, how an authorization server = can >>>>> provide delegated access, how an authorized party can authorize deleg= ated >>>>> access, and how that authorized access can be communicated to the res= ources >>>>> being protected. These actions will be connected through an explicit >>>>> transaction between the client and authorization server, resulting in= an >>>>> artifact that will allow the client to undertake the delegated action= . >>>>> >>>>> >>>>> >>>>> Additionally, the delegation process will allow for: >>>>> >>>>> - Fine-grained specification of resource access >>>>> >>>>> - Delegation between multiple users >>>>> >>>>> - Web, mobile, single-page, and other client applications >>>>> >>>>> >>>>> >>>>> The group will define extension points for this protocol to allow for >>>>> flexibility in areas including: >>>>> >>>>> >>>>> >>>>> - Cryptographic agility for keys, message signatures, and proof of >>>>> possession >>>>> >>>>> - User interaction mechanisms including web and non-web methods >>>>> >>>>> - Token presentation mechanisms and key bindings >>>>> >>>>> >>>>> >>>>> The artifacts for this work are not intended or expected to be >>>>> backwards-compatible with OAuth 2.0 and its extensions. >>>>> >>>>> >>>>> >>>>> While this work could be done in within the OAuth working group, I no= w >>>>> believe that it should be done in a new working group, and that we sh= ould >>>>> try to get that working group up and running prior to the Vancouver m= eeting >>>>> in March. I think this group should stay here on the TxAuth list, and= it=E2=80=99s >>>>> my suggestion that the resulting work be called OAuth 3.0. >>>>> >>>>> >>>>> >>>>> Why a new group? I think that the OAuth working group should remain >>>>> focused on extending, patching, and adapting OAuth 2.0 to a changing = world. >>>>> I plan to be engaged in both groups, and I know most of you are as we= ll, >>>>> but that=E2=80=99s not universal. Since OAuth 2.0 is so established a= lready, there >>>>> are a LOT of people who aren=E2=80=99t going to be interested in some= thing new any >>>>> time soon. But on the other hand, there are a number of people for wh= om >>>>> OAuth 2.0 does not work, or is at the very least a poor fit, and we= =E2=80=99ll want >>>>> to bring them in at this early stage. So even with significant overla= p, I >>>>> think there=E2=80=99s enough disconnect in the community from both si= des that >>>>> warrants a new group. In addition, I think this is a big enough piece= of >>>>> work that it=E2=80=99s simply too much for the OAuth working group to= be able to >>>>> focus on. We wouldn=E2=80=99t be able to get additional meeting time,= and OAuth >>>>> already has trouble fitting into its two meeting slots as it is. >>>>> >>>>> >>>>> >>>>> I=E2=80=99ve published a blog post detailing more of my rationale: >>>>> >>>>> >>>>> >>>>> >>>>> https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-= working-group-d6229ba8e36? >>>>> >>>>> >>>>> >>>>> >>>>> Please suggest changes to the proposed charter text above. It=E2=80= =99s my >>>>> hope that we can get the chartering process started. >>>>> >>>>> >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> -- Txauth mailing list Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> -- >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>> -- >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> @aaronpk >>>> >>>> >>>> -- >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > --000000000000e2d187059af428a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I significant difference in this case is that OAuth 3 is N= OT backward compatible with OAuth 2.

HTTP 2 was backward= s compatible, as is HTTP 3 from what I understand.

This has enterprises question what they should do, and the safe answer is = do nothing. I think this is what Brian was getting at on confusion. People = are confused on what they should do. OAuth 3 not being backward compatible = implies work done with OAuth 2 may have to be thrown away.


On Sat, Dec 28, 2019 at 9:07 AM Justin Richer <jricher@mit.edu> wrote:
This= is going to be the case whatever we call this new work. Progress is going = to continue to happen, and if a large enterprise decides to wait for the ne= w shiny thing 3 years from now, then that=E2=80=99s on them.=C2=A0

=
In my experience, it=E2=80=99s more likely that a large enterpri= se is going to shy away from the new shiny thing and go with what they can = buy in a supported package off the shelf. And I think that=E2=80=99s the ki= nd of timescale that=E2=80=99s going to drive most of the developers decisi= ons around whether to track the new work or use what=E2=80=99s out there = =E2=80=94 they need to ask =E2=80=9Cwhat do I need?=E2=80=9D And =E2=80=9Cw= hen do I need it?=E2=80=9D

But these are :always: = the questions that you need to ask when starting a project and choosing tec= hnologies.=C2=A0

I still contend that the name OAu= th 3 does a better job at communicating what=E2=80=99s going on here.
=

=C2=A0=E2=80=94 Justin

On Dec 27, 2019, at 1:27 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I agree wit= h Brian. Developers such as large enterprise customers are going=C2=A0to be= confused when they hear there is an OAuth 3 in the works. Some will push p= ause on projects because they worry that it will be outdated when it is rel= eased. They won't know which to deploy, even though OAuth 3 is not avai= lable.=C2=A0

Also, if what we are working on includes au= thentication / identity -- it no longer is just delegated authorization
=

See inline comments below.


On Tue, Dec 24, 2019 at 4:22 PM Justin Richer <= ;jricher@mit.edu&g= t; wrote:
B= rian, I hear what you=E2=80=99re saying, but I disagree completely.
Who would be confused by seeing a major revision to an existing= protocol that worked in a different way and did the same things but also n= ew things? That happens all the time.

And it causes market confusion all the time. Conservative organizati= ons stop doing things when it is not clear what the future will be.
=C2=A0
=
Was there significant confusion between OAuth 1 and 2, enoug= h to hamper adoption of either? For the people who deeply invested in OAuth= 1 and didn=E2=80=99t need or want the OAuth 2 newness, they stuck with it = (see: twitter).=C2=A0

Twitter s= tuck with OAuth 1 because they did not like bearer tokens.=C2=A0
=
Yes, there was lots of confusion between OAuth 1 and 2. Erin= did not want what became OAuth 2 to be called OAuth because of the confusi= on. Hence it was called WRAP early. The actual name of the WG is "Web = Authorization Protocol"

=C2=A0

Was OpenI= D Connect a major disservice to OpenID 2? It was a disruption, for sure, bu= t people transitioned where it made sense for them, and in many cases that = took years of dual-deployment and transition.=C2=A0

The work that was being done on OpenID 3 was killed be= cause a large platform company that starts with G did not want to confuse t= heir customers about a new version.
=C2=A0

I see us walking = along the same kind of path here, nearly a decade later. That=E2=80=99s why= I think OAuth 3 makes sense as a name for the output of this work. Or at t= he very least, for the core delegation protocol portion of whatever we make= . I think it sends the right message to implementers and developers: the co= mmunity that knows and understands OAuth 2 is working on the next version o= f that thing, so when it=E2=80=99s ready, maybe you should look at it. Unti= l it=E2=80=99s done, and for a long time after, OAuth 2 is still going to b= e there and be the right answer.=C2=A0

I agree that people may be confused if it is called something else = that OAuth, but if it is broader than OAuth, then that is confusing as well= .
=C2=A0
<= div>

The name isn=E2=80=99t a hill I=E2=80=99m committed= to dying alone on, but I think it sends a :bad: message if we call it some= thing new entirely. Namely, that we think people :should: abandon the entir= e world of OAuth, all of its ideas and implementations. That=E2=80=99s not = what we=E2=80=99re doing with this design, it=E2=80=99s an evolution as I s= ee things. And as an evolution, a new major revision number makes sense.

=C2=A0=E2=80=94 Justin

On Dec 24, 2019, at 9:54 AM, Brian Campbell <bcampbell@pingidentity.= com> wrote:

Naming any prospecti= ve resulting work here "OAuth 3.0" would significantly exacerbate= confusion in the whole space and would be a major disservice to the broade= r community.


On Mon, Dec 23, 2019 at 7:39 PM = Aaron Parecki <aa= ron@parecki.com> wrote:
I definitely am not trying to discuss= specifics of *how* authentication should be included right now, but I just= want to make sure it's included in the charter so that we can actually= talk about it and it won't be "out of scope" when we eventua= lly do talk about the specifics.

Aaron


On Mon, Dec 23, 2019 at 1:51 PM Justin Richer <jricher@mit.edu> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I=E2=80=99m fine with= it being in charter but I do think it should be a clearly separate layer, = much like OIDC/Facebook Connect/GitHub Login/etc are with OAuth today. In a= ll of these the authorization is first, and I think that=E2=80=99s the righ= t pattern. So if we do take it on we=E2=80=99ll just need to be careful how= it=E2=80=99s structured in with everything else. Otherwise, I think the au= thentication side can quickly overwhelm and drag down the authorization sid= e.

Good news: A lot of the additional stuff in OIDC is t= here to patch holes in core OAuth in a common fashion, and we=E2=80=99ll at= least be in a position to not have to do that again.=C2=A0


=C2=A0=E2=80=94 Justin

On Dec 22, 2019, at 10:46 PM, Aaron Parecki <aaron@parecki.com> = wrote:

I do think authentication shoul= d be part of the charter from the outset. Frankly the fact that authenticat= ion is intentionally left out of OAuth and has to be bolted on to the side = via OpenID Connect is one of the exact reasons people get confused about th= e whole space to begin with.=C2=A0

<= div dir=3D"auto">It's a relatively minor addition to the existing propo= sed spec to make it useful as a minimum viable authentication solution, and= I'd like to see that be addressed at the beginning of this work.
=

I think we can do this in a s= mart way and that authentication should be included in the charter.

Aaron



On Sat, Dec = 21, 2019 at 1:51 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Hi Justin,

= =C2=A0

I think the charter should mention = target use cases. For example, =E2=80=9Call use cases supported by OAuth 2 = will be supported by the new protocol=E2=80=9D or =E2=80=9Cthe protocol wil= l support at least use cases X and Y=E2=80=9D.

=C2=A0

And given the im= portance of OIDC, we could say something like: =E2=80=9CThe protocol will a= llow future extension to support authentication, in an analogous way to Ope= nID Connect. However authentication is explicitly not part of the initial s= cope.=E2=80=9D

=C2=A0=

Thanks,

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Yaron

=C2=A0

= From: Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer <jricher@mit.edu>
Dat= e: Saturday, December 21, 2019 at 00:34
To: <txauth@ietf.org>
Cc: <= /b>"rdd@cert.org= " <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>
Subject: [Txauth] TxAuth Proposed Charte= r

=C2=A0

Hi all,

=C2=A0

A= s discussed in Singapore, no matter what forum TxAuth takes, its work will = require a new charter. With that in mind, I=E2=80=99ve taken a bit of time = to put together a proposed charter text for the TxAuth work:<= /p>

=C2=A0

This group is chartered to develop a next-generation transactional authori= zation and delegation protocol for HTTP-based APIs and their clients. These= transactions will allow an authorizing party to delegate a right of access= for an API or set of APIs through an authorization server to a software cl= ient acting on behalf of an authorizing party.=C2=A0

=C2=A0

The group will deliver a protocol specification detailing how a= client can request and obtain delegated access, how an authorization serve= r can provide delegated access, how an authorized party can authorize deleg= ated access, and how that authorized access can be communicated to the reso= urces being protected. These actions will be connected through an explicit = transaction between the client and authorization server, resulting in an ar= tifact that will allow the client to undertake the delegated action.=C2=A0<= u>

=C2=A0

=

Additionally, the delegation process will= allow for:

- Fine-grain= ed specification of resource access

- Delegation between multiple users

- Web, mobile, single-page, and other client applic= ations

=C2=A0<= /u>

The group will define extension po= ints for this protocol to allow for flexibility in areas including:<= u>

=C2=A0

<= div>

- Cryptographic agility for keys, message signat= ures, and proof of possession=C2=A0

- User interaction mechanisms including web and non-web methods=

- Token presentation me= chanisms and key bindings

=C2=A0

The artifacts f= or this work are not intended or expected to be backwards-compatible with O= Auth 2.0 and its extensions.=C2=A0

=C2=A0

While this work could be done in within the OAuth working group, I n= ow believe that it should be done in a new working group, and that we shoul= d try to get that working group up and running prior to the Vancouver meeti= ng in March. I think this group should stay here on the TxAuth list, and it= =E2=80=99s my suggestion that the resulting work be called OAuth 3.0.=C2=A0=

=C2=A0

Why a new group? I think that the OAuth = working group should remain focused on extending, patching, and adapting OA= uth 2.0 to a changing world. I plan to be engaged in both groups, and I kno= w most of you are as well, but that=E2=80=99s not universal. Since OAuth 2.= 0 is so established already, there are a LOT of people who aren=E2=80=99t g= oing to be interested in something new any time soon. But on the other hand= , there are a number of people for whom OAuth 2.0 does not work, or is at t= he very least a poor fit, and we=E2=80=99ll want to bring them in at this e= arly stage. So even with significant overlap, I think there=E2=80=99s enoug= h disconnect in the community from both sides that warrants a new group. In= addition, I think this is a big enough piece of work that it=E2=80=99s sim= ply too much for the OAuth working group to be able to focus on. We wouldn= =E2=80=99t be able to get additional meeting time, and OAuth already has tr= ouble fitting into its two meeting slots as it is.

<= div>

=C2=A0

I=E2=80=99ve published a blog post detailing more of my rationale= :

=C2=A0

=C2=A0

Pl= ease suggest changes to the proposed charter text above. It=E2=80=99s my ho= pe that we can get the chartering process started.

<= div>

=C2=A0

=C2=A0=E2=80=94 Justin

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth <= u>

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--
----
Aaron = Parecki


-- =
----
Aaron Parecki
@aaronpk

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.

<= /div>
Aaron




On Sat, Dec 21, 2019 at 1:51 PM Y= aron Sheffer <yaronf.ietf@gmail= .com> wrote:

Hi Justin,<= u>

=C2=A0

I think the charter should mention target use cases. For exampl= e, =E2=80=9Call use cases supported by OAuth 2 will be supported by the new= protocol=E2=80=9D or =E2=80=9Cthe protocol will support at least use cases= X and Y=E2=80=9D.

=C2=A0=

And given the importance of OIDC, we could s= ay something like: =E2=80=9CThe protocol will allow future extension to sup= port authentication, in an analogous way to OpenID Connect. However authent= ication is explicitly not part of the initial scope.=E2=80=9D=

=C2=A0

T= hanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

=

=C2=A0

From: <= span style=3D"font-size:12.0pt;color:black">Txauth <txauth-bounces@ietf.org> on= behalf of Justin Richer <jricher@mit.edu>
Date: Saturday, December 21, 2019 = at 00:34
To: <txauth@ietf.org>
Cc: "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>
Sub= ject: [Txauth] TxAuth Proposed Charter

=C2=A0

Hi all,

=C2=A0

As discussed in Singapore, no matte= r what forum TxAuth takes, its work will require a new charter. With that i= n mind, I=E2=80=99ve taken a bit of time to put together a proposed charter= text for the TxAuth work:

=C2=A0

This group is chartered to deve= lop a next-generation transactional authorization and delegation protocol f= or HTTP-based APIs and their clients. These transactions will allow an auth= orizing party to delegate a right of access for an API or set of APIs throu= gh an authorization server to a software client acting on behalf of an auth= orizing party.=C2=A0

= =C2=A0

The group will deliv= er a protocol specification detailing how a client can request and obtain d= elegated access, how an authorization server can provide delegated access, = how an authorized party can authorize delegated access, and how that author= ized access can be communicated to the resources being protected. These act= ions will be connected through an explicit transaction between the client a= nd authorization server, resulting in an artifact that will allow the clien= t to undertake the delegated action.=C2=A0

=C2=A0

Additionally, the delegation process will allow for:

- Fine-grained specification of resource acc= ess

- Delegation between= multiple users

- Web, m= obile, single-page, and other client applications

=C2=A0

The group will define extension points for this protocol to allow = for flexibility in areas including:

=C2=A0

- Cry= ptographic agility for keys, message signatures, and proof of possession=C2= =A0

- User interaction m= echanisms including web and non-web methods

- Token presentation mechanisms and key bindings=

=C2=A0

=

The artifacts for this work are not intended or= expected to be backwards-compatible with OAuth 2.0 and its extensions.=C2= =A0

= =C2=A0

While this work could be= done in within the OAuth working group, I now believe that it should be do= ne in a new working group, and that we should try to get that working group= up and running prior to the Vancouver meeting in March. I think this group= should stay here on the TxAuth list, and it=E2=80=99s my suggestion that t= he resulting work be called OAuth 3.0.=C2=A0

=C2=A0

Why a new group? I think that the OAuth working group should remain foc= used on extending, patching, and adapting OAuth 2.0 to a changing world. I = plan to be engaged in both groups, and I know most of you are as well, but = that=E2=80=99s not universal. Since OAuth 2.0 is so established already, th= ere are a LOT of people who aren=E2=80=99t going to be interested in someth= ing new any time soon. But on the other hand, there are a number of people = for whom OAuth 2.0 does not work, or is at the very least a poor fit, and w= e=E2=80=99ll want to bring them in at this early stage. So even with signif= icant overlap, I think there=E2=80=99s enough disconnect in the community f= rom both sides that warrants a new group. In addition, I think this is a bi= g enough piece of work that it=E2=80=99s simply too much for the OAuth work= ing group to be able to focus on. We wouldn=E2=80=99t be able to get additi= onal meeting time, and OAuth already has trouble fitting into its two meeti= ng slots as it is.

=C2=A0

I=E2=80=99ve published= a blog post detailing more of my rationale:

=C2=A0

-- Txauth mailing list Txauth@ietf.org https:/= /www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--000000000000e2d187059af428a9-- From nobody Mon Dec 30 15:25:50 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8A2120B3B for ; Mon, 30 Dec 2019 15:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 ojW_feGntkld for ; Mon, 30 Dec 2019 15:25:45 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 A8CDF1200C1 for ; Mon, 30 Dec 2019 15:25:44 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id 15so26096368lfr.2 for ; Mon, 30 Dec 2019 15:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gvPrkIyksCV0L0OF5aMCtXlWRRdzCFvUwkzj/ylNE/U=; b=J2QuRJiAvGT/ujslAw/U1xYDqcwPwp4w2+LWhA6CNoOF6P23Z3kxwFRKITf28gJopq giUGJSS7zKiXnnEd/XX8Igu3BqaL8jogS4cexdm7uGWqPwlwQPCDmpyUurYFWJA3iFjI /KIfT6uuKKo49UMYV5OCWSwFAl0Ug8ILfPpKi4LSydQD+ORJT3rMZu2EmEjR/hvkOwhM EVh13QTy0yMAglvKxgvE78yoAzNeRYX5dKfznmbtumQvwxuuOnyqTpRnTWmua20qJOMS ArgAfz358QR75WMvVeyv8RFLaFOKqkTvGgq2y7coxX8Oczk37evkXKxhFxwvkQ3DLAzE 5XOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gvPrkIyksCV0L0OF5aMCtXlWRRdzCFvUwkzj/ylNE/U=; b=a9VVFFkF/JPFZmmQGzPw/WbIL4+bSbbXzvvAG3412nrAyJN6bxny9DFsKRYmADx1RN 4EjkMIaW+w7R4nZCkLgsKslX4H1LG+WYnbo7YpJs7Z9EzbX+tEeo77WIHbz9lznf02SH a8hcAGKvfhZdqp7WH/+9/n0Qr/FaaNX/sKAF1Tc+XHHoWWB576xoO0Sgz7iJ1b+csLw+ 1VIU1/eF+S+DUPsjHNjIJ6kKVkWew+0VQk2itpQU41n4V9eqRnGYnoK8PU3mP6NH5AZh Tztmv/fVvzr9rXbqCDGqxsMrLVc7ykk3PTmV0lQ7+ygfe3VTDhBJ4toDkDjY3QjltIM2 b9Pg== X-Gm-Message-State: APjAAAV8+MNllFuUH54567E1ChwtPGBpseMKK2szc+zaaipXtGjHy9JW 5dke3X1V4EoIkH9IIop3ERxwt9qMwiOs7NUWLIk= X-Google-Smtp-Source: APXvYqwW0zcYl7papi0Iq5YVrxLRslOXqeFjLcjXVUPHgHvieoDO1uzFXKjLZHTvsHGlHhSqnq9z3A4xrdze4hRtwBY= X-Received: by 2002:a19:4208:: with SMTP id p8mr38456043lfa.160.1577748342581; Mon, 30 Dec 2019 15:25:42 -0800 (PST) MIME-Version: 1.0 References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <5526B528-28A6-4F18-BE2D-846CCA035D77@amazon.com> <958491C8-81C8-469D-973D-40AD9769F21C@amazon.com> <00EEAD4B-AA76-4BDB-B3BA-378FE3BAEFFE@mit.edu> <949341AE-C72B-4645-8F20-699F14529FFB@mit.edu> <78FA3EB7-C72F-4543-95A8-03123F4E40A1@amazon.com> <20A699D9-C2A2-4B88-8F64-454D83BB0221@mit.edu> In-Reply-To: <20A699D9-C2A2-4B88-8F64-454D83BB0221@mit.edu> From: Dick Hardt Date: Mon, 30 Dec 2019 15:25:31 -0800 Message-ID: To: Justin Richer Cc: "Richard Backman, Annabelle" , Eve Maler , "rdd@cert.org" , "txauth@ietf.org" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000812e5c059af42916" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2019 23:25:48 -0000 --000000000000812e5c059af42916 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd agree with that. On Sat, Dec 28, 2019 at 9:07 AM Justin Richer wrote: > I=E2=80=99d argue that it=E2=80=99s actually essential that the complex d= eployments don=E2=80=99t > add complexity to the simple ones. > > =E2=80=94 Justin > > On Dec 27, 2019, at 1:16 PM, Dick Hardt wrote: > > I concur with Annabelle. Pretty much all large systems have a clear > separation between different functions to provide resiliency and improved > security (separation of duties) > > Ideally we can do this without adding complexity for deployments that > don't require it. > > > On Sun, Dec 22, 2019 at 8:52 PM Richard Backman, Annabelle < > richanna@amazon.com> wrote: > >> My example demonstrates an architecture where the TX Endpoint, >> authentication system, and token issuer aren=E2=80=99t simply different = micro >> services, they=E2=80=99re completely independent systems in different tr= ust >> boundaries, possibly have different domains and different keys. This has >> implications for protocol design. For example, it would no longer be >> sufficient to have a single jwks_uri, as OAuth 2.0 has. >> >> If we want to support this kind of =E2=80=9Cdecomposed AS=E2=80=9D model= , then we need to >> make sure that=E2=80=99s supported by the charter and keep it in mind as= we design >> the protocol. We can also decide it is out of scope, but we should be >> intentional about that decision. >> >> To my mind, this role decomposition is the next logical step after the >> channel decomposition that TxAuth already does. I see a lot of potential= in >> it and think we should at minimum avoid closing the door on it. >> >> On Dec 22, 2019, at 5:35 PM, Justin Richer wrote: >> >> =EF=BB=BF I think you=E2=80=99re conflating the *roles* that different c= omponents play, >> in regard to the other components, with the potential deployment of thos= e >> components. The spec needs to be written in terms of the roles. While th= e >> roles do need to consider what potential deployments might be, it=E2=80= =99s >> important that we write things in in terms of how they interact with eac= h >> other and not in terms of how they might look under the covers. >> >> So from the clients perspective, the TX Endpoint :is: the AS. The client >> doesn=E2=80=99t care that it=E2=80=99s a =E2=80=9Cglorified message queu= e=E2=80=9D or if it=E2=80=99s a massive >> server farm. The client doesn=E2=80=99t care if there=E2=80=99s a TLS re= verse proxy or if >> it=E2=80=99s talking directly to the application layer. The only thing t= he client >> cares about is if the TX Endpoint does the things that a TX Endpoint is >> supposed to do, and we define that to be the function of the AS. >> >> What=E2=80=99s important in your scenario below is that the client would= have to >> talk to the RS first every time. That=E2=80=99s one of the problems that= UMA has, >> and I think something we should avoid. I think RS-first is an interestin= g >> pattern but AS-first ought to drive this. >> >> With your hypothetical layout below, it really sounds like the TX >> Endpoint is a function of the IDP, which is fine. The client doesn=E2=80= =99t care >> that it=E2=80=99s deployed using some externalized cloud service. The on= ly weird >> thing going on is the push from the AS back to the client. The client wo= uld >> need to register that with the AS (or through the AS more specifically) = as >> part of its transaction request. This would be part of its interaction >> mechanism, because =E2=80=9Chow you get messages and updates back to the= client=E2=80=9D is >> part of the interaction model. >> >> So for an RS-first transaction, the client calls the RS: >> >> GET /foo >> >> The RS returns a resource handle, but the client doesn=E2=80=99t care wh= ere that >> came from. The RS could talk to the AS to get it. Probably a new endpoin= t >> of some kind, can probably use the same kinds of key binding that the TX >> Endpoint has. Or the RS can make one up that the TX Endpoint can recogni= ze. >> Or it calls the IdP to get one. The client doesn=E2=80=99t care, and tha= t=E2=80=99s the key >> point. >> >> WWW-Authenticate tx_endpoint=3D=E2=80=9Chttp://server//tx >> =E2=80=9D resource: =E2=80=9Casdf1234=E2=80= =9D >> >> The client calls the TX endpoint like a normal transaction: >> >> POST /tx >> >> { >> resources: [ =E2=80=9Casdf1234=E2=80=9D ], >> interact: { >> redirect: true, >> push: =E2=80=9Chttp://client/push/9876=E2=80=9D >> } >> } >> >> The AS (which is to say the TX Endpoint) tells the client to send the >> user agent to the IdP >> >> { >> interact_url: =E2=80=9Chttp://idp/login=E2=80=9D, >> handle: { value: =E2=80=9Chjkl=E2=80=9D, type: bearer } >> } >> >> Now the client could poll the TX Endpoint but it could also just sit and >> wait for an update to be pushed in. >> >> There are probably things that need to be tied together for this to be >> secure, but I think the basic pattern still fits. Importantly, the clien= t >> doesn=E2=80=99t care whereby of that stuff came from =E2=80=94 as far as= it=E2=80=99s concerned, >> it=E2=80=99s talking to the AS. >> >> Remember, the =E2=80=9CAS=E2=80=9D is a logical construct, not a physica= l one. Just like >> the =E2=80=9Cclient=E2=80=9D could be a cluster of applications and the = =E2=80=9CRS=E2=80=9D could be a >> suite of APIs tied behind a gateway. >> >> =E2=80=94 Justin >> >> >> On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >> >> On Dec 21, 2019, at 4:42 AM, Justin Richer wrote: >> >> >> Even if the client starts at the RS, the client still has to go talk to >> the AS. I haven=E2=80=99t built this out, but I see it working somewhat = like UMA. >> In XYZ=E2=80=99s terms: >> >> >> 1. Client calls the RS trying to Do A Thing >> 2. RS calls the AS requesting a Resource Handle (because that=E2=80=99s = what the >> RS represents, resources) =E2=80=94 at least good enough to cover what t= he client >> tried to do, could be more >> 3. RS gives the Resource Handle and AS Transaction Endpoint back to the >> client >> 4. Client calls the AS Transaction Endpoint to start a transaction, >> includes the Resource Handle as part of its request (note: doesn=E2=80= =99t have to >> be the whole resource section, client can add stuff) >> 5. Process continues as normal >> >> >> It depends on what you consider the =E2=80=9CAS=E2=80=9D. Consider the f= ollowing >> hypothetical architecture: >> >> =E2=80=A2 The RS, client, and tx endpoint are on the public Internet. >> =E2=80=A2 The tx endpoint returns interaction urls that point to an IdP = that is >> inaccessible from the public Internet. >> =E2=80=A2 The user agent can reach the IdP, but none of the other system= s can. >> =E2=80=A2 When the UA is redirected to the IdP, the IdP calls the tx end= point >> system to retrieve transaction details. >> =E2=80=A2 When authorization is granted, the IdP pushes artifacts direct= ly to an >> endpoint provided by the client. >> >> In this example, the client only interacts with the RS and the tx >> endpoint. It seems odd to me to consider the system hosting the tx endpo= int >> to be the AS (or at least part of the AS), as its a glorified message qu= eue >> with essentially no authority in this architecture. >> >> We could go a step further and remove the client=E2=80=99s interaction w= ith the >> tx endpoint by having the RS return the interaction url directly (you=E2= =80=99d >> need to secure the client nonce if you want to hide it from the RS, but >> that=E2=80=99s not that hard). >> >> Is the meaning of =E2=80=9Cauthorization server=E2=80=9D (or the phrase = =E2=80=9Cthrough an >> authorization server=E2=80=9D) flexible enough to accommodate these case= s? Or are >> they considered out of scope for TxAuth? >> >> =E2=80=94 Justin >> >> >> As I said, maybe I=E2=80=99m being too literal. >> >> =E1=90=A7 >> On Fri, Dec 20, 2019 at 5:08 PM Richard Backman, Annabelle < >> richanna@amazon.com> wrote: >> >>> I=E2=80=99m not sure if this is what Eve had in mind, but consider an a= utomated >>> system in an enterprise context that has been authorized by an >>> administrator. The automated system isn=E2=80=99t acting as or on behal= f of the >>> administrator, and the administrator hasn=E2=80=99t =E2=80=9Cdelegated = access=E2=80=9D; they=E2=80=99ve >>> *granted* access, just as they do when they assign permissions to >>> users/groups/roles/etc. >>> >>> Maybe I=E2=80=99m being too literal, but =E2=80=9Cthrough an authorizat= ion server=E2=80=9D in >>> paragraph 1 implies a specific context/information/request flow to me. >>> Given that one of TxAuth=E2=80=99s features is decoupling the different >>> communication channels, we should not suggest that the client or >>> authorizing party is directly interacting with the AS. >>> >>> >>> >>> =E2=80=93 >>> >>> Annabelle Richard Backman >>> >>> AWS Identity >>> >>> >>> >>> >>> >>> *From: *Txauth on behalf of Dick Hardt < >>> dick.hardt@gmail.com> >>> *Date: *Friday, December 20, 2019 at 4:14 PM >>> *To: *Eve Maler >>> *Cc: *"rdd@cert.org" , "txauth@ietf.org" , >>> Justin Richer , Benjamin Kaduk >>> *Subject: *Re: [Txauth] TxAuth Proposed Charter >>> >>> >>> >>> Eve: do you not think the software client is acting on behalf of some >>> party? Or do you think that software always is acting on behalf of some >>> party, and the mentioned phrase is redundant? >>> >>> >>> >>> Justin: a couple questions >>> >>> >>> >>> 1. What is meant by "Delegation between multiple users" ? >>> >>> >>> >>> 2. Why do you restrict this to HTTP? >>> >>> >>> >>> 3. Why is authentication not in scope? >>> >>> >>> >>> 4. When you say "not backwards compatible with OAuth 2.0 and its >>> extensions", do you expect to define a new standard to replace RFC 6750= ? >>> Developers will have to have a new method to call APIs? >>> >>> >>> >>> >>> >>> On Fri, Dec 20, 2019 at 3:27 PM Eve Maler wrote: >>> >>> Re =E2=80=9Cto a software client _acting on behalf of an authorizing pa= rty_=E2=80=9D: >>> There is a whole lot of philosophy behind whom the delegated access is >>> performed on behalf of, unless the scenario is single-user or some "act= as" >>> semantic is spelled out on the wire. Does it need to be stated here? Wh= at's >>> the consequence if the highlighted phrase were removed? >>> >>> Eve Maler (sent from my iPad) | cell +1 425 345 6756 >>> >>> >>> >>> On Dec 20, 2019, at 4:34 PM, Justin Richer wrote: >>> >>> Hi all, >>> >>> >>> >>> As discussed in Singapore, no matter what forum TxAuth takes, its work >>> will require a new charter. With that in mind, I=E2=80=99ve taken a bit= of time to >>> put together a proposed charter text for the TxAuth work: >>> >>> >>> >>> This group is chartered to develop a next-generation transactional >>> authorization and delegation protocol for HTTP-based APIs and their >>> clients. These transactions will allow an authorizing party to delegate= a >>> right of access for an API or set of APIs through an authorization serv= er >>> to a software client acting on behalf of an authorizing party. >>> >>> >>> >>> The group will deliver a protocol specification detailing how a client >>> can request and obtain delegated access, how an authorization server ca= n >>> provide delegated access, how an authorized party can authorize delegat= ed >>> access, and how that authorized access can be communicated to the resou= rces >>> being protected. These actions will be connected through an explicit >>> transaction between the client and authorization server, resulting in a= n >>> artifact that will allow the client to undertake the delegated action. >>> >>> >>> >>> Additionally, the delegation process will allow for: >>> >>> - Fine-grained specification of resource access >>> >>> - Delegation between multiple users >>> >>> - Web, mobile, single-page, and other client applications >>> >>> >>> >>> The group will define extension points for this protocol to allow for >>> flexibility in areas including: >>> >>> >>> >>> - Cryptographic agility for keys, message signatures, and proof of >>> possession >>> >>> - User interaction mechanisms including web and non-web methods >>> >>> - Token presentation mechanisms and key bindings >>> >>> >>> >>> The artifacts for this work are not intended or expected to be >>> backwards-compatible with OAuth 2.0 and its extensions. >>> >>> >>> >>> While this work could be done in within the OAuth working group, I now >>> believe that it should be done in a new working group, and that we shou= ld >>> try to get that working group up and running prior to the Vancouver mee= ting >>> in March.. I think this group should stay here on the TxAuth list, and = it=E2=80=99s >>> my suggestion that the resulting work be called OAuth 3.0. >>> >>> >>> >>> Why a new group? I think that the OAuth working group should remain >>> focused on extending, patching, and adapting OAuth 2.0 to a changing wo= rld. >>> I plan to be engaged in both groups, and I know most of you are as well= , >>> but that=E2=80=99s not universal. Since OAuth 2.0 is so established alr= eady, there >>> are a LOT of people who aren=E2=80=99t going to be interested in someth= ing new any >>> time soon. But on the other hand, there are a number of people for whom >>> OAuth 2.0 does not work, or is at the very least a poor fit, and we=E2= =80=99ll want >>> to bring them in at this early stage. So even with significant overlap,= I >>> think there=E2=80=99s enough disconnect in the community from both side= s that >>> warrants a new group. In addition, I think this is a big enough piece o= f >>> work that it=E2=80=99s simply too much for the OAuth working group to b= e able to >>> focus on. We wouldn=E2=80=99t be able to get additional meeting time, a= nd OAuth >>> already has trouble fitting into its two meeting slots as it is. >>> >>> >>> >>> I=E2=80=99ve published a blog post detailing more of my rationale: >>> >>> >>> >>> >>> https://medium.com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-wor= king-group-d6229ba8e36? >>> >>> >>> >>> Please suggest changes to the proposed charter text above. It=E2=80=99s= my hope >>> that we can get the chartering process started. >>> >>> >>> >>> =E2=80=94 Justin >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >> >> > --000000000000812e5c059af42916 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd agree with that.

On Sat, Dec 28, 2019 at 9:07 AM Ju= stin Richer <jricher@mit.edu> = wrote:
I=E2=80=99d argue that it=E2=80=99s actual= ly essential that the complex deployments don=E2=80=99t add complexity to t= he simple ones.

=C2=A0=E2=80=94 Justin

On Dec 27, 2019, at 1:16 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I concur=C2=A0with Annabelle. = Pretty much all large systems have a clear separation between different fun= ctions to provide resiliency and improved security (separation of duties)
Ideally we can do this without adding complexity for depl= oyments that don't require it.


On Sun, Dec 22, 2019= at 8:52 PM Richard Backman, Annabelle <richanna@amazon.com> wrote:
My example demonstrates an architecture where the TX Endpoint, authen= tication system, and token issuer aren=E2=80=99t simply different micro ser= vices, they=E2=80=99re completely independent systems in different trust boundaries, possibly have different domains and different keys. This= has implications for protocol design. For example, it would no longer be s= ufficient to have a single jwks_uri, as OAuth 2.0 has.

If we want to support this kind of =E2=80=9Cdecomposed AS= =E2=80=9D model, then we need to make sure that=E2=80=99s supported by the = charter and keep it in mind as we design the protocol. We can also decide i= t is out of scope, but we should be intentional about that decision.

To my mind, this role decomposition is the next logical st= ep after the channel decomposition that TxAuth already does. I see a lot of= potential in it and think we should at minimum avoid closing the door on i= t.

On Dec 22, 2019, at 5:35 PM, Justin Richer <jricher@mit.edu> = wrote:

=EF=BB=BF I think you=E2=80=99re conflating the roles=C2=A0that different components play, in regard to the other components, = with the potential deployment of those components. The spec needs to be wri= tten in terms of the roles. While the roles do need to consider what potential deployments might be, it=E2=80=99s importa= nt that we write things in in terms of how they interact with each other an= d not in terms of how they might look under the covers.

So from the clients perspective, the TX Endpoint :is: the AS. The clie= nt doesn=E2=80=99t care that it=E2=80=99s a =E2=80=9Cglorified message queu= e=E2=80=9D or if it=E2=80=99s a massive server farm. The client doesn=E2=80= =99t care if there=E2=80=99s a TLS reverse proxy or if it=E2=80=99s talking= directly to the application layer. The only thing the client cares about is if the TX = Endpoint does the things that a TX Endpoint is supposed to do, and we defin= e that to be the function of the AS.=C2=A0

What=E2=80=99s important in your scenario below is that the client wou= ld have to talk to the RS first every time. That=E2=80=99s one of the probl= ems that UMA has, and I think something we should avoid. I think RS-first i= s an interesting pattern but AS-first ought to drive this.=C2=A0

With your hypothetical layout below, it really sounds like the TX Endp= oint is a function of the IDP, which is fine. The client doesn=E2=80=99t ca= re that it=E2=80=99s deployed using some externalized cloud service. The on= ly weird thing going on is the push from the AS back to the client. The client would need to register that with the= AS (or through the AS more specifically) as part of its transaction reques= t. This would be part of its interaction mechanism, because =E2=80=9Chow yo= u get messages and updates back to the client=E2=80=9D is part of the interaction model.=C2=A0

So for an RS-first transaction, the client calls the RS:

GET /foo

The RS returns a resource handle, but the client doesn=E2=80=99t care = where that came from. The RS could talk to the AS to get it. Probably a new= endpoint of some kind, can probably use the same kinds of key binding that= the TX Endpoint has. Or the RS can make one up that the TX Endpoint can recognize. Or it calls the IdP to= get one. The client doesn=E2=80=99t care, and that=E2=80=99s the key point= .=C2=A0

WWW-Authenticate tx_endpoint=3D=E2=80=9Chttp://server//tx=E2=80=9D resource: =E2=80= =9Casdf1234=E2=80=9D

The client calls the TX endpoint like a normal transaction:

POST /tx

{
=C2=A0 resources: [ =E2=80=9Casdf1234=E2=80=9D ],
=C2=A0 interact: {
=C2=A0 =C2=A0 redirect: true,
=C2=A0 =C2=A0 push: =E2=80=9Chttp://client/push/9876=E2=80=9D
=C2=A0 }
}

The AS (which is to say the TX Endpoint) tells the client to send the = user agent to the IdP

{
=C2=A0 interact_url: =E2=80=9Chttp://idp/login=E2=80=9D,
=C2=A0 handle: { value: =E2=80=9Chjkl=E2=80=9D, type: bearer }
}

Now the client could poll the TX Endpoint but it could also just sit a= nd wait for an update to be pushed in.=C2=A0

There are probably things that need to be tied together for this to be= secure, but I think the basic pattern still fits. Importantly, the client = doesn=E2=80=99t care whereby of that stuff came from =E2=80=94 as far as it= =E2=80=99s concerned, it=E2=80=99s talking to the AS.=C2=A0

Remember, the =E2=80=9CAS=E2=80=9D is a logical construct, not a physi= cal one. Just like the =E2=80=9Cclient=E2=80=9D could be a cluster of appli= cations and the =E2=80=9CRS=E2=80=9D could be a suite of APIs tied behind a= gateway.

=C2=A0=E2=80=94 Justin


On Dec 22, 2019, at 1:05 AM, Richard Backman, Annabelle <richanna@amazon.com> = wrote:


On Dec 21, 2019, at 4:42 AM, Justin Richer <jricher@mit.edu> = wrote:

Even if the client starts at the RS, the client still has to go talk t= o the AS. I haven=E2=80=99t built this out, but I see it working somewhat l= ike UMA. In XYZ=E2=80=99s terms:


1. Client calls the RS trying to Do A Thing
2. RS calls the AS requesting a Resource Handle (because that=E2=80=99= s what the RS represents, resources) =E2=80=94 at least good enough to cove= r what the client tried to do, could be more
3. RS gives the Resource Handle and AS Transaction Endpoint back to th= e client
4. Client calls the AS Transaction Endpoint to start a transaction, in= cludes the Resource Handle as part of its request (note: doesn=E2=80=99t ha= ve to be the whole resource section, client can add stuff)
5. Process continues as normal

It depends on what you consider the =E2=80=9CAS=E2=80=9D. Consider the= following hypothetical architecture:

=E2=80=A2 The RS, client, and tx endpoint are on the public Internet.<= /div>
=E2=80=A2 The tx endpoint returns interaction urls that point to an Id= P that is inaccessible from the public Internet.
=E2=80=A2 The user agent can reach the IdP, but none of the other syst= ems can.
=E2=80=A2 When the UA is redirected to the IdP, the IdP calls the tx e= ndpoint system to retrieve transaction details.
=E2=80=A2 When authorization is granted, the IdP pushes artifacts dire= ctly to an endpoint provided by the client.

In this example, the client only interacts with the RS and the tx endp= oint. It seems odd to me to consider the system hosting the tx endpoint to = be the AS (or at least part of the AS), as its a glorified message queue wi= th essentially no authority in this architecture.=C2=A0

We could go a step further and remove the client=E2=80=99s interaction= with the tx endpoint by having the RS return the interaction url directly = (you=E2=80=99d need to secure the client nonce if you want to hide it from = the RS, but that=E2=80=99s not that hard).

Is the meaning of =E2=80=9Cauthorization server=E2=80=9D (or the phras= e =E2=80=9Cthrough an authorization server=E2=80=9D) flexible enough to acc= ommodate these cases? Or are they considered out of scope for TxAuth?

=C2=A0=E2=80=94 Justin


As I said, maybe I=E2=80=99m being too literal.

3D""=E1=90=A7
On Fri, Dec 20, 2019 at 5:08 PM Richa= rd Backman, Annabelle <richanna@amazon.com> wrote:

I=E2=80=99m not sure if this is what Eve had in= mind, but consider an automated system in an enterprise context that has b= een authorized by an administrator. The automated system isn=E2=80=99t acti= ng as or on behalf of the administrator, and the administrator hasn=E2=80=99t =E2=80=9Cdelegated access=E2=80=9D; they=E2=80=99ve gran= ted access, just as they do when they assign permissions to users/group= s/roles/etc.

Maybe I=E2=80=99m being too literal, but =E2=80=9Cthroug= h an authorization server=E2=80=9D in paragraph 1 implies a specific contex= t/information/request flow to me. Given that one of TxAuth=E2=80=99s featur= es is decoupling the different communication channels, we should not suggest that the client or authorizing party is directly interacting w= ith the AS.

=C2=A0

=E2=80=93=C2=A0<= u>

Annabelle Richard Backman

AWS Identity

=C2=A0

=C2=A0

= From: Txauth <txauth-bounces@ietf.org> on behalf o= f Dick Hardt <= dick.hardt@gmail.com>
Date: Friday, December 20, 2019 at 4:14 PM
To: Eve Maler <eve@xmlgrrl.com>
Cc: "rdd@cert= .org" <rdd@ce= rt.org>, "= txauth@ietf.org" <txauth@ietf.org>, Justin Richer <jri= cher@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>
Subject: Re: [Txauth] TxAuth Proposed Charter

=C2=A0

Eve: do you not think the software client is ac= ting on behalf of some party? Or do you think that software always is actin= g on behalf of some party, and the mentioned phrase is redundant?

=C2=A0

Justin: a couple questions

=C2=A0

1. What is meant by "Delegation between mu= ltiple users" ?

=C2=A0

2. Why do you restrict this to HTTP?<= /u>

=C2=A0

3. Why is authentication not in scope?

=C2=A0

4. When you say "not backwards compatible = with OAuth 2.0 and its extensions", do you expect to define a new stan= dard to replace RFC 6750? Developers will have to have a new method to call= APIs?

=C2=A0

=C2=A0

On Fri, Dec 20, 2019 at 3:27 PM Eve Maler <<= a href=3D"mailto:eve@xmlgrrl.com" target=3D"_blank">eve@xmlgrrl.com>= wrote:

Re =E2=80=9Cto a software client _acting on behalf of = an authorizing party_=E2=80=9D: There is a whole lot of philosophy behind whom the delegated access is performed on behalf = of, unless the scenario is single-user or some "act as" semantic = is spelled out on the wire. Does it need to be stated here? What's the = consequence if the highlighted phrase were removed?=C2=A0<= /u>

Eve Maler (sent = from my iPad) |=C2=A0cell +1 425 345 6756



On Dec 20, 2019, at 4:34 PM, Justin Richer = <jricher@mit.edu> wrote:

Hi all,

=C2=A0

As discussed in Singapore, no matter what forum= TxAuth takes, its work will require a new charter. With that in mind, I=E2= =80=99ve taken a bit of time to put together a proposed charter text for th= e TxAuth work:

=C2=A0

This group is chartered to develop a next-gener= ation transactional authorization and delegation protocol for HTTP-based AP= Is and their clients. These transactions will allow an authorizing party to= delegate a right of access for an API or set of APIs through an authorization server to a software client acting= on behalf of an authorizing party.=C2=A0

=C2=A0

The group will deliver a protocol specification= detailing how a client can request and obtain delegated access, how an aut= horization server can provide delegated access, how an authorized party can= authorize delegated access, and how that authorized access can be communicated to the resources being protected. Th= ese actions will be connected through an explicit transaction between the c= lient and authorization server, resulting in an artifact that will allow th= e client to undertake the delegated action.=C2=A0

=C2=A0

Additionally, the delegation process will allow= for:

- Fine-grained specification of resource access=

- Delegation between multiple users

- Web, mobile, single-page, and other client ap= plications

=C2=A0

The group will define extension points for this= protocol to allow for flexibility in areas including:

=C2=A0

- Cryptographic agility for keys, message signa= tures, and proof of possession=C2=A0

- User interaction mechanisms including web and= non-web methods

- Token presentation mechanisms and key binding= s

=C2=A0

The artifacts for this work are not intended or= expected to be backwards-compatible with OAuth 2.0 and its extensions.=C2= =A0

=C2=A0

While this work could be done in within the OAu= th working group, I now believe that it should be done in a new working gro= up, and that we should try to get that working group up and running prior t= o the Vancouver meeting in March.. I think this group should stay here on the TxAuth list, and it=E2=80=99s my sugges= tion that the resulting work be called OAuth 3.0.=C2=A0

=C2=A0

Why a new group? I think that the OAuth working= group should remain focused on extending, patching, and adapting OAuth 2.0= to a changing world. I plan to be engaged in both groups, and I know most = of you are as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so established already, there are a LOT of people who a= ren=E2=80=99t going to be interested in something new any time soon. But on= the other hand, there are a number of people for whom OAuth 2.0 does not w= ork, or is at the very least a poor fit, and we=E2=80=99ll want to bring them in at this early stage. So even with = significant overlap, I think there=E2=80=99s enough disconnect in the commu= nity from both sides that warrants a new group. In addition, I think this i= s a big enough piece of work that it=E2=80=99s simply too much for the OAuth working group to be able to focus on. We wouldn=E2=80= =99t be able to get additional meeting time, and OAuth already has trouble = fitting into its two meeting slots as it is.

=C2=A0

I=E2=80=99ve published a blog post detailing mo= re of my rationale:

=C2=A0

=C2=A0

Please suggest changes to the proposed charter = text above. It=E2=80=99s my hope that we can get the chartering process sta= rted.

=C2=A0

=C2=A0=E2=80=94 Justin

--
Txauth mailing list
Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth




--000000000000812e5c059af42916-- From nobody Mon Dec 30 15:36:18 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D84E120B65 for ; Mon, 30 Dec 2019 15:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 00vTTknKUy-j for ; Mon, 30 Dec 2019 15:36:13 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 37C3C12002E for ; Mon, 30 Dec 2019 15:36:13 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id w1so12875415ljh.5 for ; Mon, 30 Dec 2019 15:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TKgS/hbiKHwwpMgnsKDepUN2i5A7cA2wCZgRoQTLqr4=; b=MvSVrqMlog93wVYUvTHdLd/QkwZNlmyTRAn5fJqy/lY3jDsUSnokmXJrbkxZB4vKVo PSWCgJ+7WYytg3SwFhdraBTdBd4s54lLKDUhZqIg0PpxOrcmgvH8ibRWB9XJw2J+Y/EK ylwKluX/oqUV4q+hOeeCxqdrc59SbdyUQnrzUq++bbbar6fyKGmTJ8claMPkN/+sSmXC pAt4OK51C6Yo1+1PdJnyc4zGm/2axvqURG8M4ynNfIQJHNgPnjRC6MbuRtUCMP5lnAk0 aHaHt8E5/+ajHLq4Fleej6eJOuvqtwWaIkvOng2vw1cnjl/k9X+LnRZ/BbKYU3Jieb3y 99bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TKgS/hbiKHwwpMgnsKDepUN2i5A7cA2wCZgRoQTLqr4=; b=GxdJM5R9wu3inBL0otbN4Ar+6xOuNqHLgMXFE8DohWX4fsGkOxLXhdhXxcuLG2F/G8 +PLc0dbjwd5FC3si+8aq513KXEYSrDHwKCidCV/dNQz/sehqol0vUrL3ZfQvs4TnMyhZ HFljWEXAIZxTq8fEquKlEhalje7PPMQMmh+8Fjhv6WycAUYWuJO+ed5n2GGCN7HjKjRO U4OX2QnEGp1mlhGIS7Br8GXsgZA5fOk1kK9/4dShfixw0leWhkIR4/ZdCrQvh/6USDZS 0KepUyFLl7hx+Q4h7PmfRo92/jr3jdskvFJ+0nI0R90Xu6SpE+SsNjam+BjnhNqKKuc2 Zz+A== X-Gm-Message-State: APjAAAU0QrXFNqDc8JYinXh834f1u6JMv8QryIHavhFWSsghueZX/GDB I8tHagszbTQWMgiLgufOX7d8U0FNyfPk7QwxFRUsAbKeHHk= X-Google-Smtp-Source: APXvYqxTQlOqRKosbR+JM/NheEkDf6kgIs+IXRc0dUfVNNtaU5uYSAki4nrcUGXNFivwM0f1vpmxynLjEJRihKRDD4Q= X-Received: by 2002:a2e:a486:: with SMTP id h6mr30401788lji.235.1577748971349; Mon, 30 Dec 2019 15:36:11 -0800 (PST) MIME-Version: 1.0 References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <07AEE8DB-A0EE-4780-9CE7-B578F69948F9@mit.edu> <68CA5C79-10AB-42E6-B4A9-06A594CA436C@mit.edu> In-Reply-To: <68CA5C79-10AB-42E6-B4A9-06A594CA436C@mit.edu> From: Dick Hardt Date: Mon, 30 Dec 2019 15:36:00 -0800 Message-ID: To: Justin Richer Cc: Eve Maler , "rdd@cert.org" , txauth@ietf.org, Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000fb6d55059af44e34" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2019 23:36:16 -0000 --000000000000fb6d55059af44e34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 28, 2019 at 9:17 AM Justin Richer wrote: > 1. What is meant by "Delegation between multiple users=E2=80=9D ? >> >> >> See above. >> > > I still don't understand. Is one user delegating to another user? This is > a desirable use case for many, but currently not standardized. Is this wh= at > you are proposing is in scope? > > > > I=E2=80=99m proposing that in our model, the person using the client appl= ication > and the person approving the process can be different parties, depending = on > the nature of interaction that the client is capable of. Again, this goes > into the different roles that people play. I do think that this is in > scope, with the condition that in the case where they=E2=80=99r the same = person > (IE, the OAuth case), this collapses cleanly into a simpler case. UMA > doesn=E2=80=99t do that very well, because of the nature of OAuth=E2=80= =99s redirect-first > model. We can do better here. > Got it. Thanks for clarifying. > > >> >> 2. Why do you restrict this to HTTP? >> >> >> Because I want us to use all of the features and benefits of HTTP instea= d >> of having to invent within-protocol functions to replicate them. I don= =E2=80=99t >> want SOAP, which pretends to be transport agnostic much to its detriment= . >> If someone wants to do OAuth 3 on not-HTTP, they can define what that lo= oks >> like. This is what happened with the COAP/CORE stuff and OAuth 2. >> > > I agree SOAP was complicated. Which features and benefits of HTTP are you > wanting to use? > > > Well so far we=E2=80=99ve got headers, URLs, methods, data payload types,= and the > whole array of technologies that we can rely on working together along wi= th > HTTP. > But which ones do you want to use? > > > If it was simple to support COAP, why would we not do that? > > > Because it=E2=80=99s not just COAP =E2=80=94 you=E2=80=99ve got a differe= nt set of assumptions for > the lower layer protocols, and you=E2=80=99ve got lots of considerations = about how > the different components can talk to each other in the embedded space. > You are suggesting we rule out it working with COAP in the charter, before we have even had a chance to work on it. Perhaps it will be trivial to support COAP. We won't know if the charter forbids it. > > In my experience, it=E2=80=99s much more successful to have a protocol st= rongly > integrated with its transport mechanism and then translated out to other > mechanisms, instead of trying to come up with one universal interlingua o= f > a protocol that just get shunted along. > Would you provide an example besides SOAP for this? > This is why SOAP can=E2=80=99t use HTTP verbs to communicate things, and = why the > only signatures it can use are internal. When you do that kind of system, > you almost always end up having people just use it with one transport > anyway, like SOAP over HTTP. > > > >> >> >> 3. Why is authentication not in scope? >> >> >> It felt, to me, like that might be a bridge too far. >> > > I disagree. But I also think that authentication is the wrong term. > Identity* may be a term that maps better, as the Client is wanting to get > "identity" data from the AS. > > * The identity term is super confusing, but authentication implies just > knowing it is the same user, where OpenID Connect also provides claims > about the user. > > > I=E2=80=99m coming around to this view, but I would still like it to be s= eparate. > What does separate mean? > > > >> If we do decide it=E2=80=99s in scope, then I think it should be clearly= layered >> on top of the authorization layer. >> > > Being layered on top is confusing. An OpenID Connect flow where the Clien= t > receives an ID token, has not authorization, unless you are counting the = UX > as authorization -- but that does not seem like a layer. Would you > elaborate? > > > > What you=E2=80=99re doing in OIDC is authorizing the application to know = who you > are =E2=80=94 to get your identity information. That key insight is what = makes the > combination of OAuth and OIDC work as well as it does. And, importantly, > once you authorize identity access, you can authorize other stuff as well= . > As I stated, there is the UX of authorizing knowing who the user is, but there is no artifact representing that authorization as there is in OAuth -- ie there is no access token to access a resource. (yes, an access token may be used to read the user info endpoint, but that is all it can do. > And it=E2=80=99s the =E2=80=9Cand other stuff=E2=80=9D that people really= , really, really like > about OIDC. Nobody ever wants just authorization, in practice. > Did you mean to say "authentication"? If so, then I would posit that there are more OIDC user interactions than plain OAuth 2.0 user interactions, and that almost all of those OIDC user interactions are just logging in with Google or Facebook -- and that there is no "and other stuff". > > >> >> 4. When you say "not backwards compatible with OAuth 2.0 and its >> extensions", do you expect to define a new standard to replace RFC 6750? >> Developers will have to have a new method to call APIs? >> >> >> Kinda. First, it=E2=80=99s more 6749 that I want to step away from. But = even >> then, I think keeping just the header version of 6750 is OK enough if >> someone wants to keep using that. The thing is, won=E2=80=99t someone se= eing an >> OAuth 2 header assume the rest of OAuth 2 infrastructure? In some cases >> this won=E2=80=99t matter, but in many that could be really confusing. >> >> One of the problems, though, is that 6750 has already been clouded by >> things like the MTLS binding, where they use =E2=80=9Cbearer=E2=80=9D to= kens that have to >> be bound to the client=E2=80=99s certificate. So =E2=80=A6 not much of a= bearer token >> anymore. >> > > So, are you are you proposing that Tx have a new mechanism for API calls? > > > Yes, I think there will be new mechanisms for different kinds of key-boun= d > tokens. > So are you proposing that OAuth 3.0 will not support bearer tokens? > > > >> >> Ultimately, I don=E2=80=99t want anything that has an error-fallthrough >> compatibility process. That is to say, I try doing OAuth 2, have that fa= il, >> and then try it as OAuth 3 =E2=80=94 or vice versa. >> > > Ok. I'm not even sure how that would happen, but ok. > > > So in OAuth 2 the token parameter was originally called =E2=80=9Coauth_to= ken=E2=80=9D, > which is the same as in OAuth 1. But the difference is that in OAuth 2 > there=E2=80=99s no =E2=80=9Coauth_token_signature=E2=80=9D field, so to s= upport both you=E2=80=99d need to > try to do OAuth 1, then fail, and then try to do OAuth 2. Since the natur= e > of the tokens is completely different, I see that as a problem. > > However, with this (and with how XYZ=E2=80=99s started things), we=E2=80= =99ve got an > opportunity to say things like =E2=80=9Cif you see this type of token res= ponse, use > it with the RS according to RFC6750=E2=80=9D or =E2=80=9Caccording to thi= s new RFC we just > made up=E2=80=9D or whatever. > Got it. Agreed that we can provide a richer response that indicates how a token (or whatever) can be used. --000000000000fb6d55059af44e34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Dec 28, 2019= at 9:17 AM Justin Richer <jricher@mi= t.edu> wrote:
1. What is meant by "Delegation betwee= n multiple users=E2=80=9D ?

See above.

I sti= ll don't understand. Is one user delegating to another user? This is a = desirable use case for many, but currently not standardized. Is this what y= ou are proposing is in scope?
=C2=A0

I=E2=80=99m proposing that in our model, the pe= rson using the client application and the person approving the process can = be different parties, depending on the nature of interaction that the clien= t is capable of. Again, this goes into the different roles that people play= . I do think that this is in scope, with the condition that in the case whe= re they=E2=80=99r the same person (IE, the OAuth case), this collapses clea= nly into a simpler case. UMA doesn=E2=80=99t do that very well, because of = the nature of OAuth=E2=80=99s redirect-first model. We can do better here.<= /div>

Got it. Thanks for clarif= ying.=C2=A0

<= div dir=3D"ltr">


2. Why do you restrict this to HT= TP?

Because I want = us to use all of the features and benefits of HTTP instead of having to inv= ent within-protocol functions to replicate them. I don=E2=80=99t want SOAP,= which pretends to be transport agnostic much to its detriment. If someone = wants to do OAuth 3 on not-HTTP, they can define what that looks like. This= is what happened with the COAP/CORE stuff and OAuth 2.

I agree SOAP was complicated. Which features= and benefits of HTTP are you wanting to use?=C2=A0


Well so far we=E2=80=99ve g= ot headers, URLs, methods, data payload types, and the whole array of techn= ologies that we can rely on working together along with HTTP.

But which ones do you want to use?
=C2=A0


If it was = simple to support COAP, why would we not do that?

Because it=E2=80=99s not just COAP =E2=80=94= you=E2=80=99ve got a different set of assumptions for the lower layer prot= ocols, and you=E2=80=99ve got lots of considerations about how the differen= t components can talk to each other in the embedded space.=C2=A0

You are suggesting we rule out it w= orking with COAP in the charter, before we have even had a chance to work o= n it.

Perhaps it will be trivial to support COAP. = We won't know if the charter forbids it.
=C2=A0

In my experience, it=E2=80=99s much more = successful to have a protocol strongly integrated with its transport mechan= ism and then translated out to other mechanisms, instead of trying to come = up with one universal interlingua of a protocol that just get shunted along= .

Would you provide an e= xample besides SOAP for this?
=C2=A0
<= div>This is why SOAP can=E2=80=99t use HTTP verbs to communicate things, an= d why the only signatures it can use are internal. When you do that kind of= system, you almost always end up having people just use it with one transp= ort anyway, like SOAP over HTTP.

=C2=A0

<= div>

3. Why is authent= ication not in scope?

It felt, to me, like that might be a bridge too far.
<= /blockquote>

I disagree. But I also think that authentic= ation is the wrong term. Identity* may be a term that maps better, as the C= lient is wanting to get "identity" data from the AS.=C2=A0
<= div>
* The identity term is super confusing, but authenticati= on implies just knowing it is the same user, where OpenID Connect also prov= ides claims about the user.

I=E2=80=99m coming around to this view, but I would still like it = to be separate.

What does= separate mean?
=C2=A0

=C2=A0=
If w= e do decide it=E2=80=99s in scope, then I think it should be clearly layere= d on top of the authorization layer.=C2=A0

Being layered on top is confusing. An OpenID Connect flow= where the Client receives an ID token, has not authorization, unless you a= re counting the UX as authorization -- but that does not seem like a layer.= Would you elaborate?
=C2=A0
=

What you=E2=80=99re doing in OIDC is authorizing the ap= plication to know who you are =E2=80=94 to get your identity information. T= hat key insight is what makes the combination of OAuth and OIDC work as wel= l as it does. And, importantly, once you authorize identity access, you can= authorize other stuff as well.


As I stated, there is the UX of authorizing knowing w= ho the user is, but there is no artifact representing that authorization as= there is in OAuth -- ie there is no access token to access a resource. (ye= s, an access token may be used to read the user info endpoint, but that is = all it can do.=C2=A0
=C2=A0
And = it=E2=80=99s the =E2=80=9Cand other stuff=E2=80=9D that people really, real= ly, really like about OIDC. Nobody ever wants just authorization, in practi= ce.=C2=A0

Did you mean to= say "authentication"?

If so, then I wou= ld posit that there are more OIDC user interactions than plain OAuth 2.0 us= er interactions, and that almost all of those OIDC user interactions are ju= st logging in with Google or Facebook -- and that there is no "and oth= er stuff".


=C2=A0
= =C2=A0


=

4. When you say "not backwards co= mpatible with OAuth 2.0 and its extensions", do you expect to define a= new standard to replace RFC 6750? Developers will have to have a new metho= d to call APIs?

Kin= da. First, it=E2=80=99s more 6749 that I want to step away from. But even t= hen, I think keeping just the header version of 6750 is OK enough if someon= e wants to keep using that. The thing is, won=E2=80=99t someone seeing an O= Auth 2 header assume the rest of OAuth 2 infrastructure? In some cases this= won=E2=80=99t matter, but in many that could be really confusing.=C2=A0

One of the problems, though, is that 6750 has alread= y been clouded by things like the MTLS binding, where they use =E2=80=9Cbea= rer=E2=80=9D tokens that have to be bound to the client=E2=80=99s certifica= te. So =E2=80=A6 not much of a bearer token anymore.

So, are you are you proposing that Tx have a ne= w mechanism for API calls?

Yes, I think there will be new mechanisms for different kinds of ke= y-bound tokens.

So are yo= u proposing that OAuth 3.0 will not support bearer tokens?
=C2=A0=

=C2=A0

Ultimately, I don=E2= =80=99t want anything that has an error-fallthrough compatibility process. = That is to say, I try doing OAuth 2, have that fail, and then try it as OAu= th 3 =E2=80=94 or vice versa.

=
Ok. I'm not even sure how that would happen, but ok.

So in OAuth 2 the token paramete= r was originally called =E2=80=9Coauth_token=E2=80=9D, which is the same as= in OAuth 1. But the difference is that in OAuth 2 there=E2=80=99s no =E2= =80=9Coauth_token_signature=E2=80=9D field, so to support both you=E2=80=99= d need to try to do OAuth 1, then fail, and then try to do OAuth 2. Since t= he nature of the tokens is completely different, I see that as a problem.

However, with this (and with how XYZ=E2=80=99s star= ted things), we=E2=80=99ve got an opportunity to say things like =E2=80=9Ci= f you see this type of token response, use it with the RS according to RFC6= 750=E2=80=9D or =E2=80=9Caccording to this new RFC we just made up=E2=80=9D= or whatever.

Got it. Agr= eed that we can provide a richer response that indicates how a token (or wh= atever) can be used.
=C2=A0
--000000000000fb6d55059af44e34-- From nobody Mon Dec 30 16:20:47 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0631200C1 for ; Mon, 30 Dec 2019 16:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 5ANxqADZF-ch for ; Mon, 30 Dec 2019 16:20:43 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 8615212002E for ; Mon, 30 Dec 2019 16:20:43 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id l2so34912934lja.6 for ; Mon, 30 Dec 2019 16:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Ue/6aLCeVehTvEjev+sZ5/WVv3NOb5YncZg0l1QhnZc=; b=rC0iDx7tKaGwPEf08VJMUy2tprv/R3QJAXqHVpbVW4J4PDXDmltfpG6WvAFKO/iGFT tjjwdF0CnYAjvhPmmyVQfZg3vNVZk8ZnCmhwfPmw0y4Wg5QBote0wn9TmRCaYLbXJUS+ it1JOHYp0xxk9JYB4syS4axKsc4YcOCqBx8lqj58CbN9GOdhOkS2yCG02gl3lPd6KD8x jmhXv1Un71Q42BQG0UUsY9njKcNz5s9/EZthdUd1Y+jGJy8rEufxAo/J1htXUTOoqxjv CMZS9MnglPiJpfs6z+IMs1NDzkA2Ns+rc0wiXBxus0IZzpihmVL79/gmT541weXaJYtZ wenQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ue/6aLCeVehTvEjev+sZ5/WVv3NOb5YncZg0l1QhnZc=; b=JEPXL/gVBece7Jig7YEhuGjfHSszu63Wl4y4oHtnEPg8GnUVqQvtu25ukwCEQR1BCu 4RBWsuDLu142+85nL1d7OaJOsJN+1skio1QpygyXK5SwA4X73FKGWGRf+7jLayRM+2Zu ZNcFogtlbBil0QsX0sMJI3He3v77X6hYhjEgZG/ejV2/VN/+iOHl+Xn/xmMVyBfGhXKZ axGVXgpchY0ys8n91Aqr/ii0n4L9nN96OyGD0EfvrGvU8rcdbINEgfVsNXJ1CdFuq4Dp Ec4jyyipQj6Nl74z683Wv6sGsr55pf0x37VGpAD9/5mNOmw1S6e+wqKSPsjH+Yz8lIVX kcYg== X-Gm-Message-State: APjAAAXYKS5AsRcodvYpo8Vf3dm1NaPEZOIw7oeCsu5fPEdP87jKLPap UhgVGvuq2ETpMhfr+9YG59bZQuP+Ge8oJFZODYX0NshG X-Google-Smtp-Source: APXvYqw1+VU1BlnyYtNxJ/K7n15kASLQptLZaE2TCyXrkcMgdLtQ4bqEk0FXJZSfcxAJiPLEphGDsyGGgFlvJMGDM9M= X-Received: by 2002:a2e:a48a:: with SMTP id h10mr40530433lji.254.1577751641552; Mon, 30 Dec 2019 16:20:41 -0800 (PST) MIME-Version: 1.0 From: Dick Hardt Date: Mon, 30 Dec 2019 16:20:30 -0800 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000237c22059af4ee62" Archived-At: Subject: [Txauth] Framework vs Protocol X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 00:20:46 -0000 --000000000000237c22059af4ee62 Content-Type: text/plain; charset="UTF-8" I would propose that the resulting work is a protocol, and not a framework. What is the difference? Here are my thoughts: A framework defines a variety of ways to do each capability. A framework usually needs a profile for two systems to interoperate. For example, OIDC provides a number of ways to get identity data from an OP, and OAuth 2 grant types have overlap. A framework is like Perl. Lots of ways to do the same thing, many of which are unreadable. A protocol provides one way to do each capability. A protocol is like Python, there is a right way to do something. At times a standards group will get "consensus" by not being decisive, and including everyone's favored mechanism. In my opinion, this makes deployments more complicated for average developers, and increases the surface area to secure. Do others agree with adding this as a tenet to the charter? /Dick Note: I'm a fan of both Perl and Python. =) --000000000000237c22059af4ee62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would propose that the resulting work is a protocol, and= not a framework.

What is the difference? Here are my=C2= =A0thoughts:

A framework defines a variety of ways= to do each capability. A framework usually needs a profile for two systems= to interoperate. For example, OIDC provides a number of ways to get identi= ty data from an OP, and OAuth 2 grant types have overlap. A framework is li= ke Perl. Lots of ways to do the same thing, many of which are unreadable.

A protocol provides one way to do each capability.= =C2=A0 A protocol is like Python, there is a right way to do something.

At times a standards group will get "consensus&q= uot; by not being decisive, and including everyone's favored mechanism.= In my opinion, this makes deployments more complicated for average develop= ers, and increases the surface area to secure.

Do = others agree with adding this as a tenet to the charter?

/Dick

Note: I'm a fan of both Perl and = Python. =3D)

--000000000000237c22059af4ee62-- From nobody Tue Dec 31 05:06:35 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C86120024 for ; Tue, 31 Dec 2019 05:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Mf9CQy6xCI55 for ; Tue, 31 Dec 2019 05:06:31 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4D85C120013 for ; Tue, 31 Dec 2019 05:06:31 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBVD6SjX015974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Dec 2019 08:06:29 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Justin Richer In-Reply-To: Date: Tue, 31 Dec 2019 08:06:28 -0500 Cc: txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dick Hardt X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Framework vs Protocol X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 13:06:33 -0000 I agree with this. I think that with OAuth2 the extension mechanism of = grant types was a decent idea, and I=E2=80=99ve argued that it leads to = significant amounts of code-reuse from very different systems that = function in very different ways.=20 But I also think that what I=E2=80=99d like to see here, and what I=E2=80=99= ve tried to do with XYZ, is to have one protocol that lets you branch = off for different use cases where necessary but still brings you back to = the same process in the end. This is one of the things I like about = having the AS defined as the transaction endpoint =E2=80=94 everyone = goes to one place and sends one kind of message to start things off, and = then you have everything you need to figure out where to go from there, = even if it=E2=80=99s off-HTTP and out-of-band.=20 =E2=80=94 Justin > On Dec 30, 2019, at 7:20 PM, Dick Hardt wrote: >=20 > I would propose that the resulting work is a protocol, and not a = framework. >=20 > What is the difference? Here are my thoughts: >=20 > A framework defines a variety of ways to do each capability. A = framework usually needs a profile for two systems to interoperate. For = example, OIDC provides a number of ways to get identity data from an OP, = and OAuth 2 grant types have overlap. A framework is like Perl. Lots of = ways to do the same thing, many of which are unreadable. >=20 > A protocol provides one way to do each capability. A protocol is like = Python, there is a right way to do something. >=20 > At times a standards group will get "consensus" by not being decisive, = and including everyone's favored mechanism. In my opinion, this makes = deployments more complicated for average developers, and increases the = surface area to secure. >=20 > Do others agree with adding this as a tenet to the charter? >=20 > /Dick >=20 > Note: I'm a fan of both Perl and Python. =3D) >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Tue Dec 31 05:09:54 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E5B120048 for ; Tue, 31 Dec 2019 05:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ejGjZU2KwYY6 for ; Tue, 31 Dec 2019 05:09:49 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 0F35C120024 for ; Tue, 31 Dec 2019 05:09:48 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBVD9fMK016580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Dec 2019 08:09:42 -0500 From: Justin Richer Message-Id: <0AB6001B-43AF-42F1-87CA-BE621DEBE0FB@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_33202A69-6A23-4A0F-8DED-45EE41605124" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 31 Dec 2019 08:09:41 -0500 In-Reply-To: Cc: Brian Campbell , "rdd@cert.org" , Yaron Sheffer , Benjamin Kaduk , Aaron Parecki , txauth@ietf.org To: Dick Hardt References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 13:09:53 -0000 --Apple-Mail=_33202A69-6A23-4A0F-8DED-45EE41605124 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My understanding is that HTTP3 is not backwards compatible, since QUIC = was built on UDP from the start and the considerations are pretty = different from TCP there.=20 I don=E2=80=99t think the safe answer is =E2=80=9Cdo nothing=E2=80=9D = today because there is a large and vibrant community around OAuth 2. The = safe answer is to deploy something that solves your problems. I think that we=E2=80=99re going to have the imaging issue vis a vis = =E2=80=9Creplacing OAuth 2=E2=80=9D whether we call this OAuth 3 or = TxAuth or whatever. Truth is for some people we will be replacing OAuth = 2, and some people will be throwing out their OAuth 2 implementations = (if we=E2=80=99re successful). But that=E2=80=99s the cost of tracking = new technology, and it=E2=80=99s pretty clear to me that this work has a = long ways to go. =E2=80=94 Justin > On Dec 30, 2019, at 6:25 PM, Dick Hardt wrote: >=20 > I significant difference in this case is that OAuth 3 is NOT backward = compatible with OAuth 2. >=20 > HTTP 2 was backwards compatible, as is HTTP 3 from what I understand. >=20 > This has enterprises question what they should do, and the safe answer = is do nothing. I think this is what Brian was getting at on confusion. = People are confused on what they should do. OAuth 3 not being backward = compatible implies work done with OAuth 2 may have to be thrown away. >=20 >=20 > On Sat, Dec 28, 2019 at 9:07 AM Justin Richer > wrote: > This is going to be the case whatever we call this new work. Progress = is going to continue to happen, and if a large enterprise decides to = wait for the new shiny thing 3 years from now, then that=E2=80=99s on = them.=20 >=20 > In my experience, it=E2=80=99s more likely that a large enterprise is = going to shy away from the new shiny thing and go with what they can buy = in a supported package off the shelf. And I think that=E2=80=99s the = kind of timescale that=E2=80=99s going to drive most of the developers = decisions around whether to track the new work or use what=E2=80=99s out = there =E2=80=94 they need to ask =E2=80=9Cwhat do I need?=E2=80=9D And = =E2=80=9Cwhen do I need it?=E2=80=9D >=20 > But these are :always: the questions that you need to ask when = starting a project and choosing technologies.=20 >=20 > I still contend that the name OAuth 3 does a better job at = communicating what=E2=80=99s going on here. >=20 > =E2=80=94 Justin >=20 >> On Dec 27, 2019, at 1:27 PM, Dick Hardt > wrote: >>=20 >> I agree with Brian. Developers such as large enterprise customers are = going to be confused when they hear there is an OAuth 3 in the works. = Some will push pause on projects because they worry that it will be = outdated when it is released. They won't know which to deploy, even = though OAuth 3 is not available.=20 >>=20 >> Also, if what we are working on includes authentication / identity -- = it no longer is just delegated authorization >>=20 >> See inline comments below. >>=20 >>=20 >> On Tue, Dec 24, 2019 at 4:22 PM Justin Richer > wrote: >> Brian, I hear what you=E2=80=99re saying, but I disagree completely. >>=20 >> Who would be confused by seeing a major revision to an existing = protocol that worked in a different way and did the same things but also = new things? That happens all the time. >>=20 >> And it causes market confusion all the time. Conservative = organizations stop doing things when it is not clear what the future = will be. >> =20 >>=20 >> Was there significant confusion between OAuth 1 and 2, enough to = hamper adoption of either? For the people who deeply invested in OAuth 1 = and didn=E2=80=99t need or want the OAuth 2 newness, they stuck with it = (see: twitter).=20 >>=20 >> Twitter stuck with OAuth 1 because they did not like bearer tokens.=20= >>=20 >> Yes, there was lots of confusion between OAuth 1 and 2. Erin did not = want what became OAuth 2 to be called OAuth because of the confusion. = Hence it was called WRAP early. The actual name of the WG is "Web = Authorization Protocol" >>=20 >> =20 >>=20 >> Was OpenID Connect a major disservice to OpenID 2? It was a = disruption, for sure, but people transitioned where it made sense for = them, and in many cases that took years of dual-deployment and = transition.=20 >>=20 >> The work that was being done on OpenID 3 was killed because a large = platform company that starts with G did not want to confuse their = customers about a new version. >> =20 >>=20 >> I see us walking along the same kind of path here, nearly a decade = later. That=E2=80=99s why I think OAuth 3 makes sense as a name for the = output of this work. Or at the very least, for the core delegation = protocol portion of whatever we make. I think it sends the right message = to implementers and developers: the community that knows and understands = OAuth 2 is working on the next version of that thing, so when it=E2=80=99s= ready, maybe you should look at it. Until it=E2=80=99s done, and for a = long time after, OAuth 2 is still going to be there and be the right = answer.=20 >>=20 >> I agree that people may be confused if it is called something else = that OAuth, but if it is broader than OAuth, then that is confusing as = well. >> =20 >>=20 >> The name isn=E2=80=99t a hill I=E2=80=99m committed to dying alone = on, but I think it sends a :bad: message if we call it something new = entirely. Namely, that we think people :should: abandon the entire world = of OAuth, all of its ideas and implementations. That=E2=80=99s not what = we=E2=80=99re doing with this design, it=E2=80=99s an evolution as I see = things. And as an evolution, a new major revision number makes sense. >>=20 >> =E2=80=94 Justin >>=20 >>> On Dec 24, 2019, at 9:54 AM, Brian Campbell = > wrote: >>>=20 >>> Naming any prospective resulting work here "OAuth 3.0" would = significantly exacerbate confusion in the whole space and would be a = major disservice to the broader community.=20 >>>=20 >>>=20 >>> On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki > wrote: >>> I definitely am not trying to discuss specifics of *how* = authentication should be included right now, but I just want to make = sure it's included in the charter so that we can actually talk about it = and it won't be "out of scope" when we eventually do talk about the = specifics. >>>=20 >>> Aaron >>>=20 >>>=20 >>>=20 >>> On Mon, Dec 23, 2019 at 1:51 PM Justin Richer > wrote: >>> I=E2=80=99m fine with it being in charter but I do think it should = be a clearly separate layer, much like OIDC/Facebook Connect/GitHub = Login/etc are with OAuth today. In all of these the authorization is = first, and I think that=E2=80=99s the right pattern. So if we do take it = on we=E2=80=99ll just need to be careful how it=E2=80=99s structured in = with everything else. Otherwise, I think the authentication side can = quickly overwhelm and drag down the authorization side. >>>=20 >>> Good news: A lot of the additional stuff in OIDC is there to patch = holes in core OAuth in a common fashion, and we=E2=80=99ll at least be = in a position to not have to do that again.=20 >>>=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Dec 22, 2019, at 10:46 PM, Aaron Parecki > wrote: >>>>=20 >>>> I do think authentication should be part of the charter from the = outset. Frankly the fact that authentication is intentionally left out = of OAuth and has to be bolted on to the side via OpenID Connect is one = of the exact reasons people get confused about the whole space to begin = with.=20 >>>>=20 >>>> It's a relatively minor addition to the existing proposed spec to = make it useful as a minimum viable authentication solution, and I'd like = to see that be addressed at the beginning of this work. >>>>=20 >>>> I think we can do this in a smart way and that authentication = should be included in the charter. >>>>=20 >>>> Aaron >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer = > wrote: >>>> Hi Justin, >>>>=20 >>>> =20 >>>>=20 >>>> I think the charter should mention target use cases. For example, = =E2=80=9Call use cases supported by OAuth 2 will be supported by the new = protocol=E2=80=9D or =E2=80=9Cthe protocol will support at least use = cases X and Y=E2=80=9D. >>>>=20 >>>> =20 >>>>=20 >>>> And given the importance of OIDC, we could say something like: = =E2=80=9CThe protocol will allow future extension to support = authentication, in an analogous way to OpenID Connect. However = authentication is explicitly not part of the initial scope.=E2=80=9D >>>>=20 >>>> =20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Yaron >>>>=20 >>>> =20 >>>>=20 >>>> From: Txauth > on behalf of Justin Richer = > >>>> Date: Saturday, December 21, 2019 at 00:34 >>>> To: > >>>> Cc: "rdd@cert.org " >, Benjamin Kaduk > >>>> Subject: [Txauth] TxAuth Proposed Charter >>>>=20 >>>> =20 >>>>=20 >>>> Hi all, >>>>=20 >>>> =20 >>>>=20 >>>> As discussed in Singapore, no matter what forum TxAuth takes, its = work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of time to put together a proposed charter text for the TxAuth work: >>>>=20 >>>> =20 >>>>=20 >>>> This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 >>>>=20 >>>> =20 >>>>=20 >>>> The group will deliver a protocol specification detailing how a = client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>>>=20 >>>> =20 >>>>=20 >>>> Additionally, the delegation process will allow for: >>>>=20 >>>> - Fine-grained specification of resource access >>>>=20 >>>> - Delegation between multiple users >>>>=20 >>>> - Web, mobile, single-page, and other client applications >>>>=20 >>>> =20 >>>>=20 >>>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>>=20 >>>> =20 >>>>=20 >>>> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >>>>=20 >>>> - User interaction mechanisms including web and non-web methods >>>>=20 >>>> - Token presentation mechanisms and key bindings >>>>=20 >>>> =20 >>>>=20 >>>> The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >>>>=20 >>>> =20 >>>>=20 >>>> While this work could be done in within the OAuth working group, I = now believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>>>=20 >>>> =20 >>>>=20 >>>> Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing = world. I plan to be engaged in both groups, and I know most of you are = as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>>>=20 >>>> =20 >>>>=20 >>>> I=E2=80=99ve published a blog post detailing more of my rationale: >>>>=20 >>>> =20 >>>>=20 >>>> = https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-worki= ng-group-d6229ba8e36? = >>>> =20 >>>>=20 >>>> Please suggest changes to the proposed charter text above. It=E2=80=99= s my hope that we can get the chartering process started. >>>>=20 >>>> =20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>> -- Txauth mailing list Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth = --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>> --=20 >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> @aaronpk >>>>=20 >>>=20 >>> --=20 >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>>=20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>>=20 >>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_33202A69-6A23-4A0F-8DED-45EE41605124 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = understanding is that HTTP3 is not backwards compatible, since QUIC was = built on UDP from the start and the considerations are pretty different = from TCP there. 

I don=E2=80=99t think the safe answer is =E2=80=9Cdo = nothing=E2=80=9D today because there is a large and vibrant community = around OAuth 2. The safe answer is to deploy something that solves your = problems.

I = think that we=E2=80=99re going to have the imaging issue vis a vis = =E2=80=9Creplacing OAuth 2=E2=80=9D whether we call this OAuth 3 or = TxAuth or whatever. Truth is for some people we will be replacing OAuth = 2, and some people will be throwing out their OAuth 2 implementations = (if we=E2=80=99re successful). But that=E2=80=99s the cost of tracking = new technology, and it=E2=80=99s pretty clear to me that this work has a = long ways to go.

 =E2=80=94 Justin

On Dec = 30, 2019, at 6:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I significant difference in this = case is that OAuth 3 is NOT backward compatible with OAuth 2.

HTTP 2 was backwards = compatible, as is HTTP 3 from what I understand.

This has enterprises question what they = should do, and the safe answer is do nothing. I think this is what Brian = was getting at on confusion. People are confused on what they should do. = OAuth 3 not being backward compatible implies work done with OAuth 2 may = have to be thrown away.


On Sat, Dec 28, 2019 at 9:07 AM Justin = Richer <jricher@mit.edu> wrote:
This is going to be the case whatever we call = this new work. Progress is going to continue to happen, and if a large = enterprise decides to wait for the new shiny thing 3 years from now, = then that=E2=80=99s on them. 

In my experience, it=E2=80=99s more = likely that a large enterprise is going to shy away from the new shiny = thing and go with what they can buy in a supported package off the = shelf. And I think that=E2=80=99s the kind of timescale that=E2=80=99s = going to drive most of the developers decisions around whether to track = the new work or use what=E2=80=99s out there =E2=80=94 they need to ask = =E2=80=9Cwhat do I need?=E2=80=9D And =E2=80=9Cwhen do I need = it?=E2=80=9D

But= these are :always: the questions that you need to ask when starting a = project and choosing technologies. 

I still contend that the name OAuth 3 = does a better job at communicating what=E2=80=99s going on = here.

 =E2=80= =94 Justin

On Dec 27, 2019, at 1:27 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

I agree with Brian. Developers such as large = enterprise customers are going to be confused when they hear there = is an OAuth 3 in the works. Some will push pause on projects because = they worry that it will be outdated when it is released. They won't know = which to deploy, even though OAuth 3 is not available. 

Also, if what we are = working on includes authentication / identity -- it no longer is just = delegated authorization

See inline comments below.


On Tue, Dec = 24, 2019 at 4:22 PM Justin Richer <jricher@mit.edu> wrote:
Brian, I hear what = you=E2=80=99re saying, but I disagree completely.

Who would be confused by seeing a major = revision to an existing protocol that worked in a different way and did = the same things but also new things? That happens all the = time.

And it causes market confusion all the time. Conservative = organizations stop doing things when it is not clear what the future = will be.
 

Was there significant = confusion between OAuth 1 and 2, enough to hamper adoption of either? = For the people who deeply invested in OAuth 1 and didn=E2=80=99t need or = want the OAuth 2 newness, they stuck with it (see: = twitter). 

Twitter stuck with OAuth 1 because they = did not like bearer tokens. 

Yes, there was lots of confusion = between OAuth 1 and 2. Erin did not want what became OAuth 2 to be = called OAuth because of the confusion. Hence it was called WRAP early. = The actual name of the WG is "Web Authorization Protocol"

 

Was OpenID Connect a = major disservice to OpenID 2? It was a disruption, for sure, but people = transitioned where it made sense for them, and in many cases that took = years of dual-deployment and = transition. 

The work that was being done on OpenID = 3 was killed because a large platform company that starts with G did not = want to confuse their customers about a new version.
 

I see us walking along the same kind of = path here, nearly a decade later. That=E2=80=99s why I think OAuth 3 = makes sense as a name for the output of this work. Or at the very least, = for the core delegation protocol portion of whatever we make. I think it = sends the right message to implementers and developers: the community = that knows and understands OAuth 2 is working on the next version of = that thing, so when it=E2=80=99s ready, maybe you should look at it. = Until it=E2=80=99s done, and for a long time after, OAuth 2 is still = going to be there and be the right = answer. 

I agree that people may be confused if = it is called something else that OAuth, but if it is broader than OAuth, = then that is confusing as well.
 

The name isn=E2=80=99t a hill I=E2=80=99m= committed to dying alone on, but I think it sends a :bad: message if we = call it something new entirely. Namely, that we think people :should: = abandon the entire world of OAuth, all of its ideas and implementations. = That=E2=80=99s not what we=E2=80=99re doing with this design, it=E2=80=99s= an evolution as I see things. And as an evolution, a new major revision = number makes sense.

 =E2=80=94 Justin

On Dec = 24, 2019, at 9:54 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Naming any prospective resulting work here "OAuth 3.0" would = significantly exacerbate confusion in the whole space and would be a = major disservice to the broader community.


On Mon, Dec = 23, 2019 at 7:39 PM Aaron Parecki <aaron@parecki.com> wrote:
I definitely am not trying to discuss specifics of *how* = authentication should be included right now, but I just want to make = sure it's included in the charter so that we can actually talk about it = and it won't be "out of scope" when we eventually do talk about the = specifics.

Aaron



On Mon, Dec = 23, 2019 at 1:51 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m fine with = it being in charter but I do think it should be a clearly separate = layer, much like OIDC/Facebook Connect/GitHub Login/etc are with OAuth = today. In all of these the authorization is first, and I think that=E2=80=99= s the right pattern. So if we do take it on we=E2=80=99ll just need to = be careful how it=E2=80=99s structured in with everything else. = Otherwise, I think the authentication side can quickly overwhelm and = drag down the authorization side.

Good news: A lot of the additional stuff in OIDC is there to = patch holes in core OAuth in a common fashion, and we=E2=80=99ll at = least be in a position to not have to do that = again. 


 =E2=80= =94 Justin

On Dec 22, 2019, at 10:46 PM, = Aaron Parecki <aaron@parecki.com> wrote:

I do think = authentication should be part of the charter from the outset. Frankly = the fact that authentication is intentionally left out of OAuth and has = to be bolted on to the side via OpenID Connect is one of the exact = reasons people get confused about the whole space to begin = with. 

It's a relatively minor = addition to the existing proposed spec to make it useful as a minimum = viable authentication solution, and I'd like to see that be addressed at = the beginning of this work.

I think we can do this in = a smart way and that authentication should be included in the = charter.

Aaron




On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

Hi Justin,

 

I think the charter should = mention target use cases. For example, =E2=80=9Call use cases supported = by OAuth 2 will be supported by the new protocol=E2=80=9D or =E2=80=9Cthe = protocol will support at least use cases X and Y=E2=80=9D.

 

And = given the importance of OIDC, we could say something like: =E2=80=9CThe = protocol will allow future extension to support authentication, in an = analogous way to OpenID Connect. However authentication is explicitly = not part of the initial scope.=E2=80=9D

 

Thanks,

         =        Yaron

 

From: = Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer = <jricher@mit.edu>
Date: = Saturday, December 21, 2019 at 00:34
To: = <txauth@ietf.org>
Cc: = "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>
Subject: = [Txauth] TxAuth Proposed Charter

 

Hi= all,

 

As = discussed in Singapore, no matter what forum TxAuth takes, its work will = require a new charter. With that in mind, I=E2=80=99ve taken a bit of = time to put together a proposed charter text for the TxAuth work:

 

This group is chartered to develop a next-generation = transactional authorization and delegation protocol for HTTP-based APIs = and their clients. These transactions will allow an authorizing party to = delegate a right of access for an API or set of APIs through an = authorization server to a software client acting on behalf of an = authorizing party. 

 

The = group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can = provide delegated access, how an authorized party can authorize = delegated access, and how that authorized access can be communicated to = the resources being protected. These actions will be connected through = an explicit transaction between the client and authorization server, = resulting in an artifact that will allow the client to undertake the = delegated action. 

 

Additionally, the delegation process will allow = for:

- Fine-grained specification of resource access

- Delegation between multiple users

- Web, mobile, single-page, and other client = applications

 

The = group will define extension points for this protocol to allow for = flexibility in areas including:

 

- Cryptographic agility for keys, message = signatures, and proof of possession 

- User = interaction mechanisms including web and non-web methods

- Token presentation mechanisms and key bindings

 

The = artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions. 

 

While = this work could be done in within the OAuth working group, I now believe = that it should be done in a new working group, and that we should try to = get that working group up and running prior to the Vancouver meeting in = March. I think this group should stay here on the TxAuth list, and = it=E2=80=99s my suggestion that the resulting work be called OAuth = 3.0. 

 

Why a = new group? I think that the OAuth working group should remain focused on = extending, patching, and adapting OAuth 2.0 to a changing world. I plan = to be engaged in both groups, and I know most of you are as well, but = that=E2=80=99s not universal. Since OAuth 2.0 is so established already, = there are a LOT of people who aren=E2=80=99t going to be interested in = something new any time soon. But on the other hand, there are a number = of people for whom OAuth 2.0 does not work, or is at the very least a = poor fit, and we=E2=80=99ll want to bring them in at this early stage. = So even with significant overlap, I think there=E2=80=99s enough = disconnect in the community from both sides that warrants a new group. = In addition, I think this is a big enough piece of work that it=E2=80=99s = simply too much for the OAuth working group to be able to focus on. We = wouldn=E2=80=99t be able to get additional meeting time, and OAuth = already has trouble fitting into its two meeting slots as it is.

 

I=E2=80=99= ve published a blog post detailing more of my rationale:

 

https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-= a-new-working-group-d6229ba8e36?

 

Please suggest changes to the proposed charter text = above. It=E2=80=99s my hope that we can get the chartering process = started.

 

 =E2=80= =94 Justin

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
----
Aaron = Parecki
aaronparecki.com
@aaronpk


--
----
Aaron Parecki
aaronparecki.com
@aaronpk

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=


= --Apple-Mail=_33202A69-6A23-4A0F-8DED-45EE41605124-- From nobody Tue Dec 31 10:37:10 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88144120046 for ; Tue, 31 Dec 2019 10:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PyUx-21QdZpX for ; Tue, 31 Dec 2019 10:37:04 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 822D412001A for ; Tue, 31 Dec 2019 10:37:03 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBVIatPR022231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Dec 2019 13:36:56 -0500 From: Justin Richer Message-Id: <5137E82A-F4F1-425F-9DCA-785B3927E509@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_1C82EFA6-CE2A-49EC-AD1D-344DC1C3FBE1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 31 Dec 2019 13:36:55 -0500 In-Reply-To: <0AB6001B-43AF-42F1-87CA-BE621DEBE0FB@mit.edu> Cc: "rdd@cert.org" , Aaron Parecki , Yaron Sheffer , Benjamin Kaduk , Brian Campbell , txauth@ietf.org To: Dick Hardt References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> <0AB6001B-43AF-42F1-87CA-BE621DEBE0FB@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 18:37:08 -0000 --Apple-Mail=_1C82EFA6-CE2A-49EC-AD1D-344DC1C3FBE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 And just to reiterate a previous point =E2=80=94 as much as I want to = make the case for calling this work OAuth 3, it=E2=80=99s not something = I=E2=80=99m going to die for. The work is way more important than the = name.=20 So with that, I would propose that we basically punt on naming things = until that becomes important. I say we name both the working group and = the first document =E2=80=9CTxAuth=E2=80=9D, and keep this mailing list = as its base. If the working group decides in a couple years that this really should = be renamed, we can do that. It=E2=80=99s happened before =E2=80=94 and = again I=E2=80=99m calling to the model of HTTP/3. It started as QUIC in = the QUIC working group, and a year ago the QUIC working group decided to = rename it to HTTP/3, with the coordination and blessing of the HTTP = working group. Once QUIC group winds down, the HTTP/3 protocol will come = under the stewardship of the HTTP working group. I can easily see a = similar pattern happening here, where we create TxAuth and eventually it = gets handed over to the OAuth WG. =E2=80=94 Justin > On Dec 31, 2019, at 8:09 AM, Justin Richer wrote: >=20 > My understanding is that HTTP3 is not backwards compatible, since QUIC = was built on UDP from the start and the considerations are pretty = different from TCP there.=20 >=20 > I don=E2=80=99t think the safe answer is =E2=80=9Cdo nothing=E2=80=9D = today because there is a large and vibrant community around OAuth 2. The = safe answer is to deploy something that solves your problems. >=20 > I think that we=E2=80=99re going to have the imaging issue vis a vis = =E2=80=9Creplacing OAuth 2=E2=80=9D whether we call this OAuth 3 or = TxAuth or whatever. Truth is for some people we will be replacing OAuth = 2, and some people will be throwing out their OAuth 2 implementations = (if we=E2=80=99re successful). But that=E2=80=99s the cost of tracking = new technology, and it=E2=80=99s pretty clear to me that this work has a = long ways to go. >=20 > =E2=80=94 Justin >=20 >> On Dec 30, 2019, at 6:25 PM, Dick Hardt > wrote: >>=20 >> I significant difference in this case is that OAuth 3 is NOT backward = compatible with OAuth 2. >>=20 >> HTTP 2 was backwards compatible, as is HTTP 3 from what I understand. >>=20 >> This has enterprises question what they should do, and the safe = answer is do nothing. I think this is what Brian was getting at on = confusion. People are confused on what they should do. OAuth 3 not being = backward compatible implies work done with OAuth 2 may have to be thrown = away. >>=20 >>=20 >> On Sat, Dec 28, 2019 at 9:07 AM Justin Richer > wrote: >> This is going to be the case whatever we call this new work. Progress = is going to continue to happen, and if a large enterprise decides to = wait for the new shiny thing 3 years from now, then that=E2=80=99s on = them.=20 >>=20 >> In my experience, it=E2=80=99s more likely that a large enterprise is = going to shy away from the new shiny thing and go with what they can buy = in a supported package off the shelf. And I think that=E2=80=99s the = kind of timescale that=E2=80=99s going to drive most of the developers = decisions around whether to track the new work or use what=E2=80=99s out = there =E2=80=94 they need to ask =E2=80=9Cwhat do I need?=E2=80=9D And = =E2=80=9Cwhen do I need it?=E2=80=9D >>=20 >> But these are :always: the questions that you need to ask when = starting a project and choosing technologies.=20 >>=20 >> I still contend that the name OAuth 3 does a better job at = communicating what=E2=80=99s going on here. >>=20 >> =E2=80=94 Justin >>=20 >>> On Dec 27, 2019, at 1:27 PM, Dick Hardt > wrote: >>>=20 >>> I agree with Brian. Developers such as large enterprise customers = are going to be confused when they hear there is an OAuth 3 in the = works. Some will push pause on projects because they worry that it will = be outdated when it is released. They won't know which to deploy, even = though OAuth 3 is not available.=20 >>>=20 >>> Also, if what we are working on includes authentication / identity = -- it no longer is just delegated authorization >>>=20 >>> See inline comments below. >>>=20 >>>=20 >>> On Tue, Dec 24, 2019 at 4:22 PM Justin Richer > wrote: >>> Brian, I hear what you=E2=80=99re saying, but I disagree completely. >>>=20 >>> Who would be confused by seeing a major revision to an existing = protocol that worked in a different way and did the same things but also = new things? That happens all the time. >>>=20 >>> And it causes market confusion all the time. Conservative = organizations stop doing things when it is not clear what the future = will be. >>> =20 >>>=20 >>> Was there significant confusion between OAuth 1 and 2, enough to = hamper adoption of either? For the people who deeply invested in OAuth 1 = and didn=E2=80=99t need or want the OAuth 2 newness, they stuck with it = (see: twitter).=20 >>>=20 >>> Twitter stuck with OAuth 1 because they did not like bearer tokens.=20= >>>=20 >>> Yes, there was lots of confusion between OAuth 1 and 2. Erin did not = want what became OAuth 2 to be called OAuth because of the confusion. = Hence it was called WRAP early. The actual name of the WG is "Web = Authorization Protocol" >>>=20 >>> =20 >>>=20 >>> Was OpenID Connect a major disservice to OpenID 2? It was a = disruption, for sure, but people transitioned where it made sense for = them, and in many cases that took years of dual-deployment and = transition.=20 >>>=20 >>> The work that was being done on OpenID 3 was killed because a large = platform company that starts with G did not want to confuse their = customers about a new version. >>> =20 >>>=20 >>> I see us walking along the same kind of path here, nearly a decade = later. That=E2=80=99s why I think OAuth 3 makes sense as a name for the = output of this work. Or at the very least, for the core delegation = protocol portion of whatever we make. I think it sends the right message = to implementers and developers: the community that knows and understands = OAuth 2 is working on the next version of that thing, so when it=E2=80=99s= ready, maybe you should look at it. Until it=E2=80=99s done, and for a = long time after, OAuth 2 is still going to be there and be the right = answer.=20 >>>=20 >>> I agree that people may be confused if it is called something else = that OAuth, but if it is broader than OAuth, then that is confusing as = well. >>> =20 >>>=20 >>> The name isn=E2=80=99t a hill I=E2=80=99m committed to dying alone = on, but I think it sends a :bad: message if we call it something new = entirely. Namely, that we think people :should: abandon the entire world = of OAuth, all of its ideas and implementations. That=E2=80=99s not what = we=E2=80=99re doing with this design, it=E2=80=99s an evolution as I see = things. And as an evolution, a new major revision number makes sense. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Dec 24, 2019, at 9:54 AM, Brian Campbell = > wrote: >>>>=20 >>>> Naming any prospective resulting work here "OAuth 3.0" would = significantly exacerbate confusion in the whole space and would be a = major disservice to the broader community.=20 >>>>=20 >>>>=20 >>>> On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki > wrote: >>>> I definitely am not trying to discuss specifics of *how* = authentication should be included right now, but I just want to make = sure it's included in the charter so that we can actually talk about it = and it won't be "out of scope" when we eventually do talk about the = specifics. >>>>=20 >>>> Aaron >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Dec 23, 2019 at 1:51 PM Justin Richer > wrote: >>>> I=E2=80=99m fine with it being in charter but I do think it should = be a clearly separate layer, much like OIDC/Facebook Connect/GitHub = Login/etc are with OAuth today. In all of these the authorization is = first, and I think that=E2=80=99s the right pattern. So if we do take it = on we=E2=80=99ll just need to be careful how it=E2=80=99s structured in = with everything else. Otherwise, I think the authentication side can = quickly overwhelm and drag down the authorization side. >>>>=20 >>>> Good news: A lot of the additional stuff in OIDC is there to patch = holes in core OAuth in a common fashion, and we=E2=80=99ll at least be = in a position to not have to do that again.=20 >>>>=20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>> On Dec 22, 2019, at 10:46 PM, Aaron Parecki > wrote: >>>>>=20 >>>>> I do think authentication should be part of the charter from the = outset. Frankly the fact that authentication is intentionally left out = of OAuth and has to be bolted on to the side via OpenID Connect is one = of the exact reasons people get confused about the whole space to begin = with.=20 >>>>>=20 >>>>> It's a relatively minor addition to the existing proposed spec to = make it useful as a minimum viable authentication solution, and I'd like = to see that be addressed at the beginning of this work. >>>>>=20 >>>>> I think we can do this in a smart way and that authentication = should be included in the charter. >>>>>=20 >>>>> Aaron >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer = > wrote: >>>>> Hi Justin, >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I think the charter should mention target use cases. For example, = =E2=80=9Call use cases supported by OAuth 2 will be supported by the new = protocol=E2=80=9D or =E2=80=9Cthe protocol will support at least use = cases X and Y=E2=80=9D. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> And given the importance of OIDC, we could say something like: = =E2=80=9CThe protocol will allow future extension to support = authentication, in an analogous way to OpenID Connect. However = authentication is explicitly not part of the initial scope.=E2=80=9D >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Yaron >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: Txauth > on behalf of Justin Richer = > >>>>> Date: Saturday, December 21, 2019 at 00:34 >>>>> To: > >>>>> Cc: "rdd@cert.org " >, Benjamin Kaduk > >>>>> Subject: [Txauth] TxAuth Proposed Charter >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> =20 >>>>>=20 >>>>> As discussed in Singapore, no matter what forum TxAuth takes, its = work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of time to put together a proposed charter text for the TxAuth work: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> This group is chartered to develop a next-generation transactional = authorization and delegation protocol for HTTP-based APIs and their = clients. These transactions will allow an authorizing party to delegate = a right of access for an API or set of APIs through an authorization = server to a software client acting on behalf of an authorizing party.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The group will deliver a protocol specification detailing how a = client can request and obtain delegated access, how an authorization = server can provide delegated access, how an authorized party can = authorize delegated access, and how that authorized access can be = communicated to the resources being protected. These actions will be = connected through an explicit transaction between the client and = authorization server, resulting in an artifact that will allow the = client to undertake the delegated action.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Additionally, the delegation process will allow for: >>>>>=20 >>>>> - Fine-grained specification of resource access >>>>>=20 >>>>> - Delegation between multiple users >>>>>=20 >>>>> - Web, mobile, single-page, and other client applications >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The group will define extension points for this protocol to allow = for flexibility in areas including: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> - Cryptographic agility for keys, message signatures, and proof of = possession=20 >>>>>=20 >>>>> - User interaction mechanisms including web and non-web methods >>>>>=20 >>>>> - Token presentation mechanisms and key bindings >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> While this work could be done in within the OAuth working group, I = now believe that it should be done in a new working group, and that we = should try to get that working group up and running prior to the = Vancouver meeting in March. I think this group should stay here on the = TxAuth list, and it=E2=80=99s my suggestion that the resulting work be = called OAuth 3.0.=20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Why a new group? I think that the OAuth working group should = remain focused on extending, patching, and adapting OAuth 2.0 to a = changing world. I plan to be engaged in both groups, and I know most of = you are as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so = established already, there are a LOT of people who aren=E2=80=99t going = to be interested in something new any time soon. But on the other hand, = there are a number of people for whom OAuth 2.0 does not work, or is at = the very least a poor fit, and we=E2=80=99ll want to bring them in at = this early stage. So even with significant overlap, I think there=E2=80=99= s enough disconnect in the community from both sides that warrants a new = group. In addition, I think this is a big enough piece of work that = it=E2=80=99s simply too much for the OAuth working group to be able to = focus on. We wouldn=E2=80=99t be able to get additional meeting time, = and OAuth already has trouble fitting into its two meeting slots as it = is. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I=E2=80=99ve published a blog post detailing more of my rationale: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> = https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-worki= ng-group-d6229ba8e36? = >>>>> =20 >>>>>=20 >>>>> Please suggest changes to the proposed charter text above. It=E2=80=99= s my hope that we can get the chartering process started. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =E2=80=94 Justin >>>>>=20 >>>>> -- Txauth mailing list Txauth@ietf.org = https://www.ietf.org/mailman/listinfo/txauth = --=20 >>>>> Txauth mailing list >>>>> Txauth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>> --=20 >>>>> ---- >>>>> Aaron Parecki >>>>> aaronparecki.com >>>>> @aaronpk >>>>>=20 >>>>=20 >>>> --=20 >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> @aaronpk >>>>=20 >>>> --=20 >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth = >>>>=20 >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you. >>>=20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_1C82EFA6-CE2A-49EC-AD1D-344DC1C3FBE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 And = just to reiterate a previous point =E2=80=94 as much as I want to make = the case for calling this work OAuth 3, it=E2=80=99s not something I=E2=80= =99m going to die for. The work is way more important than the = name. 

So with = that, I would propose that we basically punt on naming things until that = becomes important. I say we name both the working group and the first = document =E2=80=9CTxAuth=E2=80=9D, and keep this mailing list as its = base.

If the = working group decides in a couple years that this really should be = renamed, we can do that. It=E2=80=99s happened before =E2=80=94 and = again I=E2=80=99m calling to the model of HTTP/3. It started as QUIC in = the QUIC working group, and a year ago the QUIC working group decided to = rename it to HTTP/3, with the coordination and blessing of the HTTP = working group. Once QUIC group winds down, the HTTP/3 protocol will come = under the stewardship of the HTTP working group. I can easily see a = similar pattern happening here, where we create TxAuth and eventually it = gets handed over to the OAuth WG.

 =E2=80=94 Justin

On Dec 31, 2019, at 8:09 AM, Justin Richer <jricher@mit.edu> = wrote:

My understanding is = that HTTP3 is not backwards compatible, since QUIC was built on UDP from = the start and the considerations are pretty different from TCP = there. 

I = don=E2=80=99t think the safe answer is =E2=80=9Cdo nothing=E2=80=9D = today because there is a large and vibrant community around OAuth 2. The = safe answer is to deploy something that solves your problems.

I think that we=E2=80=99re= going to have the imaging issue vis a vis =E2=80=9Creplacing OAuth 2=E2=80= =9D whether we call this OAuth 3 or TxAuth or whatever. Truth is for = some people we will be replacing OAuth 2, and some people will be = throwing out their OAuth 2 implementations (if we=E2=80=99re = successful). But that=E2=80=99s the cost of tracking new technology, and = it=E2=80=99s pretty clear to me that this work has a long ways to = go.

 =E2=80= =94 Justin

On Dec 30, 2019, at 6:25 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

I significant difference in this case is that OAuth 3 is NOT = backward compatible with OAuth 2.

HTTP 2 was backwards compatible, as is HTTP 3 from what I = understand.

This= has enterprises question what they should do, and the safe answer is do = nothing. I think this is what Brian was getting at on confusion. People = are confused on what they should do. OAuth 3 not being backward = compatible implies work done with OAuth 2 may have to be thrown = away.


On Sat, Dec = 28, 2019 at 9:07 AM Justin Richer <jricher@mit.edu> wrote:
This is going to be the case whatever we call = this new work. Progress is going to continue to happen, and if a large = enterprise decides to wait for the new shiny thing 3 years from now, = then that=E2=80=99s on them. 

In my experience, it=E2=80=99s more = likely that a large enterprise is going to shy away from the new shiny = thing and go with what they can buy in a supported package off the = shelf. And I think that=E2=80=99s the kind of timescale that=E2=80=99s = going to drive most of the developers decisions around whether to track = the new work or use what=E2=80=99s out there =E2=80=94 they need to ask = =E2=80=9Cwhat do I need?=E2=80=9D And =E2=80=9Cwhen do I need = it?=E2=80=9D

But= these are :always: the questions that you need to ask when starting a = project and choosing technologies. 

I still contend that the name OAuth 3 = does a better job at communicating what=E2=80=99s going on = here.

 =E2=80= =94 Justin

On Dec 27, 2019, at 1:27 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

I agree with Brian. Developers such as large = enterprise customers are going to be confused when they hear there = is an OAuth 3 in the works. Some will push pause on projects because = they worry that it will be outdated when it is released. They won't know = which to deploy, even though OAuth 3 is not available. 

Also, if what we are = working on includes authentication / identity -- it no longer is just = delegated authorization

See inline comments below.


On Tue, Dec = 24, 2019 at 4:22 PM Justin Richer <jricher@mit.edu> wrote:
Brian, I hear what = you=E2=80=99re saying, but I disagree completely.

Who would be confused by seeing a major = revision to an existing protocol that worked in a different way and did = the same things but also new things? That happens all the = time.

And it causes market confusion all the time. Conservative = organizations stop doing things when it is not clear what the future = will be.
 

Was there significant = confusion between OAuth 1 and 2, enough to hamper adoption of either? = For the people who deeply invested in OAuth 1 and didn=E2=80=99t need or = want the OAuth 2 newness, they stuck with it (see: = twitter). 

Twitter stuck with OAuth 1 because they = did not like bearer tokens. 

Yes, there was lots of confusion = between OAuth 1 and 2. Erin did not want what became OAuth 2 to be = called OAuth because of the confusion. Hence it was called WRAP early. = The actual name of the WG is "Web Authorization Protocol"

 

Was OpenID Connect a = major disservice to OpenID 2? It was a disruption, for sure, but people = transitioned where it made sense for them, and in many cases that took = years of dual-deployment and = transition. 

The work that was being done on OpenID = 3 was killed because a large platform company that starts with G did not = want to confuse their customers about a new version.
 

I see us walking along the same kind of = path here, nearly a decade later. That=E2=80=99s why I think OAuth 3 = makes sense as a name for the output of this work. Or at the very least, = for the core delegation protocol portion of whatever we make. I think it = sends the right message to implementers and developers: the community = that knows and understands OAuth 2 is working on the next version of = that thing, so when it=E2=80=99s ready, maybe you should look at it. = Until it=E2=80=99s done, and for a long time after, OAuth 2 is still = going to be there and be the right = answer. 

I agree that people may be confused if = it is called something else that OAuth, but if it is broader than OAuth, = then that is confusing as well.
 

The name isn=E2=80=99t a hill I=E2=80=99m= committed to dying alone on, but I think it sends a :bad: message if we = call it something new entirely. Namely, that we think people :should: = abandon the entire world of OAuth, all of its ideas and implementations. = That=E2=80=99s not what we=E2=80=99re doing with this design, it=E2=80=99s= an evolution as I see things. And as an evolution, a new major revision = number makes sense.

 =E2=80=94 Justin

On Dec = 24, 2019, at 9:54 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Naming any prospective resulting work here "OAuth 3.0" would = significantly exacerbate confusion in the whole space and would be a = major disservice to the broader community.


On Mon, Dec = 23, 2019 at 7:39 PM Aaron Parecki <aaron@parecki.com> wrote:
I definitely am not trying to discuss specifics of *how* = authentication should be included right now, but I just want to make = sure it's included in the charter so that we can actually talk about it = and it won't be "out of scope" when we eventually do talk about the = specifics.

Aaron



On Mon, Dec = 23, 2019 at 1:51 PM Justin Richer <jricher@mit.edu> wrote:
I=E2=80=99m fine with = it being in charter but I do think it should be a clearly separate = layer, much like OIDC/Facebook Connect/GitHub Login/etc are with OAuth = today. In all of these the authorization is first, and I think that=E2=80=99= s the right pattern. So if we do take it on we=E2=80=99ll just need to = be careful how it=E2=80=99s structured in with everything else. = Otherwise, I think the authentication side can quickly overwhelm and = drag down the authorization side.

Good news: A lot of the additional stuff in OIDC is there to = patch holes in core OAuth in a common fashion, and we=E2=80=99ll at = least be in a position to not have to do that = again. 


 =E2=80= =94 Justin

On Dec 22, 2019, at 10:46 PM, = Aaron Parecki <aaron@parecki.com> wrote:

I do think = authentication should be part of the charter from the outset. Frankly = the fact that authentication is intentionally left out of OAuth and has = to be bolted on to the side via OpenID Connect is one of the exact = reasons people get confused about the whole space to begin = with. 

It's a relatively minor = addition to the existing proposed spec to make it useful as a minimum = viable authentication solution, and I'd like to see that be addressed at = the beginning of this work.

I think we can do this in = a smart way and that authentication should be included in the = charter.

Aaron




On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer = <yaronf.ietf@gmail.com> wrote:

Hi Justin,

 

I think the charter should = mention target use cases. For example, =E2=80=9Call use cases supported = by OAuth 2 will be supported by the new protocol=E2=80=9D or =E2=80=9Cthe = protocol will support at least use cases X and Y=E2=80=9D.

 

And = given the importance of OIDC, we could say something like: =E2=80=9CThe = protocol will allow future extension to support authentication, in an = analogous way to OpenID Connect. However authentication is explicitly = not part of the initial scope.=E2=80=9D

 

Thanks,

         =        Yaron

 

From: = Txauth <txauth-bounces@ietf.org> on behalf of Justin Richer = <jricher@mit.edu>
Date: = Saturday, December 21, 2019 at 00:34
To: = <txauth@ietf.org>
Cc: = "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>
Subject: = [Txauth] TxAuth Proposed Charter

 

Hi= all,

 

As = discussed in Singapore, no matter what forum TxAuth takes, its work will = require a new charter. With that in mind, I=E2=80=99ve taken a bit of = time to put together a proposed charter text for the TxAuth work:

 

This group is chartered to develop a next-generation = transactional authorization and delegation protocol for HTTP-based APIs = and their clients. These transactions will allow an authorizing party to = delegate a right of access for an API or set of APIs through an = authorization server to a software client acting on behalf of an = authorizing party. 

 

The = group will deliver a protocol specification detailing how a client can = request and obtain delegated access, how an authorization server can = provide delegated access, how an authorized party can authorize = delegated access, and how that authorized access can be communicated to = the resources being protected. These actions will be connected through = an explicit transaction between the client and authorization server, = resulting in an artifact that will allow the client to undertake the = delegated action. 

 

Additionally, the delegation process will allow = for:

- Fine-grained specification of resource access

- Delegation between multiple users

- Web, mobile, single-page, and other client = applications

 

The = group will define extension points for this protocol to allow for = flexibility in areas including:

 

- Cryptographic agility for keys, message = signatures, and proof of possession 

- User = interaction mechanisms including web and non-web methods

- Token presentation mechanisms and key bindings

 

The = artifacts for this work are not intended or expected to be = backwards-compatible with OAuth 2.0 and its extensions. 

 

While = this work could be done in within the OAuth working group, I now believe = that it should be done in a new working group, and that we should try to = get that working group up and running prior to the Vancouver meeting in = March. I think this group should stay here on the TxAuth list, and = it=E2=80=99s my suggestion that the resulting work be called OAuth = 3.0. 

 

Why a = new group? I think that the OAuth working group should remain focused on = extending, patching, and adapting OAuth 2.0 to a changing world. I plan = to be engaged in both groups, and I know most of you are as well, but = that=E2=80=99s not universal. Since OAuth 2.0 is so established already, = there are a LOT of people who aren=E2=80=99t going to be interested in = something new any time soon. But on the other hand, there are a number = of people for whom OAuth 2.0 does not work, or is at the very least a = poor fit, and we=E2=80=99ll want to bring them in at this early stage. = So even with significant overlap, I think there=E2=80=99s enough = disconnect in the community from both sides that warrants a new group. = In addition, I think this is a big enough piece of work that it=E2=80=99s = simply too much for the OAuth working group to be able to focus on. We = wouldn=E2=80=99t be able to get additional meeting time, and OAuth = already has trouble fitting into its two meeting slots as it is.

 

I=E2=80=99= ve published a blog post detailing more of my rationale:

 

https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-= a-new-working-group-d6229ba8e36?

 

Please suggest changes to the proposed charter text = above. It=E2=80=99s my hope that we can get the chartering process = started.

 

 =E2=80= =94 Justin

-- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=
--
----
Aaron = Parecki
aaronparecki.com
@aaronpk


--
----
Aaron Parecki
aaronparecki.com
@aaronpk

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=

CONFIDENTIALITY NOTICE: This email may contain confidential = and privileged material for the sole use of the intended recipient(s). = Any review, use, distribution or disclosure by others is strictly = prohibited.  If you have received this communication in error, = please notify the sender immediately by e-mail and delete the message = and any file attachments from your computer. Thank = you.

--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth
=


--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_1C82EFA6-CE2A-49EC-AD1D-344DC1C3FBE1-- From nobody Tue Dec 31 10:42:23 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB34120058 for ; Tue, 31 Dec 2019 10:42:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-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 rc8B9xU2T5r8 for ; Tue, 31 Dec 2019 10:42:19 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 F07B312001A for ; Tue, 31 Dec 2019 10:42:18 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id z8so34564782ioh.0 for ; Tue, 31 Dec 2019 10:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZNmO75XxG+pxhDqqPflsyvGuQj5L3fqxTYggkiL1m54=; b=L+gwNK4XBiD6EuP6tg8jegCb+jSk1ma7Vvx6srzk3/2Y9Alk+Bqh44RgVCLiCU80D5 T4LrM+WsTWAok8z4qtT4RZrG80BiNRSaj9xmbmiB2QDr0RjoIMk6V7vHvgjB3n9mZ+Vh C93GM5uPL/DE35E+6c6GuXEveUXCOS9/k+fUhDZ5z1m2DVPV8ljxbyYWM0CdGrb3NoHO RsatLNR8VF5ZVOdD+LdQPeeRzOWTpzvnWrPP+GXwPfnFe8XEjAlZj+3m1kSHlfacRiAa 4Vxc7gi9Bupu9Qvb9mxHWCKjTECjGaZ5710v5Z5RS7V5msnDLFGAtK2jrtCBKIare063 zOTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZNmO75XxG+pxhDqqPflsyvGuQj5L3fqxTYggkiL1m54=; b=HbTP3c1sAv2AmcY8WhqGxQlThOldZAKoJ5tvSihR8SbIRLI941k1X4WPgIv2WPr6Pv wrumYBxKRPiyNFXTW1Zfeb9HN+55LVkvMVOd8Ec/YpEEhhuwm8oaQt9AqT8m1yICIlKD 0NCNJn+loSienxXbk6wc6TQXKW8iNCw3IPkLoaoWkdI7xCm+vSuO3aiICF3P4KXOK4tK 8acFJIZgaOwUMbPhsEJSj4J5TSqlsCTDHzs1f8LkSI4WkveG8RBFvhTh8gMgdN/w2Khu rhq2MXpIsH2xQg1V3QdWbVCDRy8Y2pSZdxMLd+rDymWf1CpYiP8cLMhDO5geS+a39NRu ntSQ== X-Gm-Message-State: APjAAAVe84wgZgOI77CLamUB5y1acC4LlUQYEoP/+aAOXTdbwhMhybaq ubsT03JFRVXYgY2gNjsLkqiRpDn38vs= X-Google-Smtp-Source: APXvYqy4IBGlTi2b0bCTr/Bb2HfzmtZWcVBGvoj6jIW6dEYRBOyFV6yaknfXLSE92remyPAxa5ayCw== X-Received: by 2002:a02:7310:: with SMTP id y16mr57760117jab.133.1577817737722; Tue, 31 Dec 2019 10:42:17 -0800 (PST) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com. [209.85.166.54]) by smtp.gmail.com with ESMTPSA id u13sm12713320iof.2.2019.12.31.10.42.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 Dec 2019 10:42:17 -0800 (PST) Received: by mail-io1-f54.google.com with SMTP id i11so34539583ioi.12 for ; Tue, 31 Dec 2019 10:42:17 -0800 (PST) X-Received: by 2002:a05:6638:3b6:: with SMTP id z22mr56135585jap.35.1577817736464; Tue, 31 Dec 2019 10:42:16 -0800 (PST) MIME-Version: 1.0 References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> <0AB6001B-43AF-42F1-87CA-BE621DEBE0FB@mit.edu> <5137E82A-F4F1-425F-9DCA-785B3927E509@mit.edu> In-Reply-To: <5137E82A-F4F1-425F-9DCA-785B3927E509@mit.edu> From: Aaron Parecki Date: Tue, 31 Dec 2019 10:42:06 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Justin Richer Cc: Dick Hardt , "rdd@cert.org" , Yaron Sheffer , Benjamin Kaduk , Brian Campbell , txauth@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 18:42:22 -0000 I agree with Justin's point that the name is not important right now. That said, OAuth 2 was not backwards compatible with OAuth 1 by design, so I would expect the same to be true for if and when OAuth 3 ends up becoming a thing, whatever form it takes. As for the points on market confusion, this TXAuth work is going to happen regardless of whether the OAuth WG wants it to, either at the IETF or not, and in my opinion it would have worse effects in the market if the OAuth WG did not acknowledge it and didn't indicate an eventual plan that this work would subsume OAuth 2. That would just lead to a situation where people are forced to implement and maintain both an OAuth 2 and TXAuth system, not because of existing deployments, but because there would be no clear indication that TXAuth is the best path for OAuth-like systems going forward. ---- Aaron Parecki aaronparecki.com On Tue, Dec 31, 2019 at 10:37 AM Justin Richer wrote: > > And just to reiterate a previous point =E2=80=94 as much as I want to mak= e the case for calling this work OAuth 3, it=E2=80=99s not something I=E2= =80=99m going to die for. The work is way more important than the name. > > So with that, I would propose that we basically punt on naming things unt= il that becomes important. I say we name both the working group and the fir= st document =E2=80=9CTxAuth=E2=80=9D, and keep this mailing list as its bas= e. > > If the working group decides in a couple years that this really should be= renamed, we can do that. It=E2=80=99s happened before =E2=80=94 and again = I=E2=80=99m calling to the model of HTTP/3. It started as QUIC in the QUIC = working group, and a year ago the QUIC working group decided to rename it t= o HTTP/3, with the coordination and blessing of the HTTP working group. Onc= e QUIC group winds down, the HTTP/3 protocol will come under the stewardshi= p of the HTTP working group. I can easily see a similar pattern happening h= ere, where we create TxAuth and eventually it gets handed over to the OAuth= WG. > > =E2=80=94 Justin > > On Dec 31, 2019, at 8:09 AM, Justin Richer wrote: > > My understanding is that HTTP3 is not backwards compatible, since QUIC wa= s built on UDP from the start and the considerations are pretty different f= rom TCP there. > > I don=E2=80=99t think the safe answer is =E2=80=9Cdo nothing=E2=80=9D tod= ay because there is a large and vibrant community around OAuth 2. The safe = answer is to deploy something that solves your problems. > > I think that we=E2=80=99re going to have the imaging issue vis a vis =E2= =80=9Creplacing OAuth 2=E2=80=9D whether we call this OAuth 3 or TxAuth or = whatever. Truth is for some people we will be replacing OAuth 2, and some p= eople will be throwing out their OAuth 2 implementations (if we=E2=80=99re = successful). But that=E2=80=99s the cost of tracking new technology, and it= =E2=80=99s pretty clear to me that this work has a long ways to go. > > =E2=80=94 Justin > > On Dec 30, 2019, at 6:25 PM, Dick Hardt wrote: > > I significant difference in this case is that OAuth 3 is NOT backward com= patible with OAuth 2. > > HTTP 2 was backwards compatible, as is HTTP 3 from what I understand. > > This has enterprises question what they should do, and the safe answer is= do nothing. I think this is what Brian was getting at on confusion. People= are confused on what they should do. OAuth 3 not being backward compatible= implies work done with OAuth 2 may have to be thrown away. > > > On Sat, Dec 28, 2019 at 9:07 AM Justin Richer wrote: >> >> This is going to be the case whatever we call this new work. Progress is= going to continue to happen, and if a large enterprise decides to wait for= the new shiny thing 3 years from now, then that=E2=80=99s on them. >> >> In my experience, it=E2=80=99s more likely that a large enterprise is go= ing to shy away from the new shiny thing and go with what they can buy in a= supported package off the shelf. And I think that=E2=80=99s the kind of ti= mescale that=E2=80=99s going to drive most of the developers decisions arou= nd whether to track the new work or use what=E2=80=99s out there =E2=80=94 = they need to ask =E2=80=9Cwhat do I need?=E2=80=9D And =E2=80=9Cwhen do I n= eed it?=E2=80=9D >> >> But these are :always: the questions that you need to ask when starting = a project and choosing technologies. >> >> I still contend that the name OAuth 3 does a better job at communicating= what=E2=80=99s going on here. >> >> =E2=80=94 Justin >> >> On Dec 27, 2019, at 1:27 PM, Dick Hardt wrote: >> >> I agree with Brian. Developers such as large enterprise customers are go= ing to be confused when they hear there is an OAuth 3 in the works. Some wi= ll push pause on projects because they worry that it will be outdated when = it is released. They won't know which to deploy, even though OAuth 3 is not= available. >> >> Also, if what we are working on includes authentication / identity -- it= no longer is just delegated authorization >> >> See inline comments below. >> >> >> On Tue, Dec 24, 2019 at 4:22 PM Justin Richer wrote: >>> >>> Brian, I hear what you=E2=80=99re saying, but I disagree completely. >>> >>> Who would be confused by seeing a major revision to an existing protoco= l that worked in a different way and did the same things but also new thing= s? That happens all the time. >> >> >> And it causes market confusion all the time. Conservative organizations = stop doing things when it is not clear what the future will be. >> >>> >>> >>> Was there significant confusion between OAuth 1 and 2, enough to hamper= adoption of either? For the people who deeply invested in OAuth 1 and didn= =E2=80=99t need or want the OAuth 2 newness, they stuck with it (see: twitt= er). >> >> >> Twitter stuck with OAuth 1 because they did not like bearer tokens. >> >> Yes, there was lots of confusion between OAuth 1 and 2. Erin did not wan= t what became OAuth 2 to be called OAuth because of the confusion. Hence it= was called WRAP early. The actual name of the WG is "Web Authorization Pro= tocol" >> >> >>> >>> >>> Was OpenID Connect a major disservice to OpenID 2? It was a disruption,= for sure, but people transitioned where it made sense for them, and in man= y cases that took years of dual-deployment and transition. >> >> >> The work that was being done on OpenID 3 was killed because a large plat= form company that starts with G did not want to confuse their customers abo= ut a new version. >> >>> >>> >>> I see us walking along the same kind of path here, nearly a decade late= r. That=E2=80=99s why I think OAuth 3 makes sense as a name for the output = of this work. Or at the very least, for the core delegation protocol portio= n of whatever we make. I think it sends the right message to implementers a= nd developers: the community that knows and understands OAuth 2 is working = on the next version of that thing, so when it=E2=80=99s ready, maybe you sh= ould look at it. Until it=E2=80=99s done, and for a long time after, OAuth = 2 is still going to be there and be the right answer. >> >> >> I agree that people may be confused if it is called something else that = OAuth, but if it is broader than OAuth, then that is confusing as well. >> >>> >>> >>> The name isn=E2=80=99t a hill I=E2=80=99m committed to dying alone on, = but I think it sends a :bad: message if we call it something new entirely. = Namely, that we think people :should: abandon the entire world of OAuth, al= l of its ideas and implementations. That=E2=80=99s not what we=E2=80=99re d= oing with this design, it=E2=80=99s an evolution as I see things. And as an= evolution, a new major revision number makes sense. >>> >>> =E2=80=94 Justin >>> >>> On Dec 24, 2019, at 9:54 AM, Brian Campbell wrote: >>> >>> Naming any prospective resulting work here "OAuth 3.0" would significan= tly exacerbate confusion in the whole space and would be a major disservice= to the broader community. >>> >>> >>> On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki wrote= : >>>> >>>> I definitely am not trying to discuss specifics of *how* authenticatio= n should be included right now, but I just want to make sure it's included = in the charter so that we can actually talk about it and it won't be "out o= f scope" when we eventually do talk about the specifics. >>>> >>>> Aaron >>>> >>>> >>>> >>>> On Mon, Dec 23, 2019 at 1:51 PM Justin Richer wrote: >>>>> >>>>> I=E2=80=99m fine with it being in charter but I do think it should be= a clearly separate layer, much like OIDC/Facebook Connect/GitHub Login/etc= are with OAuth today. In all of these the authorization is first, and I th= ink that=E2=80=99s the right pattern. So if we do take it on we=E2=80=99ll = just need to be careful how it=E2=80=99s structured in with everything else= . Otherwise, I think the authentication side can quickly overwhelm and drag= down the authorization side. >>>>> >>>>> Good news: A lot of the additional stuff in OIDC is there to patch ho= les in core OAuth in a common fashion, and we=E2=80=99ll at least be in a p= osition to not have to do that again. >>>>> >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Dec 22, 2019, at 10:46 PM, Aaron Parecki wrote= : >>>>> >>>>> I do think authentication should be part of the charter from the outs= et. Frankly the fact that authentication is intentionally left out of OAuth= and has to be bolted on to the side via OpenID Connect is one of the exact= reasons people get confused about the whole space to begin with. >>>>> >>>>> It's a relatively minor addition to the existing proposed spec to mak= e it useful as a minimum viable authentication solution, and I'd like to se= e that be addressed at the beginning of this work. >>>>> >>>>> I think we can do this in a smart way and that authentication should = be included in the charter. >>>>> >>>>> Aaron >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer = wrote: >>>>>> >>>>>> Hi Justin, >>>>>> >>>>>> >>>>>> >>>>>> I think the charter should mention target use cases. For example, = =E2=80=9Call use cases supported by OAuth 2 will be supported by the new pr= otocol=E2=80=9D or =E2=80=9Cthe protocol will support at least use cases X = and Y=E2=80=9D. >>>>>> >>>>>> >>>>>> >>>>>> And given the importance of OIDC, we could say something like: =E2= =80=9CThe protocol will allow future extension to support authentication, i= n an analogous way to OpenID Connect. However authentication is explicitly = not part of the initial scope.=E2=80=9D >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yaron >>>>>> >>>>>> >>>>>> >>>>>> From: Txauth on behalf of Justin Richer >>>>>> Date: Saturday, December 21, 2019 at 00:34 >>>>>> To: >>>>>> Cc: "rdd@cert.org" , Benjamin Kaduk >>>>>> Subject: [Txauth] TxAuth Proposed Charter >>>>>> >>>>>> >>>>>> >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> As discussed in Singapore, no matter what forum TxAuth takes, its wo= rk will require a new charter. With that in mind, I=E2=80=99ve taken a bit = of time to put together a proposed charter text for the TxAuth work: >>>>>> >>>>>> >>>>>> >>>>>> This group is chartered to develop a next-generation transactional a= uthorization and delegation protocol for HTTP-based APIs and their clients.= These transactions will allow an authorizing party to delegate a right of = access for an API or set of APIs through an authorization server to a softw= are client acting on behalf of an authorizing party. >>>>>> >>>>>> >>>>>> >>>>>> The group will deliver a protocol specification detailing how a clie= nt can request and obtain delegated access, how an authorization server can= provide delegated access, how an authorized party can authorize delegated = access, and how that authorized access can be communicated to the resources= being protected. These actions will be connected through an explicit trans= action between the client and authorization server, resulting in an artifac= t that will allow the client to undertake the delegated action. >>>>>> >>>>>> >>>>>> >>>>>> Additionally, the delegation process will allow for: >>>>>> >>>>>> - Fine-grained specification of resource access >>>>>> >>>>>> - Delegation between multiple users >>>>>> >>>>>> - Web, mobile, single-page, and other client applications >>>>>> >>>>>> >>>>>> >>>>>> The group will define extension points for this protocol to allow fo= r flexibility in areas including: >>>>>> >>>>>> >>>>>> >>>>>> - Cryptographic agility for keys, message signatures, and proof of p= ossession >>>>>> >>>>>> - User interaction mechanisms including web and non-web methods >>>>>> >>>>>> - Token presentation mechanisms and key bindings >>>>>> >>>>>> >>>>>> >>>>>> The artifacts for this work are not intended or expected to be backw= ards-compatible with OAuth 2.0 and its extensions. >>>>>> >>>>>> >>>>>> >>>>>> While this work could be done in within the OAuth working group, I n= ow believe that it should be done in a new working group, and that we shoul= d try to get that working group up and running prior to the Vancouver meeti= ng in March. I think this group should stay here on the TxAuth list, and it= =E2=80=99s my suggestion that the resulting work be called OAuth 3.0. >>>>>> >>>>>> >>>>>> >>>>>> Why a new group? I think that the OAuth working group should remain = focused on extending, patching, and adapting OAuth 2.0 to a changing world.= I plan to be engaged in both groups, and I know most of you are as well, b= ut that=E2=80=99s not universal. Since OAuth 2.0 is so established already,= there are a LOT of people who aren=E2=80=99t going to be interested in som= ething new any time soon. But on the other hand, there are a number of peop= le for whom OAuth 2.0 does not work, or is at the very least a poor fit, an= d we=E2=80=99ll want to bring them in at this early stage. So even with sig= nificant overlap, I think there=E2=80=99s enough disconnect in the communit= y from both sides that warrants a new group. In addition, I think this is a= big enough piece of work that it=E2=80=99s simply too much for the OAuth w= orking group to be able to focus on. We wouldn=E2=80=99t be able to get add= itional meeting time, and OAuth already has trouble fitting into its two me= eting slots as it is. >>>>>> >>>>>> >>>>>> >>>>>> I=E2=80=99ve published a blog post detailing more of my rationale: >>>>>> >>>>>> >>>>>> >>>>>> https://medium..com/@justinsecurity/the-case-for-oauth-3-0-why-a-new= -working-group-d6229ba8e36? >>>>>> >>>>>> >>>>>> >>>>>> Please suggest changes to the proposed charter text above. It=E2=80= =99s my hope that we can get the chartering process started. >>>>>> >>>>>> >>>>>> >>>>>> =E2=80=94 Justin >>>>>> >>>>>> -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/= listinfo/txauth >>>>>> >>>>>> -- >>>>>> Txauth mailing list >>>>>> Txauth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/txauth >>>>> >>>>> -- >>>>> ---- >>>>> Aaron Parecki >>>>> aaronparecki.com >>>>> @aaronpk >>>>> >>>>> >>>> -- >>>> ---- >>>> Aaron Parecki >>>> aaronparecki.com >>>> @aaronpk >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and privile= ged material for the sole use of the intended recipient(s). Any review, use= , distribution or disclosure by others is strictly prohibited. If you have= received this communication in error, please notify the sender immediately= by e-mail and delete the message and any file attachments from your comput= er. Thank you. >>> >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >> >> > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > From nobody Tue Dec 31 10:51:18 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BBD120013 for ; Tue, 31 Dec 2019 10:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 5FKxyPwszI8s for ; Tue, 31 Dec 2019 10:51:13 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::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 8CFD112001E for ; Tue, 31 Dec 2019 10:51:12 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id u71so37012432lje.11 for ; Tue, 31 Dec 2019 10:51:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cGLVcD102Hd0lwbUePYA6IJcOejIRxsnkBS+9PLrSxA=; b=cXext9IJ6Wneujj+ztoZkcvaR+veyOd/xO40AetOKlUZ2HO4KjnK2MZ5aigxvu8fWP 8Amy+n8CKZx6nvT8G/46OqcgElROzPt1kxkJijSnYgj5CTwZ6kbQYgWG9SaWV0UE0cIo NIsvxtAkjOD9piO0DtC4oI3XiD4Y9RFCjuybxnIZvzFngP8M4+Qk3FPGLCpKQgwTP94t L8tPQEqj0N1GnmNd+LAYVfPAc6azkkHhLp8nRbpsViaTjDk4UAAOPt8R/62GNR7IBIn+ V1/j1csn/42XvF0wy5g/ZWMmiUDM5zVADYbYQmoiNRK89o4G68ig+1Ex4EdJNm3rQYZX h+GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cGLVcD102Hd0lwbUePYA6IJcOejIRxsnkBS+9PLrSxA=; b=ofXhaydUIlNxTb/DPo+ELfS8n1ra1nYKLrvl+9Eq+nY6cIdr5UL5VH6qMSLb+ubVZO iH71CV+meGDYU+udrUV4qSsjL6qVG3tNiWb9ASh0macKL7k826VbSSqY701GkjM5oxew DBePYAiNYZyNdXLzeRfrito2AjbT8dlqyqpmUIuzvwBaVw1l/HdB16pBhMqKXvwNRRPb iRZ112p5TFqzigTnKjBBTcADcBN3lWdDF+rRaf2xeuP42JNos6r95UxSuD6gtFE8xYDF zviuEEbI+9+iKGuJRl3BugG5qYX6TA+GhJ+8urMdmnk4i8kbTlgQIMZgWYClveoOpda6 bVVw== X-Gm-Message-State: APjAAAXEgHTpFgVHtWjzr+qCV9lajxucSlBIrw8TfYMWWoapRmJ3IrN/ QPu7XJ4mN6WEruIoeBWG3n25shqRfJ6Vx8+SnOI= X-Google-Smtp-Source: APXvYqxJJ9IKdsjKasqv//oYVhx9vB2f7Bs7Id11jvnXfgQu4+dxRhY8SiBKaIyEk6W5oSfB48YKyILIYR5Ag/T8aPg= X-Received: by 2002:a05:651c:204f:: with SMTP id t15mr44303725ljo.240.1577818270687; Tue, 31 Dec 2019 10:51:10 -0800 (PST) MIME-Version: 1.0 References: <7F610E9A-787E-43B0-A553-E31983D91DD2@mit.edu> <2305299E-FB2C-426D-A9BF-F2E2492A311A@mit.edu> <0AB6001B-43AF-42F1-87CA-BE621DEBE0FB@mit.edu> <5137E82A-F4F1-425F-9DCA-785B3927E509@mit.edu> In-Reply-To: From: Dick Hardt Date: Tue, 31 Dec 2019 10:50:58 -0800 Message-ID: To: Aaron Parecki Cc: Justin Richer , "rdd@cert.org" , Yaron Sheffer , Benjamin Kaduk , Brian Campbell , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000008b6487059b047172" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 18:51:17 -0000 --0000000000008b6487059b047172 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The name is important in that calling it OAuth 3 at this point in time will create market uncertainty. I agree that this work is the successor of OAuth-like systems. I would hope that it is also the successor of OIDC-like systems. I'm confused about Aaron's comments about the OAuth WG wrt. market confusion. HTTP3 is backwards compatible with HTTP2 and HTTP 1.x from the developers point of view. The same verbs, headers etc. all work. The interface for developers is the same. What is on the wire is different. This work will not be compatible from a developers point of view wrt. OAuth 2.0 On Tue, Dec 31, 2019 at 10:42 AM Aaron Parecki wrote: > I agree with Justin's point that the name is not important right now. > > That said, OAuth 2 was not backwards compatible with OAuth 1 by > design, so I would expect the same to be true for if and when OAuth 3 > ends up becoming a thing, whatever form it takes. > > As for the points on market confusion, this TXAuth work is going to > happen regardless of whether the OAuth WG wants it to, either at the > IETF or not, and in my opinion it would have worse effects in the > market if the OAuth WG did not acknowledge it and didn't indicate an > eventual plan that this work would subsume OAuth 2. That would just > lead to a situation where people are forced to implement and maintain > both an OAuth 2 and TXAuth system, not because of existing > deployments, but because there would be no clear indication that > TXAuth is the best path for OAuth-like systems going forward. > > ---- > Aaron Parecki > aaronparecki.com > > > On Tue, Dec 31, 2019 at 10:37 AM Justin Richer wrote: > > > > And just to reiterate a previous point =E2=80=94 as much as I want to m= ake the > case for calling this work OAuth 3, it=E2=80=99s not something I=E2=80=99= m going to die > for. The work is way more important than the name. > > > > So with that, I would propose that we basically punt on naming things > until that becomes important. I say we name both the working group and th= e > first document =E2=80=9CTxAuth=E2=80=9D, and keep this mailing list as it= s base. > > > > If the working group decides in a couple years that this really should > be renamed, we can do that. It=E2=80=99s happened before =E2=80=94 and ag= ain I=E2=80=99m calling to > the model of HTTP/3. It started as QUIC in the QUIC working group, and a > year ago the QUIC working group decided to rename it to HTTP/3, with the > coordination and blessing of the HTTP working group. Once QUIC group wind= s > down, the HTTP/3 protocol will come under the stewardship of the HTTP > working group. I can easily see a similar pattern happening here, where w= e > create TxAuth and eventually it gets handed over to the OAuth WG. > > > > =E2=80=94 Justin > > > > On Dec 31, 2019, at 8:09 AM, Justin Richer wrote: > > > > My understanding is that HTTP3 is not backwards compatible, since QUIC > was built on UDP from the start and the considerations are pretty differe= nt > from TCP there. > > > > I don=E2=80=99t think the safe answer is =E2=80=9Cdo nothing=E2=80=9D t= oday because there is a > large and vibrant community around OAuth 2. The safe answer is to deploy > something that solves your problems. > > > > I think that we=E2=80=99re going to have the imaging issue vis a vis = =E2=80=9Creplacing > OAuth 2=E2=80=9D whether we call this OAuth 3 or TxAuth or whatever. Trut= h is for > some people we will be replacing OAuth 2, and some people will be throwin= g > out their OAuth 2 implementations (if we=E2=80=99re successful). But that= =E2=80=99s the > cost of tracking new technology, and it=E2=80=99s pretty clear to me that= this work > has a long ways to go. > > > > =E2=80=94 Justin > > > > On Dec 30, 2019, at 6:25 PM, Dick Hardt wrote: > > > > I significant difference in this case is that OAuth 3 is NOT backward > compatible with OAuth 2. > > > > HTTP 2 was backwards compatible, as is HTTP 3 from what I understand. > > > > This has enterprises question what they should do, and the safe answer > is do nothing. I think this is what Brian was getting at on confusion. > People are confused on what they should do. OAuth 3 not being backward > compatible implies work done with OAuth 2 may have to be thrown away. > > > > > > On Sat, Dec 28, 2019 at 9:07 AM Justin Richer wrote: > >> > >> This is going to be the case whatever we call this new work. Progress > is going to continue to happen, and if a large enterprise decides to wait > for the new shiny thing 3 years from now, then that=E2=80=99s on them. > >> > >> In my experience, it=E2=80=99s more likely that a large enterprise is = going to > shy away from the new shiny thing and go with what they can buy in a > supported package off the shelf. And I think that=E2=80=99s the kind of t= imescale > that=E2=80=99s going to drive most of the developers decisions around whe= ther to > track the new work or use what=E2=80=99s out there =E2=80=94 they need to= ask =E2=80=9Cwhat do I > need?=E2=80=9D And =E2=80=9Cwhen do I need it?=E2=80=9D > >> > >> But these are :always: the questions that you need to ask when startin= g > a project and choosing technologies. > >> > >> I still contend that the name OAuth 3 does a better job at > communicating what=E2=80=99s going on here. > >> > >> =E2=80=94 Justin > >> > >> On Dec 27, 2019, at 1:27 PM, Dick Hardt wrote: > >> > >> I agree with Brian. Developers such as large enterprise customers are > going to be confused when they hear there is an OAuth 3 in the works. Som= e > will push pause on projects because they worry that it will be outdated > when it is released. They won't know which to deploy, even though OAuth 3 > is not available. > >> > >> Also, if what we are working on includes authentication / identity -- > it no longer is just delegated authorization > >> > >> See inline comments below. > >> > >> > >> On Tue, Dec 24, 2019 at 4:22 PM Justin Richer wrote: > >>> > >>> Brian, I hear what you=E2=80=99re saying, but I disagree completely. > >>> > >>> Who would be confused by seeing a major revision to an existing > protocol that worked in a different way and did the same things but also > new things? That happens all the time. > >> > >> > >> And it causes market confusion all the time. Conservative organization= s > stop doing things when it is not clear what the future will be. > >> > >>> > >>> > >>> Was there significant confusion between OAuth 1 and 2, enough to > hamper adoption of either? For the people who deeply invested in OAuth 1 > and didn=E2=80=99t need or want the OAuth 2 newness, they stuck with it (= see: > twitter). > >> > >> > >> Twitter stuck with OAuth 1 because they did not like bearer tokens. > >> > >> Yes, there was lots of confusion between OAuth 1 and 2. Erin did not > want what became OAuth 2 to be called OAuth because of the confusion. Hen= ce > it was called WRAP early. The actual name of the WG is "Web Authorization > Protocol" > >> > >> > >>> > >>> > >>> Was OpenID Connect a major disservice to OpenID 2? It was a > disruption, for sure, but people transitioned where it made sense for the= m, > and in many cases that took years of dual-deployment and transition. > >> > >> > >> The work that was being done on OpenID 3 was killed because a large > platform company that starts with G did not want to confuse their custome= rs > about a new version. > >> > >>> > >>> > >>> I see us walking along the same kind of path here, nearly a decade > later. That=E2=80=99s why I think OAuth 3 makes sense as a name for the o= utput of > this work. Or at the very least, for the core delegation protocol portion > of whatever we make. I think it sends the right message to implementers a= nd > developers: the community that knows and understands OAuth 2 is working o= n > the next version of that thing, so when it=E2=80=99s ready, maybe you sho= uld look > at it. Until it=E2=80=99s done, and for a long time after, OAuth 2 is sti= ll going > to be there and be the right answer. > >> > >> > >> I agree that people may be confused if it is called something else tha= t > OAuth, but if it is broader than OAuth, then that is confusing as well. > >> > >>> > >>> > >>> The name isn=E2=80=99t a hill I=E2=80=99m committed to dying alone on= , but I think it > sends a :bad: message if we call it something new entirely. Namely, that = we > think people :should: abandon the entire world of OAuth, all of its ideas > and implementations. That=E2=80=99s not what we=E2=80=99re doing with thi= s design, it=E2=80=99s an > evolution as I see things. And as an evolution, a new major revision numb= er > makes sense. > >>> > >>> =E2=80=94 Justin > >>> > >>> On Dec 24, 2019, at 9:54 AM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >>> > >>> Naming any prospective resulting work here "OAuth 3.0" would > significantly exacerbate confusion in the whole space and would be a majo= r > disservice to the broader community. > >>> > >>> > >>> On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki > wrote: > >>>> > >>>> I definitely am not trying to discuss specifics of *how* > authentication should be included right now, but I just want to make sure > it's included in the charter so that we can actually talk about it and it > won't be "out of scope" when we eventually do talk about the specifics. > >>>> > >>>> Aaron > >>>> > >>>> > >>>> > >>>> On Mon, Dec 23, 2019 at 1:51 PM Justin Richer > wrote: > >>>>> > >>>>> I=E2=80=99m fine with it being in charter but I do think it should = be a > clearly separate layer, much like OIDC/Facebook Connect/GitHub Login/etc > are with OAuth today. In all of these the authorization is first, and I > think that=E2=80=99s the right pattern. So if we do take it on we=E2=80= =99ll just need to > be careful how it=E2=80=99s structured in with everything else. Otherwise= , I think > the authentication side can quickly overwhelm and drag down the > authorization side. > >>>>> > >>>>> Good news: A lot of the additional stuff in OIDC is there to patch > holes in core OAuth in a common fashion, and we=E2=80=99ll at least be in= a > position to not have to do that again. > >>>>> > >>>>> > >>>>> =E2=80=94 Justin > >>>>> > >>>>> On Dec 22, 2019, at 10:46 PM, Aaron Parecki > wrote: > >>>>> > >>>>> I do think authentication should be part of the charter from the > outset. Frankly the fact that authentication is intentionally left out of > OAuth and has to be bolted on to the side via OpenID Connect is one of th= e > exact reasons people get confused about the whole space to begin with. > >>>>> > >>>>> It's a relatively minor addition to the existing proposed spec to > make it useful as a minimum viable authentication solution, and I'd like = to > see that be addressed at the beginning of this work. > >>>>> > >>>>> I think we can do this in a smart way and that authentication shoul= d > be included in the charter. > >>>>> > >>>>> Aaron > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer > wrote: > >>>>>> > >>>>>> Hi Justin, > >>>>>> > >>>>>> > >>>>>> > >>>>>> I think the charter should mention target use cases. For example, > =E2=80=9Call use cases supported by OAuth 2 will be supported by the new = protocol=E2=80=9D > or =E2=80=9Cthe protocol will support at least use cases X and Y=E2=80=9D= . > >>>>>> > >>>>>> > >>>>>> > >>>>>> And given the importance of OIDC, we could say something like: =E2= =80=9CThe > protocol will allow future extension to support authentication, in an > analogous way to OpenID Connect. However authentication is explicitly not > part of the initial scope.=E2=80=9D > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Yaron > >>>>>> > >>>>>> > >>>>>> > >>>>>> From: Txauth on behalf of Justin Richer = < > jricher@mit.edu> > >>>>>> Date: Saturday, December 21, 2019 at 00:34 > >>>>>> To: > >>>>>> Cc: "rdd@cert.org" , Benjamin Kaduk > >>>>>> Subject: [Txauth] TxAuth Proposed Charter > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> > >>>>>> > >>>>>> As discussed in Singapore, no matter what forum TxAuth takes, its > work will require a new charter. With that in mind, I=E2=80=99ve taken a = bit of > time to put together a proposed charter text for the TxAuth work: > >>>>>> > >>>>>> > >>>>>> > >>>>>> This group is chartered to develop a next-generation transactional > authorization and delegation protocol for HTTP-based APIs and their > clients. These transactions will allow an authorizing party to delegate a > right of access for an API or set of APIs through an authorization server > to a software client acting on behalf of an authorizing party. > >>>>>> > >>>>>> > >>>>>> > >>>>>> The group will deliver a protocol specification detailing how a > client can request and obtain delegated access, how an authorization serv= er > can provide delegated access, how an authorized party can authorize > delegated access, and how that authorized access can be communicated to t= he > resources being protected. These actions will be connected through an > explicit transaction between the client and authorization server, resulti= ng > in an artifact that will allow the client to undertake the delegated acti= on. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Additionally, the delegation process will allow for: > >>>>>> > >>>>>> - Fine-grained specification of resource access > >>>>>> > >>>>>> - Delegation between multiple users > >>>>>> > >>>>>> - Web, mobile, single-page, and other client applications > >>>>>> > >>>>>> > >>>>>> > >>>>>> The group will define extension points for this protocol to allow > for flexibility in areas including: > >>>>>> > >>>>>> > >>>>>> > >>>>>> - Cryptographic agility for keys, message signatures, and proof of > possession > >>>>>> > >>>>>> - User interaction mechanisms including web and non-web methods > >>>>>> > >>>>>> - Token presentation mechanisms and key bindings > >>>>>> > >>>>>> > >>>>>> > >>>>>> The artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 and its extensions. > >>>>>> > >>>>>> > >>>>>> > >>>>>> While this work could be done in within the OAuth working group, I > now believe that it should be done in a new working group, and that we > should try to get that working group up and running prior to the Vancouve= r > meeting in March. I think this group should stay here on the TxAuth list, > and it=E2=80=99s my suggestion that the resulting work be called OAuth 3.= 0. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Why a new group? I think that the OAuth working group should remai= n > focused on extending, patching, and adapting OAuth 2.0 to a changing worl= d. > I plan to be engaged in both groups, and I know most of you are as well, > but that=E2=80=99s not universal. Since OAuth 2.0 is so established alrea= dy, there > are a LOT of people who aren=E2=80=99t going to be interested in somethin= g new any > time soon. But on the other hand, there are a number of people for whom > OAuth 2.0 does not work, or is at the very least a poor fit, and we=E2=80= =99ll want > to bring them in at this early stage. So even with significant overlap, I > think there=E2=80=99s enough disconnect in the community from both sides = that > warrants a new group. In addition, I think this is a big enough piece of > work that it=E2=80=99s simply too much for the OAuth working group to be = able to > focus on. We wouldn=E2=80=99t be able to get additional meeting time, and= OAuth > already has trouble fitting into its two meeting slots as it is. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I=E2=80=99ve published a blog post detailing more of my rationale: > >>>>>> > >>>>>> > >>>>>> > >>>>>> https://medium. > .com/@justinsecurity/the-case-for-oauth-3-0-why-a-new-working-group-d6229= ba8e36? > >>>>>> > >>>>>> > >>>>>> > >>>>>> Please suggest changes to the proposed charter text above. It=E2= =80=99s my > hope that we can get the chartering process started. > >>>>>> > >>>>>> > >>>>>> > >>>>>> =E2=80=94 Justin > >>>>>> > >>>>>> -- Txauth mailing list Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > >>>>>> > >>>>>> -- > >>>>>> Txauth mailing list > >>>>>> Txauth@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/txauth > >>>>> > >>>>> -- > >>>>> ---- > >>>>> Aaron Parecki > >>>>> aaronparecki.com > >>>>> @aaronpk > >>>>> > >>>>> > >>>> -- > >>>> ---- > >>>> Aaron Parecki > >>>> aaronparecki.com > >>>> @aaronpk > >>>> > >>>> -- > >>>> Txauth mailing list > >>>> Txauth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/txauth > >>> > >>> > >>> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you. > >>> > >>> > >>> -- > >>> Txauth mailing list > >>> Txauth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/txauth > >> > >> > > > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > > > > --0000000000008b6487059b047172 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The name is important in that calling it OAuth 3 at this p= oint in time will create market uncertainty.

I agree tha= t this work is the successor of OAuth-like systems.=C2=A0
I would= hope that it is also the successor of OIDC-like systems.=C2=A0
<= br>
I'm confused about Aaron's comments about the OAuth W= G wrt. market confusion.=C2=A0

HTTP3 is backwards = compatible with HTTP2 and HTTP 1.x from the developers point of view. The s= ame verbs, headers etc. all work. The interface for developers is the same.= What is on the wire is different.=C2=A0

This work= will not be compatible from a developers point of view wrt. OAuth 2.0


On Tue, Dec 31, 2019 at 10:42 AM Aaron Parecki <aaron@parecki.com> wrote:
I agree with Justin's po= int that the name is not important right now.

That said, OAuth 2 was not backwards compatible with OAuth 1 by
design, so I would expect the same to be true for if and when OAuth 3
ends up becoming a thing, whatever form it takes.

As for the points on market confusion, this TXAuth work is going to
happen regardless of whether the OAuth WG wants it to, either at the
IETF or not, and in my opinion it would have worse effects in the
market if the OAuth WG did not acknowledge it and didn't indicate an eventual plan that this work would subsume OAuth 2. That would just
lead to a situation where people are forced to implement and maintain
both an OAuth 2 and TXAuth system, not because of existing
deployments, but because there would be no clear indication that
TXAuth is the best path for OAuth-like systems going forward.

----
Aaron Parecki
aa= ronparecki.com


On Tue, Dec 31, 2019 at 10:37 AM Justin Richer <jricher@mit.edu> wrote:
>
> And just to reiterate a previous point =E2=80=94 as much as I want to = make the case for calling this work OAuth 3, it=E2=80=99s not something I= =E2=80=99m going to die for. The work is way more important than the name.<= br> >
> So with that, I would propose that we basically punt on naming things = until that becomes important. I say we name both the working group and the = first document =E2=80=9CTxAuth=E2=80=9D, and keep this mailing list as its = base.
>
> If the working group decides in a couple years that this really should= be renamed, we can do that. It=E2=80=99s happened before =E2=80=94 and aga= in I=E2=80=99m calling to the model of HTTP/3. It started as QUIC in the QU= IC working group, and a year ago the QUIC working group decided to rename i= t to HTTP/3, with the coordination and blessing of the HTTP working group. = Once QUIC group winds down, the HTTP/3 protocol will come under the steward= ship of the HTTP working group. I can easily see a similar pattern happenin= g here, where we create TxAuth and eventually it gets handed over to the OA= uth WG.
>
>=C2=A0 =E2=80=94 Justin
>
> On Dec 31, 2019, at 8:09 AM, Justin Richer <jricher@mit.edu> wrote:
>
> My understanding is that HTTP3 is not backwards compatible, since QUIC= was built on UDP from the start and the considerations are pretty differen= t from TCP there.
>
> I don=E2=80=99t think the safe answer is =E2=80=9Cdo nothing=E2=80=9D = today because there is a large and vibrant community around OAuth 2. The sa= fe answer is to deploy something that solves your problems.
>
> I think that we=E2=80=99re going to have the imaging issue vis a vis = =E2=80=9Creplacing OAuth 2=E2=80=9D whether we call this OAuth 3 or TxAuth = or whatever. Truth is for some people we will be replacing OAuth 2, and som= e people will be throwing out their OAuth 2 implementations (if we=E2=80=99= re successful). But that=E2=80=99s the cost of tracking new technology, and= it=E2=80=99s pretty clear to me that this work has a long ways to go.
>
>=C2=A0 =E2=80=94 Justin
>
> On Dec 30, 2019, at 6:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> I significant difference in this case is that OAuth 3 is NOT backward = compatible with OAuth 2.
>
> HTTP 2 was backwards compatible, as is HTTP 3 from what I understand.<= br> >
> This has enterprises question what they should do, and the safe answer= is do nothing. I think this is what Brian was getting at on confusion. Peo= ple are confused on what they should do. OAuth 3 not being backward compati= ble implies work done with OAuth 2 may have to be thrown away.
>
>
> On Sat, Dec 28, 2019 at 9:07 AM Justin Richer <jricher@mit.edu> wrote:
>>
>> This is going to be the case whatever we call this new work. Progr= ess is going to continue to happen, and if a large enterprise decides to wa= it for the new shiny thing 3 years from now, then that=E2=80=99s on them. >>
>> In my experience, it=E2=80=99s more likely that a large enterprise= is going to shy away from the new shiny thing and go with what they can bu= y in a supported package off the shelf. And I think that=E2=80=99s the kind= of timescale that=E2=80=99s going to drive most of the developers decision= s around whether to track the new work or use what=E2=80=99s out there =E2= =80=94 they need to ask =E2=80=9Cwhat do I need?=E2=80=9D And =E2=80=9Cwhen= do I need it?=E2=80=9D
>>
>> But these are :always: the questions that you need to ask when sta= rting a project and choosing technologies.
>>
>> I still contend that the name OAuth 3 does a better job at communi= cating what=E2=80=99s going on here.
>>
>>=C2=A0 =E2=80=94 Justin
>>
>> On Dec 27, 2019, at 1:27 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>> I agree with Brian. Developers such as large enterprise customers = are going to be confused when they hear there is an OAuth 3 in the works. S= ome will push pause on projects because they worry that it will be outdated= when it is released. They won't know which to deploy, even though OAut= h 3 is not available.
>>
>> Also, if what we are working on includes authentication / identity= -- it no longer is just delegated authorization
>>
>> See inline comments below.
>>
>>
>> On Tue, Dec 24, 2019 at 4:22 PM Justin Richer <jricher@mit.edu> wrote:
>>>
>>> Brian, I hear what you=E2=80=99re saying, but I disagree compl= etely.
>>>
>>> Who would be confused by seeing a major revision to an existin= g protocol that worked in a different way and did the same things but also = new things? That happens all the time.
>>
>>
>> And it causes market confusion all the time. Conservative organiza= tions stop doing things when it is not clear what the future will be.
>>
>>>
>>>
>>> Was there significant confusion between OAuth 1 and 2, enough = to hamper adoption of either? For the people who deeply invested in OAuth 1= and didn=E2=80=99t need or want the OAuth 2 newness, they stuck with it (s= ee: twitter).
>>
>>
>> Twitter stuck with OAuth 1 because they did not like bearer tokens= .
>>
>> Yes, there was lots of confusion between OAuth 1 and 2. Erin did n= ot want what became OAuth 2 to be called OAuth because of the confusion. He= nce it was called WRAP early. The actual name of the WG is "Web Author= ization Protocol"
>>
>>
>>>
>>>
>>> Was OpenID Connect a major disservice to OpenID 2? It was a di= sruption, for sure, but people transitioned where it made sense for them, a= nd in many cases that took years of dual-deployment and transition.
>>
>>
>> The work that was being done on OpenID 3 was killed because a larg= e platform company that starts with G did not want to confuse their custome= rs about a new version.
>>
>>>
>>>
>>> I see us walking along the same kind of path here, nearly a de= cade later. That=E2=80=99s why I think OAuth 3 makes sense as a name for th= e output of this work. Or at the very least, for the core delegation protoc= ol portion of whatever we make. I think it sends the right message to imple= menters and developers: the community that knows and understands OAuth 2 is= working on the next version of that thing, so when it=E2=80=99s ready, may= be you should look at it. Until it=E2=80=99s done, and for a long time afte= r, OAuth 2 is still going to be there and be the right answer.
>>
>>
>> I agree that people may be confused if it is called something else= that OAuth, but if it is broader than OAuth, then that is confusing as wel= l.
>>
>>>
>>>
>>> The name isn=E2=80=99t a hill I=E2=80=99m committed to dying a= lone on, but I think it sends a :bad: message if we call it something new e= ntirely. Namely, that we think people :should: abandon the entire world of = OAuth, all of its ideas and implementations. That=E2=80=99s not what we=E2= =80=99re doing with this design, it=E2=80=99s an evolution as I see things.= And as an evolution, a new major revision number makes sense.
>>>
>>>=C2=A0 =E2=80=94 Justin
>>>
>>> On Dec 24, 2019, at 9:54 AM, Brian Campbell <bcampbell@pingidentity.co= m> wrote:
>>>
>>> Naming any prospective resulting work here "OAuth 3.0&quo= t; would significantly exacerbate confusion in the whole space and would be= a major disservice to the broader community.
>>>
>>>
>>> On Mon, Dec 23, 2019 at 7:39 PM Aaron Parecki <aaron@parecki.com> wrote:=
>>>>
>>>> I definitely am not trying to discuss specifics of *how* a= uthentication should be included right now, but I just want to make sure it= 's included in the charter so that we can actually talk about it and it= won't be "out of scope" when we eventually do talk about the= specifics.
>>>>
>>>> Aaron
>>>>
>>>>
>>>>
>>>> On Mon, Dec 23, 2019 at 1:51 PM Justin Richer <jricher@mit.edu> wrote= :
>>>>>
>>>>> I=E2=80=99m fine with it being in charter but I do thi= nk it should be a clearly separate layer, much like OIDC/Facebook Connect/G= itHub Login/etc are with OAuth today. In all of these the authorization is = first, and I think that=E2=80=99s the right pattern. So if we do take it on= we=E2=80=99ll just need to be careful how it=E2=80=99s structured in with = everything else. Otherwise, I think the authentication side can quickly ove= rwhelm and drag down the authorization side.
>>>>>
>>>>> Good news: A lot of the additional stuff in OIDC is th= ere to patch holes in core OAuth in a common fashion, and we=E2=80=99ll at = least be in a position to not have to do that again.
>>>>>
>>>>>
>>>>>=C2=A0 =E2=80=94 Justin
>>>>>
>>>>> On Dec 22, 2019, at 10:46 PM, Aaron Parecki <aaron@parecki.com> = wrote:
>>>>>
>>>>> I do think authentication should be part of the charte= r from the outset. Frankly the fact that authentication is intentionally le= ft out of OAuth and has to be bolted on to the side via OpenID Connect is o= ne of the exact reasons people get confused about the whole space to begin = with.
>>>>>
>>>>> It's a relatively minor addition to the existing p= roposed spec to make it useful as a minimum viable authentication solution,= and I'd like to see that be addressed at the beginning of this work. >>>>>
>>>>> I think we can do this in a smart way and that authent= ication should be included in the charter.
>>>>>
>>>>> Aaron
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Dec 21, 2019 at 1:51 PM Yaron Sheffer <yaronf.ietf@gmail.co= m> wrote:
>>>>>>
>>>>>> Hi Justin,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I think the charter should mention target use case= s. For example, =E2=80=9Call use cases supported by OAuth 2 will be support= ed by the new protocol=E2=80=9D or =E2=80=9Cthe protocol will support at le= ast use cases X and Y=E2=80=9D.
>>>>>>
>>>>>>
>>>>>>
>>>>>> And given the importance of OIDC, we could say som= ething like: =E2=80=9CThe protocol will allow future extension to support a= uthentication, in an analogous way to OpenID Connect. However authenticatio= n is explicitly not part of the initial scope.=E2=80=9D
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Yaron
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Txauth <txauth-bounces@ietf.org> on behalf of Ju= stin Richer <jriche= r@mit.edu>
>>>>>> Date: Saturday, December 21, 2019 at 00:34
>>>>>> To: <txauth@ietf.org>
>>>>>> Cc: "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>
>>>>>> Subject: [Txauth] TxAuth Proposed Charter
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>>
>>>>>>
>>>>>> As discussed in Singapore, no matter what forum Tx= Auth takes, its work will require a new charter. With that in mind, I=E2=80= =99ve taken a bit of time to put together a proposed charter text for the T= xAuth work:
>>>>>>
>>>>>>
>>>>>>
>>>>>> This group is chartered to develop a next-generati= on transactional authorization and delegation protocol for HTTP-based APIs = and their clients. These transactions will allow an authorizing party to de= legate a right of access for an API or set of APIs through an authorization= server to a software client acting on behalf of an authorizing party.
>>>>>>
>>>>>>
>>>>>>
>>>>>> The group will deliver a protocol specification de= tailing how a client can request and obtain delegated access, how an author= ization server can provide delegated access, how an authorized party can au= thorize delegated access, and how that authorized access can be communicate= d to the resources being protected. These actions will be connected through= an explicit transaction between the client and authorization server, resul= ting in an artifact that will allow the client to undertake the delegated a= ction.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Additionally, the delegation process will allow fo= r:
>>>>>>
>>>>>> - Fine-grained specification of resource access >>>>>>
>>>>>> - Delegation between multiple users
>>>>>>
>>>>>> - Web, mobile, single-page, and other client appli= cations
>>>>>>
>>>>>>
>>>>>>
>>>>>> The group will define extension points for this pr= otocol to allow for flexibility in areas including:
>>>>>>
>>>>>>
>>>>>>
>>>>>> - Cryptographic agility for keys, message signatur= es, and proof of possession
>>>>>>
>>>>>> - User interaction mechanisms including web and no= n-web methods
>>>>>>
>>>>>> - Token presentation mechanisms and key bindings >>>>>>
>>>>>>
>>>>>>
>>>>>> The artifacts for this work are not intended or ex= pected to be backwards-compatible with OAuth 2.0 and its extensions.
>>>>>>
>>>>>>
>>>>>>
>>>>>> While this work could be done in within the OAuth = working group, I now believe that it should be done in a new working group,= and that we should try to get that working group up and running prior to t= he Vancouver meeting in March. I think this group should stay here on the T= xAuth list, and it=E2=80=99s my suggestion that the resulting work be calle= d OAuth 3.0.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Why a new group? I think that the OAuth working gr= oup should remain focused on extending, patching, and adapting OAuth 2.0 to= a changing world. I plan to be engaged in both groups, and I know most of = you are as well, but that=E2=80=99s not universal. Since OAuth 2.0 is so es= tablished already, there are a LOT of people who aren=E2=80=99t going to be= interested in something new any time soon. But on the other hand, there ar= e a number of people for whom OAuth 2.0 does not work, or is at the very le= ast a poor fit, and we=E2=80=99ll want to bring them in at this early stage= . So even with significant overlap, I think there=E2=80=99s enough disconne= ct in the community from both sides that warrants a new group. In addition,= I think this is a big enough piece of work that it=E2=80=99s simply too mu= ch for the OAuth working group to be able to focus on. We wouldn=E2=80=99t = be able to get additional meeting time, and OAuth already has trouble fitti= ng into its two meeting slots as it is.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I=E2=80=99ve published a blog post detailing more = of my rationale:
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://medium..com/@justinsecurity/the-case-for-oauth-3= -0-why-a-new-working-group-d6229ba8e36?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please suggest changes to the proposed charter tex= t above. It=E2=80=99s my hope that we can get the chartering process starte= d.
>>>>>>
>>>>>>
>>>>>>
>>>>>>=C2=A0 =E2=80=94 Justin
>>>>>>
>>>>>> -- Txauth mailing list Txauth@ietf.org https://ww= w.ietf.org/mailman/listinfo/txauth
>>>>>>
>>>>>> --
>>>>>> Txauth mailing list
>>>>>> Txauth@ietf.org
>>>>>> https://www.ietf.org/mailman/li= stinfo/txauth
>>>>>
>>>>> --
>>>>> ----
>>>>> Aaron Parecki
>>>>> aaronparecki.com
>>>>> @aaronpk
>>>>>
>>>>>
>>>> --
>>>> ----
>>>> Aaron Parecki
>>>> aaronparecki.com
>>>> @aaronpk
>>>>
>>>> --
>>>> Txauth mailing list
>>>> Txaut= h@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/t= xauth
>>>
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential an= d privileged material for the sole use of the intended recipient(s). Any re= view, use, distribution or disclosure by others is strictly prohibited.=C2= =A0 If you have received this communication in error, please notify the sen= der immediately by e-mail and delete the message and any file attachments f= rom your computer. Thank you.
>>>
>>>
>>> --
>>> Txauth mailing list
>>> Txauth@ie= tf.org
>>> https://www.ietf.org/mailman/listinfo/txa= uth
>>
>>
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth >
>
--0000000000008b6487059b047172-- From nobody Tue Dec 31 11:00:20 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F71512001A for ; Tue, 31 Dec 2019 11:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cPyGeQLQaQdT for ; Tue, 31 Dec 2019 11:00:17 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 CF180120013 for ; Tue, 31 Dec 2019 11:00:16 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id b15so27498237lfc.4 for ; Tue, 31 Dec 2019 11:00:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mSX92jhi4OMkoiSb2C3KezIiCJUb9rfhxWoaeR8+YcM=; b=RaqBZgLFDVYnKBXsJ1RO9NfcRu9azgTkTMOUrk4nTzYqEC3Wu/I4n69o2KsZ/bEWe/ KdohDDqXaY5I71fdt4WG+WYHV1HS7ZWK6xrHOh5dGr92I+OldGxR1qOBsqtXredqy0GS SxbT63GRpelw6Ya6KzjftoH9wX75yJwjdcRNcrE50yNZ0Mgw3bFdGo5VpDSpjjG3uQq9 6M7KE6+/iz/dNgrulOvwflhrOYqpzYKeU/HPn7C/LN+0nwcfBdd331Jura1TbhRWAzSt NFJyWXdlOZSJvlWv2ZZt84PiR36TA/VUQ3zcyQs4X/WONP7pVsVa5WFE8J4s0ue4si1q Ssnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mSX92jhi4OMkoiSb2C3KezIiCJUb9rfhxWoaeR8+YcM=; b=QDVrA8Xo4xg9IIzFZoZgtqnkFkHp30GymDm6ZhuU5FYwSyicnep3cJdObjl1dv4HFO 7js8tdgcrKWehq52mfKg9DsE4ca/nYVDWxtgbLvGsGSWnMPRIneR6yX0MakBisQ7d4VV rXTKPbdVanmTg1FA/WDTn/f0SZGSFKDcH9s6BpEH4cr717HiLusEXGbYzhobZJkd7sCF 5FsuisMWqziSuCrXW4uA/qULUvC8eN1qR6oBbG30cmCPd0Q7R+SCLLBdkA2gbMdaxcRe Defyhl2cvR9IUUAjdH97ImXD9hO0qA9b0SRqU2gV8tOdkFOVQfAk4rrzSLye9DN/B6Qj q2gg== X-Gm-Message-State: APjAAAW8C3KWqQ6JA9lICT2tStmZy6JvasXljCSPiVO53Vj7FODAwJir k29PKeY91/G6FgG/I88+uA7ZHAaoCc6ZNI0vxrk= X-Google-Smtp-Source: APXvYqw+4iUh95CwuTXJmyrDeXfnJ6lEmu91ZKKxSWNbk03YSlDSxdPAO6j/sw4W8UnqT0VHVWn4k3eb/MBPaPa060U= X-Received: by 2002:a19:5057:: with SMTP id z23mr41343251lfj.132.1577818814800; Tue, 31 Dec 2019 11:00:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 31 Dec 2019 11:00:03 -0800 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000f9ebce059b0491a8" Archived-At: Subject: Re: [Txauth] Framework vs Protocol X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 19:00:19 -0000 --000000000000f9ebce059b0491a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A couple questions inserted to understand what you are suggesting ... On Tue, Dec 31, 2019 at 5:06 AM Justin Richer wrote: > I agree with this. I think that with OAuth2 the extension mechanism of > grant types was a decent idea, and I=E2=80=99ve argued that it leads to s= ignificant > amounts of code-reuse from very different systems that function in very > different ways. > > But I also think that what I=E2=80=99d like to see here, and what I=E2=80= =99ve tried to do > with XYZ, is to have one protocol that lets you branch off for different > use cases where necessary but still brings you back to the same process i= n > the end. "... brings you back to the same process in the end." -- implies something different than below where the process may branch off and end up in a different place. Would you clarify what you mean? > This is one of the things I like about having the AS defined as the > transaction endpoint =E2=80=94 everyone goes to one place and sends one k= ind of > message to start things off, and then you have everything you need to > figure out where to go from there, even if it=E2=80=99s off-HTTP and out-= of-band. > A way to start the transaction in COAP would likely be interesting to the constrained environment people. Would you not agree? > > =E2=80=94 Justin > > > On Dec 30, 2019, at 7:20 PM, Dick Hardt wrote: > > > > I would propose that the resulting work is a protocol, and not a > framework. > > > > What is the difference? Here are my thoughts: > > > > A framework defines a variety of ways to do each capability. A framewor= k > usually needs a profile for two systems to interoperate. For example, OID= C > provides a number of ways to get identity data from an OP, and OAuth 2 > grant types have overlap. A framework is like Perl. Lots of ways to do th= e > same thing, many of which are unreadable. > > > > A protocol provides one way to do each capability. A protocol is like > Python, there is a right way to do something. > > > > At times a standards group will get "consensus" by not being decisive, > and including everyone's favored mechanism. In my opinion, this makes > deployments more complicated for average developers, and increases the > surface area to secure. > > > > Do others agree with adding this as a tenet to the charter? > > > > /Dick > > > > Note: I'm a fan of both Perl and Python. =3D) > > > > -- > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth > > --000000000000f9ebce059b0491a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A couple questions inserted to understand= what you are=C2=A0suggesting ...=C2=A0

On Tue, Dec 31, 2019 at 5:06 AM Just= in Richer <jricher@mit.edu> wr= ote:
I agree wit= h this. I think that with OAuth2 the extension mechanism of grant types was= a decent idea, and I=E2=80=99ve argued that it leads to significant amount= s of code-reuse from very different systems that function in very different= ways.

But I also think that what I=E2=80=99d like to see here, and what I=E2=80= =99ve tried to do with XYZ, is to have one protocol that lets you branch of= f for different use cases where necessary but still brings you back to the = same process in the end.

"... brings = you back to the same process in the end." -- implies something differe= nt than below where the process may branch off and end up in a different pl= ace. Would you clarify what you mean?
=C2=A0
This is one of the things I like about h= aving the AS defined as the transaction endpoint =E2=80=94 everyone goes to= one place and sends one kind of message to start things off, and then you = have everything you need to figure out where to go from there, even if it= =E2=80=99s off-HTTP and out-of-band.

A= way to start the transaction in COAP would likely be interesting to the co= nstrained environment people. Would you not agree?
=C2=A0

=C2=A0=E2=80=94 Justin

> On Dec 30, 2019, at 7:20 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> I would propose that the resulting work is a protocol, and not a frame= work.
>
> What is the difference? Here are my thoughts:
>
> A framework defines a variety of ways to do each capability. A framewo= rk usually needs a profile for two systems to interoperate. For example, OI= DC provides a number of ways to get identity data from an OP, and OAuth 2 g= rant types have overlap. A framework is like Perl. Lots of ways to do the s= ame thing, many of which are unreadable.
>
> A protocol provides one way to do each capability.=C2=A0 A protocol is= like Python, there is a right way to do something.
>
> At times a standards group will get "consensus" by not being= decisive, and including everyone's favored mechanism. In my opinion, t= his makes deployments more complicated for average developers, and increase= s the surface area to secure.
>
> Do others agree with adding this as a tenet to the charter?
>
> /Dick
>
> Note: I'm a fan of both Perl and Python. =3D)
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
--000000000000f9ebce059b0491a8-- From nobody Tue Dec 31 11:01:32 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DF412001A for ; Tue, 31 Dec 2019 11:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 0K-7LYiM6Rr0 for ; Tue, 31 Dec 2019 11:01:27 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3DF94120013 for ; Tue, 31 Dec 2019 11:01:27 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBVJ1M9A027156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Dec 2019 14:01:23 -0500 From: Justin Richer Message-Id: <3066B58F-47D5-48C6-B705-A9F3F58EB496@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_5F5431CD-FD80-44C5-9187-D68486A93CE6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 31 Dec 2019 14:01:22 -0500 In-Reply-To: Cc: Eve Maler , "rdd@cert.org" , txauth@ietf.org, Benjamin Kaduk To: Dick Hardt References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <07AEE8DB-A0EE-4780-9CE7-B578F69948F9@mit.edu> <68CA5C79-10AB-42E6-B4A9-06A594CA436C@mit.edu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 19:01:32 -0000 --Apple-Mail=_5F5431CD-FD80-44C5-9187-D68486A93CE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 >>=20 >>>=20 >>> 2. Why do you restrict this to HTTP? >>=20 >> Because I want us to use all of the features and benefits of HTTP = instead of having to invent within-protocol functions to replicate them. = I don=E2=80=99t want SOAP, which pretends to be transport agnostic much = to its detriment. If someone wants to do OAuth 3 on not-HTTP, they can = define what that looks like. This is what happened with the COAP/CORE = stuff and OAuth 2. >>=20 >> I agree SOAP was complicated. Which features and benefits of HTTP are = you wanting to use?=20 >>=20 >=20 > Well so far we=E2=80=99ve got headers, URLs, methods, data payload = types, and the whole array of technologies that we can rely on working = together along with HTTP. >=20 > But which ones do you want to use? > =20 Those things that I already listed are what I want to use. I want to use = the headers for sending key proofs and probably content negotiation. I = want to have content negotiation so that we can have an option to use = JOSE (or COSE) as the body format instead of JSON, but that function = switch should come from the transport protocol (HTTP) and not something = internal to our protocol. I want to be able to use redirects to get the = user to interact, and get back from the interaction. I want to = (eventually) do things like token revocation using a DELETE verb instead = of a separate endpoint. I want to use HTTP Message Signatures (once they = exist) as a key presentation mechanism. And I want our security = considerations to be able to take into account the particulars of HTTP, = TLS, and the like when we write them. >=20 >=20 >> If it was simple to support COAP, why would we not do that? >=20 > Because it=E2=80=99s not just COAP =E2=80=94 you=E2=80=99ve got a = different set of assumptions for the lower layer protocols, and you=E2=80=99= ve got lots of considerations about how the different components can = talk to each other in the embedded space.=20 >=20 > You are suggesting we rule out it working with COAP in the charter, = before we have even had a chance to work on it. >=20 > Perhaps it will be trivial to support COAP. We won't know if the = charter forbids it. If it turns out to be trivial and people want to include it and do the = work here, then we could always update the charter to include it. I = would rather see that than us trying to enumerate all of the target = carrier mechanisms. Because if we do COAP, why not MQTT? Or BluetoothLE?=20= If we include COAP, then to my mind that necessitates one of two things, = if not both: 1) We have a document that says =E2=80=9CIF you=E2=80=99re doing HTTP do = (A) if you=E2=80=99re doing COAP do (B)=E2=80=9D 2) We have an =E2=80=9Cabstract=E2=80=9D document that says =E2=80=9Chere=E2= =80=99s this thing but for details on how to do it go read the HTTP = document and/or the COAP document=E2=80=9D, but when you read the HTTP = or COAP documents, they don=E2=80=99t have any information about what = the thing is because it=E2=80=99s in the abstract.=20 =46rom a developer=E2=80=99s perspective, I would rather have an HTTP = document be self-contained, and a COAP document be self-contained. And = if the two describe the same process, or one inherits from the other but = says =E2=80=9Cinstead of doing HTTP thing X do COAP equivalent Y=E2=80=9D,= then that=E2=80=99s good.=20 But overly abstracting a system is both tempting and potentially = disastrous.=20 > =20 >=20 > In my experience, it=E2=80=99s much more successful to have a protocol = strongly integrated with its transport mechanism and then translated out = to other mechanisms, instead of trying to come up with one universal = interlingua of a protocol that just get shunted along. >=20 > Would you provide an example besides SOAP for this? It=E2=80=99s the most egregious example that comes to mind for me, so = that=E2=80=99s why I keep coming back to it. I also have in mind a dozen = projects that never went anywhere, and nobody=E2=80=99s heard of, = because of an outmoded effort being put into defining abstractions ahead = of time in order to allow transport-agnostic messaging.=20 A similar level of overly-eager abstraction went into JOSE, with the JWA = document. It makes it so that JWS, JWE, and JWK make no sense without = JWA, and JWA is just a collection of content that really should have = been included inline with the other documents.=20 I want to avoid that kind of thing. > =20 > This is why SOAP can=E2=80=99t use HTTP verbs to communicate things, = and why the only signatures it can use are internal. When you do that = kind of system, you almost always end up having people just use it with = one transport anyway, like SOAP over HTTP. >=20 >> =20 >>=20 >>>=20 >>> 3. Why is authentication not in scope? >>=20 >> It felt, to me, like that might be a bridge too far. >>=20 >> I disagree. But I also think that authentication is the wrong term. = Identity* may be a term that maps better, as the Client is wanting to = get "identity" data from the AS.=20 >>=20 >> * The identity term is super confusing, but authentication implies = just knowing it is the same user, where OpenID Connect also provides = claims about the user. >=20 > I=E2=80=99m coming around to this view, but I would still like it to = be separate. >=20 > What does separate mean? It means that the bits that say =E2=80=9Cthis is how you talk about = identity information in the response=E2=80=9D are controlled by a = separate spec that not everyone needs to understand. I think there are = too many use cases of wanting to get API access and NOT user information = for it to be a core piece.=20 However, this is arguably getting into the details of how to slice up = different documents, which is really a decision to be made once the WG = is running and not during the charter.=20 > =20 >=20 >> =20 >> If we do decide it=E2=80=99s in scope, then I think it should be = clearly layered on top of the authorization layer.=20 >>=20 >> Being layered on top is confusing. An OpenID Connect flow where the = Client receives an ID token, has not authorization, unless you are = counting the UX as authorization -- but that does not seem like a layer. = Would you elaborate? >> =20 >=20 > What you=E2=80=99re doing in OIDC is authorizing the application to = know who you are =E2=80=94 to get your identity information. That key = insight is what makes the combination of OAuth and OIDC work as well as = it does. And, importantly, once you authorize identity access, you can = authorize other stuff as well. >=20 >=20 > As I stated, there is the UX of authorizing knowing who the user is, = but there is no artifact representing that authorization as there is in = OAuth -- ie there is no access token to access a resource. (yes, an = access token may be used to read the user info endpoint, but that is all = it can do.=20 > =20 > And it=E2=80=99s the =E2=80=9Cand other stuff=E2=80=9D that people = really, really, really like about OIDC. Nobody ever wants just = authorization, in practice.=20 >=20 > Did you mean to say "authentication"? >=20 > If so, then I would posit that there are more OIDC user interactions = than plain OAuth 2.0 user interactions, and that almost all of those = OIDC user interactions are just logging in with Google or Facebook -- = and that there is no "and other stuff". >=20 Yes, I meant authentication, thank you.=20 I=E2=80=99m not sure it=E2=80=99s true, but I=E2=80=99ll agree that = it=E2=80=99s more public-facing. But even if what you posit is actually = true by raw numbers, it=E2=80=99s not universal. In particular, there = are a large number of system-to-system cases that OAuth 2 covers, which = have nothing to do with identity, that we don=E2=80=99t want to throw = out. >=20 > =20 > =20 >=20 >>=20 >>>=20 >>> 4. When you say "not backwards compatible with OAuth 2.0 and its = extensions", do you expect to define a new standard to replace RFC 6750? = Developers will have to have a new method to call APIs? >>=20 >> Kinda. First, it=E2=80=99s more 6749 that I want to step away from. = But even then, I think keeping just the header version of 6750 is OK = enough if someone wants to keep using that. The thing is, won=E2=80=99t = someone seeing an OAuth 2 header assume the rest of OAuth 2 = infrastructure? In some cases this won=E2=80=99t matter, but in many = that could be really confusing.=20 >>=20 >> One of the problems, though, is that 6750 has already been clouded by = things like the MTLS binding, where they use =E2=80=9Cbearer=E2=80=9D = tokens that have to be bound to the client=E2=80=99s certificate. So =E2=80= =A6 not much of a bearer token anymore. >>=20 >> So, are you are you proposing that Tx have a new mechanism for API = calls? >=20 > Yes, I think there will be new mechanisms for different kinds of = key-bound tokens. >=20 > So are you proposing that OAuth 3.0 will not support bearer tokens? That is not correct and I=E2=80=99m not sure where you got that. Bearer = tokens are still useful. But they should look and behave as distinct = from sender-constrained tokens. But ultimately we can tell the client = how the token gets used, as below. > =20 >=20 >> =20 >>=20 >> Ultimately, I don=E2=80=99t want anything that has an = error-fallthrough compatibility process. That is to say, I try doing = OAuth 2, have that fail, and then try it as OAuth 3 =E2=80=94 or vice = versa. >>=20 >> Ok. I'm not even sure how that would happen, but ok. >=20 > So in OAuth 2 the token parameter was originally called = =E2=80=9Coauth_token=E2=80=9D, which is the same as in OAuth 1. But the = difference is that in OAuth 2 there=E2=80=99s no = =E2=80=9Coauth_token_signature=E2=80=9D field, so to support both = you=E2=80=99d need to try to do OAuth 1, then fail, and then try to do = OAuth 2. Since the nature of the tokens is completely different, I see = that as a problem. >=20 > However, with this (and with how XYZ=E2=80=99s started things), = we=E2=80=99ve got an opportunity to say things like =E2=80=9Cif you see = this type of token response, use it with the RS according to RFC6750=E2=80= =9D or =E2=80=9Caccording to this new RFC we just made up=E2=80=9D or = whatever. >=20 > Got it. Agreed that we can provide a richer response that indicates = how a token (or whatever) can be used. Exactly. I should give you all the information on how to use the = artifact alongside of the artifact itself. It=E2=80=99ll also give us a = way to do server-side provisioning of keys bound to the tokens = themselves. So I can generate a public/private keypair at the AS and = hand it to the client, but I only save the public portion so that the RS = can eventually validate it. (Or I do key wrapping or pack it into the = token so I don=E2=80=99t have to save anything.) This is particularly = useful for disadvantaged clients, which you=E2=80=99ve said above = you=E2=80=99d like to be in scope anyway. ;) =E2=80=94 Justin= --Apple-Mail=_5F5431CD-FD80-44C5-9187-D68486A93CE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8



2. Why do you restrict = this to HTTP?

Because I want us to use all of the = features and benefits of HTTP instead of having to invent = within-protocol functions to replicate them. I don=E2=80=99t want SOAP, = which pretends to be transport agnostic much to its detriment. If = someone wants to do OAuth 3 on not-HTTP, they can define what that looks = like. This is what happened with the COAP/CORE stuff and OAuth = 2.

I agree SOAP was complicated. Which features and benefits of = HTTP are you wanting to use? 


Well so far we=E2=80=99ve got headers, = URLs, methods, data payload types, and the whole array of technologies = that we can rely on working together along with = HTTP.

But which ones do you want to = use?
 

Those things that I already listed are what I want = to use. I want to use the headers for sending key proofs and probably = content negotiation. I want to have content negotiation so that we can = have an option to use JOSE (or COSE) as the body format instead of JSON, = but that function switch should come from the transport protocol (HTTP) = and not something internal to our protocol. I want to be able to use = redirects to get the user to interact, and get back from the = interaction. I want to (eventually) do things like token revocation = using a DELETE verb instead of a separate endpoint. I want to use HTTP = Message Signatures (once they exist) as a key presentation mechanism. = And I want our security considerations to be able to take into account = the particulars of HTTP, TLS, and the like when we write them.



If it was simple to support COAP, = why would we not do that?

Because it=E2=80=99s not = just COAP =E2=80=94 you=E2=80=99ve got a different set of assumptions = for the lower layer protocols, and you=E2=80=99ve got lots of = considerations about how the different components can talk to each other = in the embedded space. 

You are suggesting we = rule out it working with COAP in the charter, before we have even had a = chance to work on it.

Perhaps it will be trivial to support COAP. We won't know if = the charter forbids it.

If it turns out to be trivial and people want to = include it and do the work here, then we could always update the charter = to include it. I would rather see that than us trying to enumerate all = of the target carrier mechanisms. Because if we do COAP, why not MQTT? = Or BluetoothLE? 

If we include = COAP, then to my mind that necessitates one of two things, if not = both:

1) We have a document that = says =E2=80=9CIF you=E2=80=99re doing HTTP do (A) if you=E2=80=99re = doing COAP do (B)=E2=80=9D
2) We have an =E2=80=9Cabstract=E2=80= =9D document that says =E2=80=9Chere=E2=80=99s this thing but for = details on how to do it go read the HTTP document and/or the COAP = document=E2=80=9D, but when you read the HTTP or COAP documents, they = don=E2=80=99t have any information about what the thing is because = it=E2=80=99s in the abstract. 

=46rom a developer=E2=80=99s perspective, I would = rather have an HTTP document be self-contained, and a COAP document be = self-contained. And if the two describe the same process, or one = inherits from the other but says =E2=80=9Cinstead of doing HTTP thing X = do COAP equivalent Y=E2=80=9D, then that=E2=80=99s = good. 

But overly abstracting a = system is both tempting and potentially disastrous. 

 

In my experience, it=E2=80=99s much more successful to have a = protocol strongly integrated with its transport mechanism and then = translated out to other mechanisms, instead of trying to come up with = one universal interlingua of a protocol that just get shunted = along.

Would you provide an example besides = SOAP for this?

It=E2=80=99s the most egregious example that comes = to mind for me, so that=E2=80=99s why I keep coming back to it. I also = have in mind a dozen projects that never went anywhere, and nobody=E2=80=99= s heard of, because of an outmoded effort being put into defining = abstractions ahead of time in order to allow transport-agnostic = messaging. 

A similar level of = overly-eager abstraction went into JOSE, with the JWA document. It makes = it so that JWS, JWE, and JWK make no sense without JWA, and JWA is just = a collection of content that really should have been included inline = with the other documents. 

I = want to avoid that kind of thing.

 
This is why SOAP can=E2=80=99t use HTTP verbs to communicate = things, and why the only signatures it can use are internal. When you do = that kind of system, you almost always end up having people just use it = with one transport anyway, like SOAP over HTTP.

 


3. Why = is authentication not in scope?

It felt, to me, like = that might be a bridge too far.

I disagree. But I also = think that authentication is the wrong term. Identity* may be a term = that maps better, as the Client is wanting to get "identity" data from = the AS. 

* = The identity term is super confusing, but authentication implies just = knowing it is the same user, where OpenID Connect also provides claims = about the user.

I=E2=80=99m coming around to this view, = but I would still like it to be = separate.

What does separate = mean?

It = means that the bits that say =E2=80=9Cthis is how you talk about = identity information in the response=E2=80=9D are controlled by a = separate spec that not everyone needs to understand. I think there are = too many use cases of wanting to get API access and NOT user information = for it to be a core piece. 

However, this is arguably getting into the details = of how to slice up different documents, which is really a decision to be = made once the WG is running and not during the charter. 

 

 
If we do decide it=E2=80=99s in scope, then I = think it should be clearly layered on top of the authorization = layer. 

Being layered on top is confusing. An = OpenID Connect flow where the Client receives an ID token, has not = authorization, unless you are counting the UX as authorization -- but = that does not seem like a layer. Would you elaborate?
 

What you=E2=80=99re doing in OIDC is = authorizing the application to know who you are =E2=80=94 to get your = identity information. That key insight is what makes the combination of = OAuth and OIDC work as well as it does. And, importantly, once you = authorize identity access, you can authorize other stuff as = well.


As = I stated, there is the UX of authorizing knowing who the user is, but = there is no artifact representing that authorization as there is in = OAuth -- ie there is no access token to access a resource. (yes, an = access token may be used to read the user info endpoint, but that is all = it can do. 
 
And it=E2=80=99s = the =E2=80=9Cand other stuff=E2=80=9D that people really, really, really = like about OIDC. Nobody ever wants just authorization, in = practice. 

Did you mean to say = "authentication"?

If so, then I would posit that there are more OIDC user = interactions than plain OAuth 2.0 user interactions, and that almost all = of those OIDC user interactions are just logging in with Google or = Facebook -- and that there is no "and other stuff".


Yes, I meant authentication, thank = you. 

I=E2=80=99m not sure = it=E2=80=99s true, but I=E2=80=99ll agree that it=E2=80=99s more = public-facing. But even if what you posit is actually true by raw = numbers, it=E2=80=99s not universal. In particular, there are a large = number of system-to-system cases that OAuth 2 covers, which have nothing = to do with identity, that we don=E2=80=99t want to throw out.


 
 



4. When = you say "not backwards compatible with OAuth 2.0 and its extensions", do = you expect to define a new standard to replace RFC 6750? Developers will = have to have a new method to call = APIs?

Kinda. First, it=E2=80=99s more 6749 = that I want to step away from. But even then, I think keeping just the = header version of 6750 is OK enough if someone wants to keep using that. = The thing is, won=E2=80=99t someone seeing an OAuth 2 header assume the = rest of OAuth 2 infrastructure? In some cases this won=E2=80=99t matter, = but in many that could be really confusing. 
One of the problems, though, is that = 6750 has already been clouded by things like the MTLS binding, where = they use =E2=80=9Cbearer=E2=80=9D tokens that have to be bound to the = client=E2=80=99s certificate. So =E2=80=A6 not much of a bearer token = anymore.

So, are you are you proposing that Tx = have a new mechanism for API = calls?

Yes, I think there will be new = mechanisms for different kinds of key-bound = tokens.

So are you proposing that OAuth 3.0 = will not support bearer tokens?

That is not correct and I=E2=80=99m not sure where = you got that. Bearer tokens are still useful. But they should look and = behave as distinct from sender-constrained tokens. But ultimately we can = tell the client how the token gets used, as below.

 

 

Ultimately, I don=E2=80=99t want anything that has an = error-fallthrough compatibility process. That is to say, I try doing = OAuth 2, have that fail, and then try it as OAuth 3 =E2=80=94 or vice = versa.

Ok. I'm not even sure how that would = happen, but ok.

So in OAuth 2 the token parameter was = originally called =E2=80=9Coauth_token=E2=80=9D, which is the same as in = OAuth 1. But the difference is that in OAuth 2 there=E2=80=99s no = =E2=80=9Coauth_token_signature=E2=80=9D field, so to support both = you=E2=80=99d need to try to do OAuth 1, then fail, and then try to do = OAuth 2. Since the nature of the tokens is completely different, I see = that as a problem.

However, with this (and with how XYZ=E2=80=99s started = things), we=E2=80=99ve got an opportunity to say things like =E2=80=9Cif = you see this type of token response, use it with the RS according to = RFC6750=E2=80=9D or =E2=80=9Caccording to this new RFC we just made = up=E2=80=9D or whatever.
Got it. Agreed that we can provide a = richer response that indicates how a token (or whatever) can be = used.

Exactly. I = should give you all the information on how to use the artifact alongside = of the artifact itself. It=E2=80=99ll also give us a way to do = server-side provisioning of keys bound to the tokens themselves. So I = can generate a public/private keypair at the AS and hand it to the = client, but I only save the public portion so that the RS can eventually = validate it. (Or I do key wrapping or pack it into the token so I = don=E2=80=99t have to save anything.) This is particularly useful for = disadvantaged clients, which you=E2=80=99ve said above you=E2=80=99d = like to be in scope anyway. ;)



 =E2=80=94 Justin
= --Apple-Mail=_5F5431CD-FD80-44C5-9187-D68486A93CE6-- From nobody Tue Dec 31 11:13:06 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3D912001E for ; Tue, 31 Dec 2019 11:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0OiiYi0UqnhO for ; Tue, 31 Dec 2019 11:13:01 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3C5FD120013 for ; Tue, 31 Dec 2019 11:13:01 -0800 (PST) Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBVJCwuR029667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Dec 2019 14:12:58 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_789E7005-58FE-4028-8A21-FDD94ACA6920" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 31 Dec 2019 14:12:57 -0500 In-Reply-To: Cc: txauth@ietf.org To: Dick Hardt References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Txauth] Framework vs Protocol X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 19:13:04 -0000 --Apple-Mail=_789E7005-58FE-4028-8A21-FDD94ACA6920 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Answers inline. > On Dec 31, 2019, at 2:00 PM, Dick Hardt wrote: >=20 > A couple questions inserted to understand what you are suggesting ...=20= >=20 > On Tue, Dec 31, 2019 at 5:06 AM Justin Richer > wrote: > I agree with this. I think that with OAuth2 the extension mechanism of = grant types was a decent idea, and I=E2=80=99ve argued that it leads to = significant amounts of code-reuse from very different systems that = function in very different ways.=20 >=20 > But I also think that what I=E2=80=99d like to see here, and what = I=E2=80=99ve tried to do with XYZ, is to have one protocol that lets you = branch off for different use cases where necessary but still brings you = back to the same process in the end. >=20 > "... brings you back to the same process in the end." -- implies = something different than below where the process may branch off and end = up in a different place. Would you clarify what you mean? I didn=E2=80=99t mean to imply that you=E2=80=99d end up somewhere else, = but rather that you=E2=80=99d potentially take a detour through some = other mechanism and come back to the same thing that you started. So I = start by making an HTTP call, and then maybe I blip out a number over my = speaker, or I send a DIDComm message to an agent on my device, or I = redirect the user off in some browser thing =E2=80=94 but then = eventually I go back to making an HTTP call. The variability is in the = middle part, where the user interaction is involved. The variability = should not be in how the clients talk to other systems. > =20 > This is one of the things I like about having the AS defined as the = transaction endpoint =E2=80=94 everyone goes to one place and sends one = kind of message to start things off, and then you have everything you = need to figure out where to go from there, even if it=E2=80=99s off-HTTP = and out-of-band.=20 >=20 > A way to start the transaction in COAP would likely be interesting to = the constrained environment people. Would you not agree? I totally agree. And they=E2=80=99d also want to continue and finish the = transaction in COAP. And be able to do redirects using COAP principles = instead of HTTP principles. And generally do things that are similar but = not the same. So it turns into a different protocol with the same ideas, = and I=E2=80=99m all for that happening =E2=80=94 but I don=E2=80=99t = think it=E2=80=99s a good idea to put it all in the same document, or to = have an abstract document that everyone tries to inherit from. We know we need and want HTTP, so to me that=E2=80=99s firmly in-scope. = Other protocols are =E2=80=9Cwouldn=E2=80=99t it be nice if it did = this=E2=80=9D right now, and abstracting for something that =E2=80=9Cwould= be nice=E2=80=9D leads to bad system design. I=E2=80=99m not against COAP, but like with OAuth and ACE, I don=E2=80=99t= think it=E2=80=99s good to try and cram them together this early.=20 > =20 >=20 > =E2=80=94 Justin >=20 > > On Dec 30, 2019, at 7:20 PM, Dick Hardt > wrote: > >=20 > > I would propose that the resulting work is a protocol, and not a = framework. > >=20 > > What is the difference? Here are my thoughts: > >=20 > > A framework defines a variety of ways to do each capability. A = framework usually needs a profile for two systems to interoperate. For = example, OIDC provides a number of ways to get identity data from an OP, = and OAuth 2 grant types have overlap. A framework is like Perl. Lots of = ways to do the same thing, many of which are unreadable. > >=20 > > A protocol provides one way to do each capability. A protocol is = like Python, there is a right way to do something. > >=20 > > At times a standards group will get "consensus" by not being = decisive, and including everyone's favored mechanism. In my opinion, = this makes deployments more complicated for average developers, and = increases the surface area to secure. > >=20 > > Do others agree with adding this as a tenet to the charter? > >=20 > > /Dick > >=20 > > Note: I'm a fan of both Perl and Python. =3D) > >=20 > > --=20 > > Txauth mailing list > > Txauth@ietf.org > > https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_789E7005-58FE-4028-8A21-FDD94ACA6920 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Answers inline.

On Dec 31, 2019, at 2:00 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

A = couple questions inserted to understand what you are suggesting = ... 

On Tue, Dec 31, 2019 at 5:06 AM Justin Richer = <jricher@mit.edu> = wrote:
I agree with this. I think that with = OAuth2 the extension mechanism of grant types was a decent idea, and = I=E2=80=99ve argued that it leads to significant amounts of code-reuse = from very different systems that function in very different ways.

But I also think that what I=E2=80=99d like to see here, and what I=E2=80=99= ve tried to do with XYZ, is to have one protocol that lets you branch = off for different use cases where necessary but still brings you back to = the same process in the end.

"... brings you back to the same = process in the end." -- implies something different than below where the = process may branch off and end up in a different place. Would you = clarify what you mean?

I didn=E2=80=99t mean to imply that you=E2=80=99d = end up somewhere else, but rather that you=E2=80=99d potentially take a = detour through some other mechanism and come back to the same thing that = you started. So I start by making an HTTP call, and then maybe I blip = out a number over my speaker, or I send a DIDComm message to an agent on = my device, or I redirect the user off in some browser thing =E2=80=94 = but then eventually I go back to making an HTTP call. The variability is = in the middle part, where the user interaction is involved. The = variability should not be in how the clients talk to other = systems.

 
This is one of the things I like = about having the AS defined as the transaction endpoint =E2=80=94 = everyone goes to one place and sends one kind of message to start things = off, and then you have everything you need to figure out where to go = from there, even if it=E2=80=99s off-HTTP and out-of-band.

A way to start the transaction in COAP would likely be = interesting to the constrained environment people. Would you not = agree?

I totally agree. And they=E2=80=99d also want to = continue and finish the transaction in COAP. And be able to do redirects = using COAP principles instead of HTTP principles. And generally do = things that are similar but not the same. So it turns into a different = protocol with the same ideas, and I=E2=80=99m all for that happening =E2=80= =94 but I don=E2=80=99t think it=E2=80=99s a good idea to put it all in = the same document, or to have an abstract document that everyone tries = to inherit from.

We know we need and = want HTTP, so to me that=E2=80=99s firmly in-scope. Other protocols are = =E2=80=9Cwouldn=E2=80=99t it be nice if it did this=E2=80=9D right now, = and abstracting for something that =E2=80=9Cwould be nice=E2=80=9D leads = to bad system design.

I=E2=80=99m = not against COAP, but like with OAuth and ACE, I don=E2=80=99t think = it=E2=80=99s good to try and cram them together this = early. 

 

 =E2=80=94 Justin

> On Dec 30, 2019, at 7:20 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>
> I would propose that the resulting work is a protocol, and not a = framework.
>
> What is the difference? Here are my thoughts:
>
> A framework defines a variety of ways to do each capability. A = framework usually needs a profile for two systems to interoperate. For = example, OIDC provides a number of ways to get identity data from an OP, = and OAuth 2 grant types have overlap. A framework is like Perl. Lots of = ways to do the same thing, many of which are unreadable.
>
> A protocol provides one way to do each capability.  A protocol = is like Python, there is a right way to do something.
>
> At times a standards group will get "consensus" by not being = decisive, and including everyone's favored mechanism. In my opinion, = this makes deployments more complicated for average developers, and = increases the surface area to secure.
>
> Do others agree with adding this as a tenet to the charter?
>
> /Dick
>
> Note: I'm a fan of both Perl and Python. =3D)
>
> --
> Txauth mailing list
> Txauth@ietf.org
> https://www.ietf.org/mailman/listinfo/txauth
=

= --Apple-Mail=_789E7005-58FE-4028-8A21-FDD94ACA6920-- From nobody Tue Dec 31 12:41:19 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6EC120046 for ; Tue, 31 Dec 2019 12:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 Tw9syljXbo9y for ; Tue, 31 Dec 2019 12:41:14 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 973E2120013 for ; Tue, 31 Dec 2019 12:41:13 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id h23so37183969ljc.8 for ; Tue, 31 Dec 2019 12:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TN02S5HlRQtObWDwLj5syi9+Jspg3MRg0saKpseF/7o=; b=nye50R03ygYP44mIt1Qy9qL0K2VTWVMPFfO4yWXrZfoiNywEcXePav7yqJjPDj4YED nY36z4Noi5wLRgLPoKezgCKG2LEdlGXySkJphM/We+oUKDDBLj8uAfXObBl/p9Fva+iD 2X9QxHaOmB7Vo8keDjsMF6F/AhrdEe3vHJuKicVgLBqydF7fQP9ldhwK6h6i8wLpPv1V PuUhCFTcUO1De4O9jyoGeUF910ioJxWyujTMdhuCwoSAS0IwmWrtjsBjhuhAcNnPdjLe tyucPdZfNZUmseo5CBkdFwXvCisvHFbuwSj4OGJaHP+1WI4XRg0UjDx4jrI5mZekA3K6 k+5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TN02S5HlRQtObWDwLj5syi9+Jspg3MRg0saKpseF/7o=; b=r6sQvcAQyFpvxXtwPHm7cRS7++NdHTcJPntse4SXgFHvVa59Ea69ZjVtMrb0tI/cw6 HPjMm7OLUsLyHt16CaOkNpyLrdvYj39eXyZRhuXSQtjxsMs8ZX4XyR0e1XrXwUt/+psL jTSVW8A8TlAwKXVniZ0HrHR18o/848JVA0762U7KmE/yTyGPn9KGkKaak5AYxNUW9JXE 3wBTIWJaY3ulM2RiHwTtaC3wEeeyGcOxNbnCIhVcf7n2io4WdFsgH2YU3w7TuP0pCVCk QJBeQLeFoqEBpIW+PSOIJ8ii29T2PQdGweAm4pTTrRZS1GKPVKcnb7rxsyHLPBJLPcUC tGyw== X-Gm-Message-State: APjAAAVs3Wu4foQFLnhx6P9Fya/WR1yOit055tT84QJaHhoISDhNbRIS jwN1l+It3+ILaJvmbS3x5Pi24WQq453IB/9bSoo= X-Google-Smtp-Source: APXvYqyh+Mxx6TE6mzegrXM2xyVjaeW/Mwa5mPbKPmkeaEQ9mIMF0r5e4PEqC34slsF48sIq5lAz9L4Qq0UqmGlmm+M= X-Received: by 2002:a05:651c:204f:: with SMTP id t15mr44514925ljo.240.1577824871639; Tue, 31 Dec 2019 12:41:11 -0800 (PST) MIME-Version: 1.0 References: <9E02E9F3-999F-41C9-AAF8-6DA7A2D565F2@xmlgrrl.com> <07AEE8DB-A0EE-4780-9CE7-B578F69948F9@mit.edu> <68CA5C79-10AB-42E6-B4A9-06A594CA436C@mit.edu> <3066B58F-47D5-48C6-B705-A9F3F58EB496@mit.edu> In-Reply-To: <3066B58F-47D5-48C6-B705-A9F3F58EB496@mit.edu> From: Dick Hardt Date: Tue, 31 Dec 2019 12:40:59 -0800 Message-ID: To: Justin Richer Cc: Eve Maler , "rdd@cert.org" , txauth@ietf.org, Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000fdf01f059b05fa70" Archived-At: Subject: Re: [Txauth] TxAuth Proposed Charter X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2019 20:41:17 -0000 --000000000000fdf01f059b05fa70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 31, 2019 at 11:01 AM Justin Richer wrote: > >> >>> >>> 2. Why do you restrict this to HTTP? >>> >>> >>> Because I want us to use all of the features and benefits of HTTP >>> instead of having to invent within-protocol functions to replicate them= . I >>> don=E2=80=99t want SOAP, which pretends to be transport agnostic much t= o its >>> detriment. If someone wants to do OAuth 3 on not-HTTP, they can define = what >>> that looks like. This is what happened with the COAP/CORE stuff and OAu= th 2. >>> >> >> I agree SOAP was complicated. Which features and benefits of HTTP are yo= u >> wanting to use? >> >> >> Well so far we=E2=80=99ve got headers, URLs, methods, data payload types= , and the >> whole array of technologies that we can rely on working together along w= ith >> HTTP. >> > > But which ones do you want to use? > > > > Those things that I already listed are what I want to use. I want to use > the headers for sending key proofs and probably content negotiation. I wa= nt > to have content negotiation so that we can have an option to use JOSE (or > COSE) as the body format instead of JSON, but that function switch should > come from the transport protocol (HTTP) and not something internal to our > protocol. I want to be able to use redirects to get the user to interact, > and get back from the interaction. I want to (eventually) do things like > token revocation using a DELETE verb instead of a separate endpoint. I wa= nt > to use HTTP Message Signatures (once they exist) as a key presentation > mechanism. And I want our security considerations to be able to take into > account the particulars of HTTP, TLS, and the like when we write them. > Thanks for clarifying. I agree that using the http content-type header, and http verbs is preferable to inventing new mechanisms. > > >> >> If it was simple to support COAP, why would we not do that? >> >> >> Because it=E2=80=99s not just COAP =E2=80=94 you=E2=80=99ve got a differ= ent set of assumptions >> for the lower layer protocols, and you=E2=80=99ve got lots of considerat= ions about >> how the different components can talk to each other in the embedded spac= e. >> > > You are suggesting we rule out it working with COAP in the charter, befor= e > we have even had a chance to work on it. > > Perhaps it will be trivial to support COAP. We won't know if the charter > forbids it. > > > If it turns out to be trivial and people want to include it and do the > work here, then we could always update the charter to include it. I would > rather see that than us trying to enumerate all of the target carrier > mechanisms. Because if we do COAP, why not MQTT? Or BluetoothLE? > > If we include COAP, then to my mind that necessitates one of two things, > if not both: > > 1) We have a document that says =E2=80=9CIF you=E2=80=99re doing HTTP do = (A) if you=E2=80=99re > doing COAP do (B)=E2=80=9D > 2) We have an =E2=80=9Cabstract=E2=80=9D document that says =E2=80=9Chere= =E2=80=99s this thing but for > details on how to do it go read the HTTP document and/or the COAP > document=E2=80=9D, but when you read the HTTP or COAP documents, they don= =E2=80=99t have > any information about what the thing is because it=E2=80=99s in the abstr= act. > > From a developer=E2=80=99s perspective, I would rather have an HTTP docum= ent be > self-contained, and a COAP document be self-contained. And if the two > describe the same process, or one inherits from the other but says =E2=80= =9Cinstead > of doing HTTP thing X do COAP equivalent Y=E2=80=9D, then that=E2=80=99s = good. > I agree completely. > > But overly abstracting a system is both tempting and potentially > disastrous. > I agree. I align with the design tenet: "Easy things should be easy, hard things should be possible" -- Larry Wall If the WG has a choice between A and B, and they all other things are equal for an HTTP implementation, but B is much better for COAP, then I would suggest we choose B. I'm not saying COAP support should be a priority, I'm saying we should not completely ignore it. > > > >> >> In my experience, it=E2=80=99s much more successful to have a protocol s= trongly >> integrated with its transport mechanism and then translated out to other >> mechanisms, instead of trying to come up with one universal interlingua = of >> a protocol that just get shunted along. >> > > Would you provide an example besides SOAP for this? > > > It=E2=80=99s the most egregious example that comes to mind for me, so tha= t=E2=80=99s why I > keep coming back to it. I also have in mind a dozen projects that never > went anywhere, and nobody=E2=80=99s heard of, because of an outmoded effo= rt being > put into defining abstractions ahead of time in order to allow > transport-agnostic messaging. > > A similar level of overly-eager abstraction went into JOSE, with the JWA > document. It makes it so that JWS, JWE, and JWK make no sense without JWA= , > and JWA is just a collection of content that really should have been > included inline with the other documents. > > I want to avoid that kind of thing. > Agreed > > > >> This is why SOAP can=E2=80=99t use HTTP verbs to communicate things, and= why the >> only signatures it can use are internal. When you do that kind of system= , >> you almost always end up having people just use it with one transport >> anyway, like SOAP over HTTP. >> >> >> >>> >>> >>> 3. Why is authentication not in scope? >>> >>> >>> It felt, to me, like that might be a bridge too far. >>> >> >> I disagree. But I also think that authentication is the wrong term. >> Identity* may be a term that maps better, as the Client is wanting to ge= t >> "identity" data from the AS. >> >> * The identity term is super confusing, but authentication implies just >> knowing it is the same user, where OpenID Connect also provides claims >> about the user. >> >> >> I=E2=80=99m coming around to this view, but I would still like it to be = separate. >> > > What does separate mean? > > > It means that the bits that say =E2=80=9Cthis is how you talk about ident= ity > information in the response=E2=80=9D are controlled by a separate spec th= at not > everyone needs to understand. I think there are too many use cases of > wanting to get API access and NOT user information for it to be a core > piece. > Some developers only care about identity. Some only care about API access. It should be easy for both. > > However, this is arguably getting into the details of how to slice up > different documents, which is really a decision to be made once the WG is > running and not during the charter. > Currently, identity is not in scope of the charter, which is why I am bringing it up. > > > >> >> >> >>> If we do decide it=E2=80=99s in scope, then I think it should be clearl= y layered >>> on top of the authorization layer. >>> >> >> Being layered on top is confusing. An OpenID Connect flow where the >> Client receives an ID token, has not authorization, unless you are count= ing >> the UX as authorization -- but that does not seem like a layer. Would yo= u >> elaborate? >> >> >> >> What you=E2=80=99re doing in OIDC is authorizing the application to know= who you >> are =E2=80=94 to get your identity information. That key insight is what= makes the >> combination of OAuth and OIDC work as well as it does. And, importantly, >> once you authorize identity access, you can authorize other stuff as wel= l. >> > > > As I stated, there is the UX of authorizing knowing who the user is, but > there is no artifact representing that authorization as there is in OAuth > -- ie there is no access token to access a resource. (yes, an access toke= n > may be used to read the user info endpoint, but that is all it can do. > > >> And it=E2=80=99s the =E2=80=9Cand other stuff=E2=80=9D that people reall= y, really, really like >> about OIDC. Nobody ever wants just authorization, in practice. >> > > Did you mean to say "authentication"? > > If so, then I would posit that there are more OIDC user interactions than > plain OAuth 2.0 user interactions, and that almost all of those OIDC user > interactions are just logging in with Google or Facebook -- and that ther= e > is no "and other stuff". > > > Yes, I meant authentication, thank you. > > I=E2=80=99m not sure it=E2=80=99s true, but I=E2=80=99ll agree that it=E2= =80=99s more public-facing. But > even if what you posit is actually true by raw numbers, it=E2=80=99s not = universal. > In particular, there are a large number of system-to-system cases that > OAuth 2 covers, which have nothing to do with identity, that we don=E2=80= =99t want > to throw out. > I'm not suggesting that those use cases should be thrown out, nor second class. > > > > > >> >> >>> >>> 4. When you say "not backwards compatible with OAuth 2.0 and its >>> extensions", do you expect to define a new standard to replace RFC 6750= ? >>> Developers will have to have a new method to call APIs? >>> >>> >>> Kinda. First, it=E2=80=99s more 6749 that I want to step away from. But= even >>> then, I think keeping just the header version of 6750 is OK enough if >>> someone wants to keep using that. The thing is, won=E2=80=99t someone s= eeing an >>> OAuth 2 header assume the rest of OAuth 2 infrastructure? In some cases >>> this won=E2=80=99t matter, but in many that could be really confusing. >>> >>> One of the problems, though, is that 6750 has already been clouded by >>> things like the MTLS binding, where they use =E2=80=9Cbearer=E2=80=9D t= okens that have to >>> be bound to the client=E2=80=99s certificate. So =E2=80=A6 not much of = a bearer token >>> anymore. >>> >> >> So, are you are you proposing that Tx have a new mechanism for API calls= ? >> >> >> Yes, I think there will be new mechanisms for different kinds of >> key-bound tokens. >> > > So are you proposing that OAuth 3.0 will not support bearer tokens? > > > That is not correct and I=E2=80=99m not sure where you got that. Bearer t= okens are > still useful. But they should look and behave as distinct from > sender-constrained tokens. But ultimately we can tell the client how the > token gets used, as below. > It was not clear from your response, as a new mechanism could mean that the old one is not used anymore. To clarify, you expect there will be additional mechanisms. /Dick --000000000000fdf01f059b05fa70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Dec 31, 2019 at 11:01 AM Just= in Richer <jricher@mit.edu> wr= ote:

=


2. Why do you restrict this to HTTP?

Because I want us to use all of t= he features and benefits of HTTP instead of having to invent within-protoco= l functions to replicate them. I don=E2=80=99t want SOAP, which pretends to= be transport agnostic much to its detriment. If someone wants to do OAuth = 3 on not-HTTP, they can define what that looks like. This is what happened = with the COAP/CORE stuff and OAuth 2.
I agree SOAP was complicated. Which features and benefits of H= TTP are you wanting to use?=C2=A0


Well so far we=E2=80=99ve got headers, URLs, = methods, data payload types, and the whole array of technologies that we ca= n rely on working together along with HTTP.
<= div>
But which ones do you want to use?
=C2=A0

Those things that I already l= isted are what I want to use. I want to use the headers for sending key pro= ofs and probably content negotiation. I want to have content negotiation so= that we can have an option to use JOSE (or COSE) as the body format instea= d of JSON, but that function switch should come from the transport protocol= (HTTP) and not something internal to our protocol. I want to be able to us= e redirects to get the user to interact, and get back from the interaction.= I want to (eventually) do things like token revocation using a DELETE verb= instead of a separate endpoint. I want to use HTTP Message Signatures (onc= e they exist) as a key presentation mechanism. And I want our security cons= iderations to be able to take into account the particulars of HTTP, TLS, an= d the like when we write them.

Thanks for clarifying. I agree that using the http content-type heade= r, and http verbs is preferable to inventing new mechanisms.
=C2= =A0



=
If it was simple to suppor= t COAP, why would we not do that?
=
Because it=E2=80=99s not just COAP =E2=80=94 you=E2=80=99ve = got a different set of assumptions for the lower layer protocols, and you= =E2=80=99ve got lots of considerations about how the different components c= an talk to each other in the embedded space.=C2=A0

You are suggesting we rule out it working with CO= AP in the charter, before we have even had a chance to work on it.

Perhaps it will be trivial to support COAP. We won't k= now if the charter forbids it.

If it turns out to be trivial and people want to include it and do th= e work here, then we could always update the charter to include it. I would= rather see that than us trying to enumerate all of the target carrier mech= anisms. Because if we do COAP, why not MQTT? Or BluetoothLE?=C2=A0

If we include COAP, then to my mind that necessitates one = of two things, if not both:

1) We have a document = that says =E2=80=9CIF you=E2=80=99re doing HTTP do (A) if you=E2=80=99re do= ing COAP do (B)=E2=80=9D
2) We have an =E2=80=9Cabstract=E2=80=9D= document that says =E2=80=9Chere=E2=80=99s this thing but for details on h= ow to do it go read the HTTP document and/or the COAP document=E2=80=9D, bu= t when you read the HTTP or COAP documents, they don=E2=80=99t have any inf= ormation about what the thing is because it=E2=80=99s in the abstract.=C2= =A0

From a developer=E2=80=99s perspective, I woul= d rather have an HTTP document be self-contained, and a COAP document be se= lf-contained. And if the two describe the same process, or one inherits fro= m the other but says =E2=80=9Cinstead of doing HTTP thing X do COAP equival= ent Y=E2=80=9D, then that=E2=80=99s good.=C2=A0

I agree completely.
=C2=A0

But overly abstracting a system is both tem= pting and potentially disastrous.=C2=A0
=
I agree.=C2=A0

I align with the des= ign tenet:

"Easy things should be easy, hard = things should be possible" -- Larry Wall

If t= he WG has a choice between A and B, and they all other things are equal for= an HTTP implementation, but B is much better for COAP, then I would sugges= t we choose B.

I'm not saying COAP support sho= uld be a priority, I'm saying we should not completely ignore it.=C2=A0=
=C2=A0

=
=C2=A0

In my= experience, it=E2=80=99s much more successful to have a protocol strongly = integrated with its transport mechanism and then translated out to other me= chanisms, instead of trying to come up with one universal interlingua of a = protocol that just get shunted along.
Would you provide an example besides SOAP for this?

It=E2=80=99s the most egregious exa= mple that comes to mind for me, so that=E2=80=99s why I keep coming back to= it. I also have in mind a dozen projects that never went anywhere, and nob= ody=E2=80=99s heard of, because of an outmoded effort being put into defini= ng abstractions ahead of time in order to allow transport-agnostic messagin= g.=C2=A0

A similar level of overly-eager abstracti= on went into JOSE, with the JWA document. It makes it so that JWS, JWE, and= JWK make no sense without JWA, and JWA is just a collection of content tha= t really should have been included inline with the other documents.=C2=A0

I want to avoid that kind of thing.

Agreed
=C2=A0

=C2=A0
This is why SOAP can=E2=80=99t use HTTP verbs to commu= nicate things, and why the only signatures it can use are internal. When yo= u do that kind of system, you almost always end up having people just use i= t with one transport anyway, like SOAP over HTTP.

=C2=A0


= 3. Why is authentication not in scope?
=

It felt, to me, like that might be a bridge too far.

I disagree. But I also thin= k that authentication is the wrong term. Identity* may be a term that maps = better, as the Client is wanting to get "identity" data from the = AS.=C2=A0

* The identity term is super confusing, = but authentication implies just knowing it is the same user, where OpenID C= onnect also provides claims about the user.

I=E2=80=99m coming around to this view, but I woul= d still like it to be separate.

What does separate mean?

It means that the bits that say =E2=80=9Cthis is how you talk about = identity information in the response=E2=80=9D are controlled by a separate = spec that not everyone needs to understand. I think there are too many use = cases of wanting to get API access and NOT user information for it to be a = core piece.=C2=A0

Some de= velopers only care about identity. Some only care about API access. It shou= ld be easy for both.
=C2=A0

<= /div>
However, this is arguably getting into the details of how to slic= e up different documents, which is really a decision to be made once the WG= is running and not during the charter.=C2=A0

Currently, identity is not in scope of the charter, wh= ich is why I am bringing it up.
=C2=A0

=C2=A0

=C2=A0
And it=E2=80=99s the = =E2=80=9Cand other stuff=E2=80=9D that people really, really, really like a= bout OIDC. Nobody ever wants just authorization, in practice.=C2=A0

Did you mean to say "authen= tication"?

If so, then I would posit that the= re are more OIDC user interactions than plain OAuth 2.0 user interactions, = and that almost all of those OIDC user interactions are just logging in wit= h Google or Facebook -- and that there is no "and other stuff".


Yes, I mean= t authentication, thank you.=C2=A0

I=E2=80=99m not= sure it=E2=80=99s true, but I=E2=80=99ll agree that it=E2=80=99s more publ= ic-facing. But even if what you posit is actually true by raw numbers, it= =E2=80=99s not universal. In particular, there are a large number of system= -to-system cases that OAuth 2 covers, which have nothing to do with identit= y, that we don=E2=80=99t want to throw out.
<= div>
I'm not suggesting that those use cases should be th= rown out, nor second class.
=C2=A0
=

=C2=A0
=C2=A0


=

4. When you say "not backwards co= mpatible with OAuth 2.0 and its extensions", do you expect to define a= new standard to replace RFC 6750? Developers will have to have a new metho= d to call APIs?

Kin= da. First, it=E2=80=99s more 6749 that I want to step away from. But even t= hen, I think keeping just the header version of 6750 is OK enough if someon= e wants to keep using that. The thing is, won=E2=80=99t someone seeing an O= Auth 2 header assume the rest of OAuth 2 infrastructure? In some cases this= won=E2=80=99t matter, but in many that could be really confusing.=C2=A0

One of the problems, though, is that 6750 has alread= y been clouded by things like the MTLS binding, where they use =E2=80=9Cbea= rer=E2=80=9D tokens that have to be bound to the client=E2=80=99s certifica= te. So =E2=80=A6 not much of a bearer token anymore.

So, are you are you proposing that Tx have a ne= w mechanism for API calls?

Yes, I think there will be new mechanisms for different kinds of ke= y-bound tokens.

So are yo= u proposing that OAuth 3.0 will not support bearer tokens?

That is not correct and I=E2=80=99m not s= ure where you got that. Bearer tokens are still useful. But they should loo= k and behave as distinct from sender-constrained tokens. But ultimately we = can tell the client how the token gets used, as below.

It was not clear from your response, as a new= mechanism could mean that the old one is not used anymore.

<= /div>
To clarify, you expect there will be additional mechanisms.
=
=C2=A0
/Dick
--000000000000fdf01f059b05fa70-- From nobody Tue Dec 31 16:04:32 2019 Return-Path: X-Original-To: txauth@ietfa.amsl.com Delivered-To: txauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5930712004E for ; Tue, 31 Dec 2019 16:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.228 X-Spam-Level: ** X-Spam-Status: No, score=2.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 xaKca6-e_P_V for ; Tue, 31 Dec 2019 16:04:30 -0800 (PST) Received: from alkaline-solutions.com (unknown [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id E1DC9120019 for ; Tue, 31 Dec 2019 16:04:29 -0800 (PST) Received: from [IPv6:2601:282:202:b210:61fd:b5b8:8be9:af5c] (unknown [IPv6:2601:282:202:b210:61fd:b5b8:8be9:af5c]) by alkaline-solutions.com (Postfix) with ESMTPSA id 8C33D3155D; Wed, 1 Jan 2020 00:06:02 +0000 (UTC) From: David Waite Message-Id: <063D9E65-9F39-41CA-A2A7-C15CCF89E2DC@alkaline-solutions.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_25BA95A6-CE94-4983-B2C9-25C95D31073F" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.1\)) Date: Tue, 31 Dec 2019 17:04:25 -0700 In-Reply-To: Cc: Dick Hardt , txauth@ietf.org To: Justin Richer References: X-Mailer: Apple Mail (2.3608.60.0.2.1) Archived-At: Subject: Re: [Txauth] Framework vs Protocol X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2020 00:04:31 -0000 --Apple-Mail=_25BA95A6-CE94-4983-B2C9-25C95D31073F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 31, 2019, at 12:12 PM, Justin Richer wrote: >> This is one of the things I like about having the AS defined as the = transaction endpoint =E2=80=94 everyone goes to one place and sends one = kind of message to start things off, and then you have everything you = need to figure out where to go from there, even if it=E2=80=99s off-HTTP = and out-of-band.=20 >>=20 >> A way to start the transaction in COAP would likely be interesting to = the constrained environment people. Would you not agree? >=20 > I totally agree. And they=E2=80=99d also want to continue and finish = the transaction in COAP. And be able to do redirects using COAP = principles instead of HTTP principles. And generally do things that are = similar but not the same. So it turns into a different protocol with the = same ideas, and I=E2=80=99m all for that happening =E2=80=94 but I = don=E2=80=99t think it=E2=80=99s a good idea to put it all in the same = document, or to have an abstract document that everyone tries to inherit = from. I assume still that the =E2=80=9Ctransactional=E2=80=9D nature of the = protocol is that the coordinator/transaction endpoint/AS and potentially = other components/endpoints are facilitating communication across = software serving the different roles. In that case, an accessing agent/client may be constrained to COAP, but = the authorizing agent/interactor/external user agent could be regular = HTTP. Or triggered via device or CIBA-style flows. It could also be a = locally triggered user agent which is constrained to using COAP for = communication and rendering CBOR-specified instructions for interaction. Tokens might also be acquired via HTTP, but for business reasons some = API are only accessible via COAP. The ability for a client to interact with the coordinator/transaction = endpoint/AS via COAP would be independent from the client ability to = apply acquired tokens to COAP requests, and both of those are = independent from any definition of a protocol defining user interaction = via COAP/CBOR. I=E2=80=99d expect such a definition for user = interactions for constrained clients to be out of scope, outside being = allowed and an allowance for supporting multiple options for = interactions. > We know we need and want HTTP, so to me that=E2=80=99s firmly = in-scope. Other protocols are =E2=80=9Cwouldn=E2=80=99t it be nice if it = did this=E2=80=9D right now, and abstracting for something that =E2=80=9Cw= ould be nice=E2=80=9D leads to bad system design. >=20 > I=E2=80=99m not against COAP, but like with OAuth and ACE, I don=E2=80=99= t think it=E2=80=99s good to try and cram them together this early.=20 I would love the two to be kept aligned, but I neither want the = requirement or impression that a conformant TXAuth implementation needs = to implement COAP or to include CBOR.= --Apple-Mail=_25BA95A6-CE94-4983-B2C9-25C95D31073F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 31, 2019, at 12:12 PM, Justin Richer <jricher@mit.edu> = wrote:
This is one = of the things I like about having the AS defined as the transaction = endpoint =E2=80=94 everyone goes to one place and sends one kind of = message to start things off, and then you have everything you need to = figure out where to go from there, even if it=E2=80=99s off-HTTP and = out-of-band. 

A way to start the transaction in COAP would likely be = interesting to the constrained environment people. Would you not = agree?

I totally agree. And they=E2=80=99d = also want to continue and finish the transaction in COAP. And be able to = do redirects using COAP principles instead of HTTP principles. And = generally do things that are similar but not the same. So it turns into = a different protocol with the same ideas, and I=E2=80=99m all for that = happening =E2=80=94 but I don=E2=80=99t think it=E2=80=99s a good idea = to put it all in the same document, or to have an abstract document that = everyone tries to inherit from.

I assume still that the =E2=80=9Ctransactional=E2=80=9D = nature of the protocol is that the coordinator/transaction endpoint/AS = and potentially other components/endpoints are facilitating = communication across software serving the different roles.

In that case, an accessing agent/client may be = constrained to COAP, but the authorizing agent/interactor/external user = agent could be regular HTTP. Or triggered via device or CIBA-style = flows. It could also be a locally triggered user agent which is = constrained to using COAP for communication and rendering CBOR-specified = instructions for interaction.

Tokens = might also be acquired via HTTP, but for business reasons some API are = only accessible via COAP.

The = ability for a client to interact with the coordinator/transaction = endpoint/AS via COAP would be independent from the client ability to = apply acquired tokens to COAP requests, and both of those are = independent from any definition of a protocol defining user interaction = via COAP/CBOR. I=E2=80=99d expect such a definition for user = interactions for constrained clients to be out of scope, outside being = allowed and an allowance for supporting multiple options for = interactions.

We know we need and = want HTTP, so to me that=E2=80=99s firmly in-scope. Other protocols are = =E2=80=9Cwouldn=E2=80=99t it be nice if it did this=E2=80=9D right now, = and abstracting for something that =E2=80=9Cwould be nice=E2=80=9D leads = to bad system design.

I=E2=80=99m not against COAP, but like with OAuth and ACE, I = don=E2=80=99t think it=E2=80=99s good to try and cram them together this = early. 

I would = love the two to be kept aligned, but I neither want the requirement or = impression that a conformant TXAuth implementation needs to implement = COAP or to include CBOR.
= --Apple-Mail=_25BA95A6-CE94-4983-B2C9-25C95D31073F--