From nobody Tue Jun 2 06:18:03 2020 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 8E70C3A08FF for ; Tue, 2 Jun 2020 06:18:02 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 uy1YWV1rqd6r for ; Tue, 2 Jun 2020 06:17:59 -0700 (PDT) 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 8F2AB3A08FB for ; Tue, 2 Jun 2020 06:17:59 -0700 (PDT) Received: from [192.168.1.12] (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 052DHu4P031137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 2 Jun 2020 09:17:57 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_92C560C9-0304-4342-9F53-19F0B782A863" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 2 Jun 2020 09:17:56 -0400 References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> To: "txauth@ietf.org" In-Reply-To: Message-Id: <73BEEDEF-70D5-4B7A-BE9D-E01A5831D9EF@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 02 Jun 2020 13:18:03 -0000 --Apple-Mail=_92C560C9-0304-4342-9F53-19F0B782A863 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, I just wanted to remind the community that feedback on the = potential names is needed by the chairs by this Thursday, June 4th. = Please post your comments to the list before then! Remember, they=E2=80=99re looking for feedback in the form of = =E2=80=9Cwouldn=E2=80=99t object=E2=80=9D and =E2=80=9Cwould object=E2=80=9D= , and all objections should have specific reasons. =E2=80=94 Justin > On May 28, 2020, at 5:47 PM, Justin Richer wrote: >=20 > Thanks to everyone in the community for suggesting names, and thanks = to the chairs for putting this list together. >=20 > Here=E2=80=99s my personal take on the candidates. >=20 >=20 >=20 > Wouldn=E2=80=99t Object: >=20 > * TxAuth Transmission of Authority > This is my personal favorite of the lot because it avoids the = =E2=80=9Cauthorization/authentication=E2=80=9D question and gets at the = heart of what this protocol does: delegation, which is to say, = transmitting the authority to do something from one party to another. = That delegation allows for authorized access to resources, but can also = allow different rights to flow as needed. Additionally, =E2=80=9Ctx=E2=80=9D= has long been used to stand for =E2=80=9Ctransmission=E2=80=9D in = computer science and networking. >=20 > * AZARP AuthoriZed Access to Resources Protocol > The use of =E2=80=9CAZ=E2=80=9D to stand for =E2=80=9Cauthorized=E2= =80=9D is awkward, but the pronunciation kinda works as something = memorable. The expansion is a twist of words to make it fit, and I like = that less. > Resource access is only part of the story, but it=E2=80=99s an = important part. This leaves out what we want to do around = non-authorization cases (like identity conveyance). >=20 > * AZARAP AuthoriZation And Resource Access Protocol > I like the expansion here more than the one for AZARP but I like = the acronym less with the additional =E2=80=9CA=E2=80=9D. > Same comment as above for AZ standing for Authorization. > Same comment as above for resource access. >=20 > * DAZARAP Delegated AuthoriZation And Resource Access Protocol > I like the expansion here, but the acronym is awkward and weak.=20= > Same comment as above for AZ standing for Authorized. > Same comment as above for resource access. >=20 > * GNAP Grant Negotiation and Authorization Protocol > This is ok, but it has a couple downsides. The pronunciation of = a hard =E2=80=9Cg=E2=80=9D or not is going to potentially be confusing, = as is the fact that it looks like it=E2=80=99s part of the GNU project = because of that. > The term =E2=80=9CGrant=E2=80=9D is one of the more confusing = things that was introduced in OAuth 2, and while it=E2=80=99s = established in the lexicon today, I=E2=80=99ve yet to meet many = engineering teams that actually know what a =E2=80=9Cgrant=E2=80=9D is. = Most think it=E2=80=99s another name for the authorization code. > Also it means =E2=80=9Cto bite=E2=80=9D, which may or may not be = desirable. >=20 > * NIRAD Negotiation of Intent Registration and Authority Delegation > This is a somewhat weak construct, but it mostly works. It = spells out more what the protocol will do (if we go with the currently = proposed solution designs) than what it solves, but that might be ok. > It makes me think of NORAD (a positive, they do weather radar = and track Santa Claus each year), but also =E2=80=9Cnimrod=E2=80=9D, a = pejorative term. And before anyone chimes in with =E2=80=9CBut Nimrod = was a mighty hunter of ancient times=E2=80=9D, it doesn=E2=80=99t mean = that to any modern listener. >=20 > * GATAR Grant Authorization To Access Resources=20 > This one isn=E2=80=99t bad, and I can appreciate the = =E2=80=9Cguitar=E2=80=9D pronunciation and imagery. As above, resource = access isonly part of the story. > Same comment about =E2=80=9CGrant=E2=80=9D as above in GNAP. >=20 >=20 >=20 > Object: >=20 > * AAuthZ Alternative Authorization Protocol (AAuthZ) > It=E2=80=99s an alternative to what, exactly? And what happens = when someone makes an alternative to it? > The focus on =E2=80=9CAuthorization=E2=80=9D as a core part of = the name tells only part of the story.=20 > Assuming the =E2=80=9CZ=E2=80=9D is pronounced as its letter = name (which is implied by the capitalization), there=E2=80=99s an issue = with pronouncing the final =E2=80=9CZ=E2=80=9D as either =E2=80=9CZee=E2=80= =9D or =E2=80=9CZed=E2=80=9D depending on dialect. If it=E2=80=99s not = pronounced as a letter, it=E2=80=99s really difficult to say the = consonants =E2=80=9Cthz" together in a way that can be heard and = understood. >=20 > * BeBAuthZ Back-end Based Authorization Protocol > The definition of =E2=80=9Cback end=E2=80=9D is going to change = depending on your perspective in the stack, but even if it were = consistent, the flexibility around user interaction is a huge motivator = for many getting involved in this work. > This is close to =E2=80=9CBBAuth=E2=80=9D, which was a = commercial predecessor to OAuth 1, so much that it=E2=80=99s nearly = impossible to disambiguate when talking. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * BYOAuthZ Build-Your-Own Authorization Protocol > This is the opposite of what we=E2=80=99re doing here. We = don=E2=80=99t want a bunch of disparate pieces that people can use to = build a protocol, we want a protocol with the right kind of flexibility = to fit different use cases. This name tells developers that they = aren=E2=80=99t getting a solution and incompatibility is likely. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * CPAAP Comprehensive Privileged Authentication Authorization = Protocol > This makes me think of CPAP, a breathing assistance device. Not = something I=E2=80=99m keen to call to mind in the middle of a global = pandemic of a respiratory disease. > The expansion doesn=E2=80=99t really tell me anything. > What does =E2=80=9Cprivileged=E2=80=9D mean here, and does it = apply to the authentication (which seems implied)? >=20 > * DIYAuthZ Do-It-Yourself Authorization Protocol > As above in BYOAuthZ, this is the opposite of what we=E2=80=99re = trying to do by creating a standard.=20 > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * GranPro GRAnt Negotiation Protocol > The acronym is a really awkward construction.=20 > As above, =E2=80=9Cgrant=E2=80=9D is an often misunderstood term = from OAuth 2. Plus, the =E2=80=9Cgrant=E2=80=9D isn=E2=80=99t really = what=E2=80=99s being negotiated here. >=20 > * IDPAuthZ Intent Driven Protocol for Authorization > =E2=80=9CIDP=E2=80=9D is already well understood in this space = to mean =E2=80=9Cidentity provider=E2=80=9D, so we should not try to = overload it. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * PAuthZ Protocol for Authorization > It was suggested this would be pronounced =E2=80=9Cpaws=E2=80=9D = but I can=E2=80=99t think of a single reason someone looking at the word = would try to pronounce it that way.=20 > It=E2=80=99s also completely generic and doesn=E2=80=99t say = anything about the work. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * RefAuthZ Refactored Authorization Protocol > Refactored from what? What if someone refactors this? What are = the factors? > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * ReAuthZ Reimagined Authorization Protocol > The short form is already a short term for = =E2=80=9Cre-authorization=E2=80=9D, which is not what we are doing. > Reimagined from what, and by whom? > The expansion sounds like it=E2=80=99s imaginary and not real. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * TIAAP Tokenized Identity and Access Protocol > I don=E2=80=99t think =E2=80=9Ctokenized=E2=80=9D is used in a = meaningful way here. It produced =E2=80=9Ctokens=E2=80=9D, but = tokenization is the splitting up of an input into pieces, which is not = what=E2=80=99s happening here. >=20 > * TIDEAuth Trust via Intent Driven Extension Auth > The expansion is really awkward. > It sounds like it=E2=80=99s an extension to an existing protocol = (something that we are explicitly NOT doing per the charter). > =09 > * TIDYAuth Trust via Intent Driven Yield Auth > I actually really like the acronym but the expansion is super = awkward. What is being yielded here? >=20 > * TIEAuth Trust via Intent Extension Auth > What is =E2=80=9Cintent extension=E2=80=9D?=20 > As above, it sounds like an extension not a protocol. >=20 > * TINOA This Is Not OAuth > This says nothing about what this work is, only what it isn=E2=80=99= t. And on that regard, it doesn=E2=80=99t matter that this isn=E2=80=99t = OAuth. OAuth 2 isn=E2=80=99t OAuth 1, either.=20 > And given that ease of transition from OAuth 2 is part of the = charter, this isn=E2=80=99t a helpful distinction. >=20 > * TXAuth Testable eXtensible Authorization > I don=E2=80=99t get the focus on =E2=80=9Ctestable=E2=80=9D in = the name. Testable in what way? Can other protocols not be tested? > Extensibility is not a differentiating feature of this work. >=20 > * TXAuth Truly eXtensible Authorization > Extensibility is not a differentiating feature of this work. > What makes something =E2=80=9Ctruly extensible=E2=80=9D as = opposed to =E2=80=9Cnot truly extensible=E2=80=9D? >=20 > * XAuthZ eXtensible authoriZation protocol > Extensibility is not a differentiating feature of this work. > The acronym is just pulling random letters from the middle of = words in the expansion to try to work. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * WRAC Web Resource Access Collaboration > This is not a collaboration protocol or system. Collaboration, = within computer science, is established to refer to when two or more = :people: work and communicate together. This protocol does not = facilitate human communication, and so the use of this term is not = appropriate here.=20 > This is very close to =E2=80=9Cwrack=E2=80=9D which is a common = enough English verb, as in =E2=80=9Cwracked nerves=E2=80=9D or =E2=80=9Cto= wrack one=E2=80=99s brain=E2=80=9D, which derives from the medieval = torture process of stretching someone over a rack. This=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_92C560C9-0304-4342-9F53-19F0B782A863 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = everyone, I just wanted to remind the community that feedback on the = potential names is needed by the chairs by this Thursday, June 4th. = Please post your comments to the list before then!

Remember, they=E2=80=99re looking for = feedback in the form of =E2=80=9Cwouldn=E2=80=99t object=E2=80=9D and = =E2=80=9Cwould object=E2=80=9D, and all objections should have specific = reasons.

 =E2=80=94 Justin

On May = 28, 2020, at 5:47 PM, Justin Richer <jricher@mit.edu> wrote:

Thanks = to everyone in the community for suggesting names, and thanks to the = chairs for putting this list together.

Here=E2=80=99s my personal take on the = candidates.



Wouldn=E2=80=99t Object:

* TxAuth      Transmission of = Authority
This is my personal favorite of = the lot because it avoids the =E2=80=9Cauthorization/authentication=E2=80=9D= question and gets at the heart of what this protocol does: delegation, = which is to say, transmitting the authority to do something from one = party to another. That delegation allows for authorized access to = resources, but can also allow different rights to flow as needed. = Additionally, =E2=80=9Ctx=E2=80=9D has long been used to stand for = =E2=80=9Ctransmission=E2=80=9D in computer science and = networking.

* AZARP =    AuthoriZed Access to Resources Protocol
The use of =E2=80=9CAZ=E2=80=9D = to stand for =E2=80=9Cauthorized=E2=80=9D is awkward, but the = pronunciation kinda works as something memorable. The expansion is a = twist of words to make it fit, and I like that less.
= Resource access is only part of the story, but it=E2=80=99s an = important part. This leaves out what we want to do around = non-authorization cases (like identity conveyance).

* AZARAP    AuthoriZation And = Resource Access Protocol
I like = the expansion here more than the one for AZARP but I like the acronym = less with the additional =E2=80=9CA=E2=80=9D.
Same = comment as above for AZ standing for Authorization.
= Same comment as above for resource access.
* DAZARAP    Delegated = AuthoriZation And Resource Access Protocol
= I like the expansion here, but the acronym is awkward and = weak. 
Same comment as above for AZ = standing for Authorized.
Same = comment as above for resource access.

* GNAP    Grant Negotiation = and Authorization Protocol
This is = ok, but it has a couple downsides. The pronunciation of a hard =E2=80=9Cg=E2= =80=9D or not is going to potentially be confusing, as is the fact that = it looks like it=E2=80=99s part of the GNU project because of = that.
The term =E2=80=9CGrant=E2=80=9D = is one of the more confusing things that was introduced in OAuth 2, and = while it=E2=80=99s established in the lexicon today, I=E2=80=99ve yet to = meet many engineering teams that actually know what a =E2=80=9Cgrant=E2=80= =9D is. Most think it=E2=80=99s another name for the authorization = code.
Also it means =E2=80=9Cto = bite=E2=80=9D, which may or may not be desirable.
* NIRAD    Negotiation of = Intent Registration and Authority Delegation
= This is a somewhat weak construct, but it mostly works. It spells = out more what the protocol will do (if we go with the currently proposed = solution designs) than what it solves, but that might be ok.
= It makes me think of NORAD (a positive, they do weather radar and = track Santa Claus each year), but also =E2=80=9Cnimrod=E2=80=9D, a = pejorative term. And before anyone chimes in with =E2=80=9CBut Nimrod = was a mighty hunter of ancient times=E2=80=9D, it doesn=E2=80=99t mean = that to any modern listener.

* GATAR      Grant = Authorization To Access Resources 
This one = isn=E2=80=99t bad, and I can appreciate the =E2=80=9Cguitar=E2=80=9D = pronunciation and imagery. As above, resource access isonly part of the = story.
Same comment about =E2=80=9CGrant=E2= =80=9D as above in GNAP.



Object:

* AAuthZ    Alternative Authorization = Protocol (AAuthZ)
It=E2=80=99s an alternative to = what, exactly? And what happens when someone makes an alternative to = it?
The focus on =E2=80=9CAuthorization= =E2=80=9D as a core part of the name tells only part of the = story. 
Assuming the =E2=80=9CZ=E2=80=9D = is pronounced as its letter name (which is implied by the = capitalization), there=E2=80=99s an issue with pronouncing the = final =E2=80=9CZ=E2=80=9D as either =E2=80=9CZee=E2=80=9D or =E2=80=9CZed=E2= =80=9D depending on dialect. If it=E2=80=99s not pronounced as a letter, = it=E2=80=99s really difficult to say the consonants =E2=80=9Cthz" = together in a way that can be heard and understood.

* BeBAuthZ    Back-end Based = Authorization Protocol
The definition of =E2=80=9Cback = end=E2=80=9D is going to change depending on your perspective in the = stack, but even if it were consistent, the flexibility around user = interaction is a huge motivator for many getting involved in this = work.
This is close to =E2=80=9CBBAuth=E2= =80=9D, which was a commercial predecessor to OAuth 1, so much that = it=E2=80=99s nearly impossible to disambiguate when talking.
= Same comment as above focus on Authorization.
= Same comment as above about Zed/Zee confusion.

* BYOAuthZ    Build-Your-Own = Authorization Protocol
This is the opposite of what = we=E2=80=99re doing here. We don=E2=80=99t want a bunch of disparate = pieces that people can use to build a protocol, we want a protocol with = the right kind of flexibility to fit different use cases. This name = tells developers that they aren=E2=80=99t getting a solution and = incompatibility is likely.
Same = comment as above focus on Authorization.
Same = comment as above about Zed/Zee confusion.

* CPAAP    Comprehensive = Privileged Authentication Authorization Protocol
= This makes me think of CPAP, a breathing assistance device. Not = something I=E2=80=99m keen to call to mind in the middle of a global = pandemic of a respiratory disease.
The = expansion doesn=E2=80=99t really tell me anything.
= What does =E2=80=9Cprivileged=E2=80=9D mean here, and does it = apply to the authentication (which seems implied)?

* DIYAuthZ   =  Do-It-Yourself Authorization Protocol
As above = in BYOAuthZ, this is the opposite of what we=E2=80=99re trying to do by = creating a standard. 
= Same comment as above focus on Authorization.
= Same comment as above about Zed/Zee confusion.

* GranPro    GRAnt Negotiation = Protocol
The acronym is a really awkward = construction. 
As above, =E2=80=9Cgrant=E2=80= =9D is an often misunderstood term from OAuth 2. Plus, the =E2=80=9Cgrant=E2= =80=9D isn=E2=80=99t really what=E2=80=99s being negotiated = here.

* IDPAuthZ    Intent = Driven Protocol for Authorization
=E2=80=9CID= P=E2=80=9D is already well understood in this space to mean =E2=80=9Cident= ity provider=E2=80=9D, so we should not try to overload it.
Same comment as above focus on = Authorization.
Same comment as above about = Zed/Zee confusion.

* = PAuthZ    Protocol for Authorization
It was = suggested this would be pronounced =E2=80=9Cpaws=E2=80=9D but I can=E2=80=99= t think of a single reason someone looking at the word would try to = pronounce it that way. 
It=E2=80=99= s also completely generic and doesn=E2=80=99t say anything about the = work.
Same = comment as above focus on Authorization.
Same = comment as above about Zed/Zee confusion.

* RefAuthZ    Refactored Authorization = Protocol
Refactored from what? What if = someone refactors this? What are the factors?
Same comment as above focus on = Authorization.
Same comment as above about = Zed/Zee confusion.

* = ReAuthZ    Reimagined Authorization Protocol
The short = form is already a short term for =E2=80=9Cre-authorization=E2=80=9D, = which is not what we are doing.
= Reimagined from what, and by whom?
The = expansion sounds like it=E2=80=99s imaginary and not = real.
Same = comment as above focus on Authorization.
Same = comment as above about Zed/Zee confusion.

* TIAAP    Tokenized Identity and Access = Protocol
I don=E2=80=99t think = =E2=80=9Ctokenized=E2=80=9D is used in a meaningful way here. It = produced =E2=80=9Ctokens=E2=80=9D, but tokenization is the splitting up = of an input into pieces, which is not what=E2=80=99s happening = here.

* TIDEAuth    Trust = via Intent Driven Extension Auth
The = expansion is really awkward.
It sounds = like it=E2=80=99s an extension to an existing protocol (something that = we are explicitly NOT doing per the charter).

* TIDYAuth    Trust via Intent Driven Yield = Auth
I actually really like the = acronym but the expansion is super awkward. What is being yielded = here?

* TIEAuth    Trust = via Intent Extension Auth
What is = =E2=80=9Cintent extension=E2=80=9D? 
As above, = it sounds like an extension not a protocol.

* TINOA   This Is Not OAuth
This says = nothing about what this work is, only what it isn=E2=80=99t. And on that = regard, it doesn=E2=80=99t matter that this isn=E2=80=99t OAuth. = OAuth 2 isn=E2=80=99t OAuth 1, either. 
And given = that ease of transition from OAuth 2 is part of the charter, this = isn=E2=80=99t a helpful distinction.

*= TXAuth    Testable eXtensible Authorization
= I don=E2=80=99t get the focus on =E2=80=9Ctestable=E2=80=9D in = the name. Testable in what way? Can other protocols not be = tested?
= Extensibility is not a differentiating feature of this = work.

* TXAuth     =  Truly eXtensible Authorization
= Extensibility is not a differentiating feature of this = work.
What makes something =E2=80=9Ctruly= extensible=E2=80=9D as opposed to =E2=80=9Cnot truly = extensible=E2=80=9D?

* XAuthZ =    eXtensible authoriZation protocol
Extensibility is not a = differentiating feature of this work.
The = acronym is just pulling random letters from the middle of words in the = expansion to try to work.
Same = comment as above focus on Authorization.
Same = comment as above about Zed/Zee confusion.

* WRAC     Web Resource Access = Collaboration
This is not a collaboration = protocol or system. Collaboration, within computer science, is = established to refer to when two or more :people: work and communicate = together. This protocol does not facilitate human communication, and so = the use of this term is not appropriate here. 
= This is very close to =E2=80=9Cwrack=E2=80=9D which is a = common enough English verb, as in =E2=80=9Cwracked nerves=E2=80=9D or = =E2=80=9Cto wrack one=E2=80=99s brain=E2=80=9D, which derives from the = medieval torture process of stretching someone over a rack. = This 

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

= --Apple-Mail=_92C560C9-0304-4342-9F53-19F0B782A863-- From nobody Tue Jun 2 09:57:48 2020 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 2AFB53A0CA8 for ; Tue, 2 Jun 2020 09:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 CEi_qTuj6-IV for ; Tue, 2 Jun 2020 09:57:43 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 376093A0CA7 for ; Tue, 2 Jun 2020 09:57:43 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id r9so3627271wmh.2 for ; Tue, 02 Jun 2020 09:57:43 -0700 (PDT) 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=3vwGInnRHYX/Yu+vqicu7jlDcc326XPFNLE2wMRtm1I=; b=CaVAm8QdiwBVuc40zKe6k/MK544TYVs4xzry8u8T9A58sMGLGqGtFhrqlDn2Lz6Tc9 rKW75mH0vHZv7GBX1nCTMHllR2oG5H5uwYkDtT8hLRT/qCRyfT9/Ts13bolKbYJCsyDe KYxGkpD1Nw/SaUyl9wuvqd3EWf3PYUBDs+UXnosp0faBffm0CobhF80qPHtTuh4KAovC kHxPZCijpWpY/7GMyuY4TuP+1779oqumO8Kpm6pE1NJ8i4HIScMZyu3kVM4wRFWpcwo+ MbTTpmr7UuxE8Cjv1CuFqBbBm6vUIJ409YUoNgUG5xA0qZYz5jRTxs/Lb3Rl61dlSA+N IKeg== 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=3vwGInnRHYX/Yu+vqicu7jlDcc326XPFNLE2wMRtm1I=; b=jqtwt1dwzMg6/xlhh98AnACAkpifBtYG7PeXhdpTSMUcxLa8TTxz2zt+WNxeS0oAv7 8q9MDmhpFhoGoAsCsQYxBXr25tQUQddBbPehnwX01lmq/7WYEB8PD2/vCDcN4ALduGuS tBS+AIXRzZmcrFiEDpZpCrJi6Z6xRY4HvUmfijzzMzCIiqT3A0OK8jX2MzF90m3R849F rKWo7nSLKUVsvo/rCIV/GWfK8nPoX/wQi4N5lhZlFZ0FTWMOS4x2xJRrJlcYyFhNbuOM gTfRfP2dWdkPKlQLpgcF0imkV06vlI40BA6jOburZ4QDU02y2GaUa7Vlq6Yx5GkmCn/t 0qqg== X-Gm-Message-State: AOAM5332hHmNA3esXTYw0xdb3xUbYTWACHe2zhjb7L+2iDgm+GmuzvyE jysfN6hQa1J+tT4BasaNjr0uuHckiZ2aGUk1AAw= X-Google-Smtp-Source: ABdhPJw1SwVgy1XYu2BWzib7qLBiCNcbcp5eo4l7oLP4SkIb+5Jr9xRb7D6aatUhK2CKKGBcfTpT/grdw5UlfhnE97c= X-Received: by 2002:a7b:c0c5:: with SMTP id s5mr4563621wmh.166.1591117057795; Tue, 02 Jun 2020 09:57:37 -0700 (PDT) MIME-Version: 1.0 References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> <73BEEDEF-70D5-4B7A-BE9D-E01A5831D9EF@mit.edu> In-Reply-To: <73BEEDEF-70D5-4B7A-BE9D-E01A5831D9EF@mit.edu> From: Nat Sakimura Date: Wed, 3 Jun 2020 01:57:26 +0900 Message-ID: To: Justin Richer Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000006ab4005a71ccfbc" Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 02 Jun 2020 16:57:46 -0000 --00000000000006ab4005a71ccfbc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While there is some good point to your critique to GNAP, I still seem to like it, partly because I grew up in the country where gnu migration happens every summer, and especially because we need to establish Grant as the properly understood term in relation to OAuth. Best, Nat On Tue, Jun 2, 2020 at 10:18 PM Justin Richer wrote: > Hi everyone, I just wanted to remind the community that feedback on the > potential names is needed by the chairs by this Thursday, June 4th. Pleas= e > post your comments to the list before then! > > Remember, they=E2=80=99re looking for feedback in the form of =E2=80=9Cwo= uldn=E2=80=99t object=E2=80=9D > and =E2=80=9Cwould object=E2=80=9D, and all objections should have specif= ic reasons. > > =E2=80=94 Justin > > On May 28, 2020, at 5:47 PM, Justin Richer wrote: > > Thanks to everyone in the community for suggesting names, and thanks to > the chairs for putting this list together. > > Here=E2=80=99s my personal take on the candidates. > > > > *Wouldn=E2=80=99t Object:* > > * TxAuth Transmission of Authority > This is my personal favorite of the lot because it avoids the > =E2=80=9Cauthorization/authentication=E2=80=9D question and gets at the h= eart of what this > protocol does: delegation, which is to say, transmitting the authority to > do something from one party to another. That delegation allows for > authorized access to resources, but can also allow different rights to fl= ow > as needed. Additionally, =E2=80=9Ctx=E2=80=9D has long been used to stand= for > =E2=80=9Ctransmission=E2=80=9D in computer science and networking. > > * AZARP AuthoriZed Access to Resources Protocol > The use of =E2=80=9CAZ=E2=80=9D to stand for =E2=80=9Cauthorized=E2=80=9D= is awkward, but the > pronunciation kinda works as something memorable. The expansion is a twis= t > of words to make it fit, and I like that less. > Resource access is only part of the story, but it=E2=80=99s an important = part. > This leaves out what we want to do around non-authorization cases (like > identity conveyance). > > * AZARAP AuthoriZation And Resource Access Protocol > I like the expansion here more than the one for AZARP but I like the > acronym less with the additional =E2=80=9CA=E2=80=9D. > Same comment as above for AZ standing for Authorization. > Same comment as above for resource access. > > * DAZARAP Delegated AuthoriZation And Resource Access Protocol > I like the expansion here, but the acronym is awkward and weak. > Same comment as above for AZ standing for Authorized. > Same comment as above for resource access. > > * GNAP Grant Negotiation and Authorization Protocol > This is ok, but it has a couple downsides. The pronunciation of a hard = =E2=80=9Cg=E2=80=9D > or not is going to potentially be confusing, as is the fact that it looks > like it=E2=80=99s part of the GNU project because of that. > The term =E2=80=9CGrant=E2=80=9D is one of the more confusing things that= was introduced > in OAuth 2, and while it=E2=80=99s established in the lexicon today, I=E2= =80=99ve yet to > meet many engineering teams that actually know what a =E2=80=9Cgrant=E2= =80=9D is. Most > think it=E2=80=99s another name for the authorization code. > Also it means =E2=80=9Cto bite=E2=80=9D, which may or may not be desirabl= e. > > * NIRAD Negotiation of Intent Registration and Authority Delegation > This is a somewhat weak construct, but it mostly works. It spells out mor= e > what the protocol will do (if we go with the currently proposed solution > designs) than what it solves, but that might be ok. > It makes me think of NORAD (a positive, they do weather radar and track > Santa Claus each year), but also =E2=80=9Cnimrod=E2=80=9D, a pejorative t= erm. And before > anyone chimes in with =E2=80=9CBut Nimrod was a mighty hunter of ancient = times=E2=80=9D, it > doesn=E2=80=99t mean that to any modern listener. > > * GATAR Grant Authorization To Access Resources > This one isn=E2=80=99t bad, and I can appreciate the =E2=80=9Cguitar=E2= =80=9D pronunciation and > imagery. As above, resource access isonly part of the story. > Same comment about =E2=80=9CGrant=E2=80=9D as above in GNAP. > > > > *Object:* > > * AAuthZ Alternative Authorization Protocol (AAuthZ) > It=E2=80=99s an alternative to what, exactly? And what happens when someo= ne makes > an alternative to it? > The focus on =E2=80=9CAuthorization=E2=80=9D as a core part of the name t= ells only part of > the story. > Assuming the =E2=80=9CZ=E2=80=9D is pronounced as its letter name (which = is implied by the > capitalization), there=E2=80=99s an issue with pronouncing the final =E2= =80=9CZ=E2=80=9D as either > =E2=80=9CZee=E2=80=9D or =E2=80=9CZed=E2=80=9D depending on dialect. If i= t=E2=80=99s not pronounced as a letter, > it=E2=80=99s really difficult to say the consonants =E2=80=9Cthz" togethe= r in a way that > can be heard and understood. > > * BeBAuthZ Back-end Based Authorization Protocol > The definition of =E2=80=9Cback end=E2=80=9D is going to change depending= on your > perspective in the stack, but even if it were consistent, the flexibility > around user interaction is a huge motivator for many getting involved in > this work. > This is close to =E2=80=9CBBAuth=E2=80=9D, which was a commercial predece= ssor to OAuth 1, > so much that it=E2=80=99s nearly impossible to disambiguate when talking. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * BYOAuthZ Build-Your-Own Authorization Protocol > This is the opposite of what we=E2=80=99re doing here. We don=E2=80=99t w= ant a bunch of > disparate pieces that people can use to build a protocol, we want a > protocol with the right kind of flexibility to fit different use cases. > This name tells developers that they aren=E2=80=99t getting a solution an= d > incompatibility is likely. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * CPAAP Comprehensive Privileged Authentication Authorization Protocol > This makes me think of CPAP, a breathing assistance device. Not something > I=E2=80=99m keen to call to mind in the middle of a global pandemic of a > respiratory disease. > The expansion doesn=E2=80=99t really tell me anything. > What does =E2=80=9Cprivileged=E2=80=9D mean here, and does it apply to th= e authentication > (which seems implied)? > > * DIYAuthZ Do-It-Yourself Authorization Protocol > As above in BYOAuthZ, this is the opposite of what we=E2=80=99re trying t= o do by > creating a standard. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * GranPro GRAnt Negotiation Protocol > The acronym is a really awkward construction. > As above, =E2=80=9Cgrant=E2=80=9D is an often misunderstood term from OAu= th 2. Plus, the > =E2=80=9Cgrant=E2=80=9D isn=E2=80=99t really what=E2=80=99s being negotia= ted here. > > * IDPAuthZ Intent Driven Protocol for Authorization > =E2=80=9CIDP=E2=80=9D is already well understood in this space to mean = =E2=80=9Cidentity > provider=E2=80=9D, so we should not try to overload it. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * PAuthZ Protocol for Authorization > It was suggested this would be pronounced =E2=80=9Cpaws=E2=80=9D but I ca= n=E2=80=99t think of a > single reason someone looking at the word would try to pronounce it that > way. > It=E2=80=99s also completely generic and doesn=E2=80=99t say anything abo= ut the work. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * RefAuthZ Refactored Authorization Protocol > Refactored from what? What if someone refactors this? What are the factor= s? > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * ReAuthZ Reimagined Authorization Protocol > The short form is already a short term for =E2=80=9Cre-authorization=E2= =80=9D, which is > not what we are doing. > Reimagined from what, and by whom? > The expansion sounds like it=E2=80=99s imaginary and not real. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * TIAAP Tokenized Identity and Access Protocol > I don=E2=80=99t think =E2=80=9Ctokenized=E2=80=9D is used in a meaningful= way here. It produced > =E2=80=9Ctokens=E2=80=9D, but tokenization is the splitting up of an inpu= t into pieces, > which is not what=E2=80=99s happening here. > > * TIDEAuth Trust via Intent Driven Extension Auth > The expansion is really awkward. > It sounds like it=E2=80=99s an extension to an existing protocol (somethi= ng that > we are explicitly NOT doing per the charter). > > * TIDYAuth Trust via Intent Driven Yield Auth > I actually really like the acronym but the expansion is super awkward. > What is being yielded here? > > * TIEAuth Trust via Intent Extension Auth > What is =E2=80=9Cintent extension=E2=80=9D? > As above, it sounds like an extension not a protocol. > > * TINOA This Is Not OAuth > This says nothing about what this work is, only what it isn=E2=80=99t. An= d on that > regard, it doesn=E2=80=99t matter that this isn=E2=80=99t OAuth. OAuth 2 = isn=E2=80=99t OAuth 1, > either. > And given that ease of transition from OAuth 2 is part of the charter, > this isn=E2=80=99t a helpful distinction. > > * TXAuth Testable eXtensible Authorization > I don=E2=80=99t get the focus on =E2=80=9Ctestable=E2=80=9D in the name. = Testable in what way? Can > other protocols not be tested? > Extensibility is not a differentiating feature of this work. > > * TXAuth Truly eXtensible Authorization > Extensibility is not a differentiating feature of this work. > What makes something =E2=80=9Ctruly extensible=E2=80=9D as opposed to =E2= =80=9Cnot truly > extensible=E2=80=9D? > > * XAuthZ eXtensible authoriZation protocol > Extensibility is not a differentiating feature of this work. > The acronym is just pulling random letters from the middle of words in th= e > expansion to try to work. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * WRAC Web Resource Access Collaboration > This is not a collaboration protocol or system. Collaboration, within > computer science, is established to refer to when two or more :people: wo= rk > and communicate together. This protocol does not facilitate human > communication, and so the use of this term is not appropriate here. > This is very close to =E2=80=9Cwrack=E2=80=9D which is a common enough En= glish verb, as in > =E2=80=9Cwracked nerves=E2=80=9D or =E2=80=9Cto wrack one=E2=80=99s brain= =E2=80=9D, which derives from the medieval > torture process of stretching someone over a rack. This > > -- > 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 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --00000000000006ab4005a71ccfbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While there is some good point=C2=A0to your critique to GN= AP, I still seem to like it, partly because I grew up in the country where = gnu migration happens every summer, and especially because we need to estab= lish Grant as the properly understood term in relation to OAuth.=C2=A0
=
Best,=C2=A0

Nat

On Tue, Jun 2,= 2020 at 10:18 PM Justin Richer <jric= her@mit.edu> wrote:
Hi everyone, I just wa= nted to remind the community that feedback on the potential names is needed= by the chairs by this Thursday, June 4th. Please post your comments to the= list before then!

Remember, they=E2=80=99re looking for= feedback in the form of =E2=80=9Cwouldn=E2=80=99t object=E2=80=9D and =E2= =80=9Cwould object=E2=80=9D, and all objections should have specific reason= s.

=C2=A0=E2=80=94 Justin

On May 28, 2020, at 5:47 PM, Justin Richer <jricher@mit.edu> wrote= :

Thanks to everyone in the co= mmunity for suggesting names, and thanks to the chairs for putting this lis= t together.

Here=E2=80=99s my personal take on the= candidates.



Woul= dn=E2=80=99t Object:

* TxAuth =C2=A0 =C2=A0 =C2=A0T= ransmission of Authority
T= his is my personal favorite of the lot because it avoids the =E2=80=9Cautho= rization/authentication=E2=80=9D question and gets at the heart of what thi= s protocol does: delegation, which is to say, transmitting the authority to= do something from one party to another. That delegation allows for authori= zed access to resources, but can also allow different rights to flow as nee= ded. Additionally, =E2=80=9Ctx=E2=80=9D has long been used to stand for =E2= =80=9Ctransmission=E2=80=9D in computer science and networking.
<= br>
* AZARP =C2=A0 =C2=A0AuthoriZed Access to Resources Protocol
The use of =E2=80=9CAZ= =E2=80=9D to stand for =E2=80=9Cauthorized=E2=80=9D is awkward, but the pro= nunciation kinda works as something memorable. The expansion is a twist of = words to make it fit, and I like that less.
Resource access is only part of the story, but it= =E2=80=99s an important part. This leaves out what we want to do around non= -authorization cases (like identity conveyance).

* AZAR= AP =C2=A0 =C2=A0AuthoriZation And Resource Access Protocol
I like the expansion here more than = the one for AZARP but I like the acronym less with the additional =E2=80=9C= A=E2=80=9D.
Same com= ment as above for AZ standing for Authorization.
Same comment as above for resource access.

* DAZARAP =C2=A0 =C2=A0Delegated AuthoriZation And Resource= Access Protocol
I like the expansion here, but the acronym is awkward and weak.=C2=A0
Same comment as above fo= r AZ standing for Authorized.
Same comment as above for resource access.
<= br>
* GNAP =C2=A0 =C2=A0Grant Negotiation and Authorization Proto= col
This is ok, = but it has a couple downsides. The pronunciation of a hard =E2=80=9Cg=E2=80= =9D or not is going to potentially be confusing, as is the fact that it loo= ks like it=E2=80=99s part of the GNU project because of that.
The term =E2=80=9CGrant=E2=80=9D = is one of the more confusing things that was introduced in OAuth 2, and whi= le it=E2=80=99s established in the lexicon today, I=E2=80=99ve yet to meet = many engineering teams that actually know what a =E2=80=9Cgrant=E2=80=9D is= . Most think it=E2=80=99s another name for the authorization code.
Also it means =E2=80=9Cto bi= te=E2=80=9D, which may or may not be desirable.

* = NIRAD =C2=A0 =C2=A0Negotiation of Intent Registration and Authority Delegat= ion
This is a so= mewhat weak construct, but it mostly works. It spells out more what the pro= tocol will do (if we go with the currently proposed solution designs) than = what it solves, but that might be ok.
It makes me think of NORAD (a positive, they do weather r= adar and track Santa Claus each year), but also =E2=80=9Cnimrod=E2=80=9D, a= pejorative term. And before anyone chimes in with =E2=80=9CBut Nimrod was = a mighty hunter of ancient times=E2=80=9D, it doesn=E2=80=99t mean that to = any modern listener.

* GATAR =C2=A0 =C2=A0 =C2=A0G= rant Authorization To Access Resources=C2=A0
This one isn=E2=80=99t bad, and I can appreciate t= he =E2=80=9Cguitar=E2=80=9D pronunciation and imagery. As above, resource a= ccess isonly part of the story.
Same comment about =E2=80=9CGrant=E2=80=9D as above in GNAP.



Object:

* AAuthZ =C2=A0 =C2=A0Alternative Authorization Protocol (AAut= hZ)
It=E2=80=99s an = alternative to what, exactly? And what happens when someone makes an altern= ative to it?
The foc= us on =E2=80=9CAuthorization=E2=80=9D as a core part of the name tells only= part of the story.=C2=A0
<= /span>Assuming the =E2=80=9CZ=E2=80=9D is pronounced as its letter name (wh= ich is implied by the capitalization),=C2=A0there=E2=80=99s an issue with p= ronouncing the final =E2=80=9CZ=E2=80=9D as either =E2=80=9CZee=E2=80=9D or= =E2=80=9CZed=E2=80=9D depending on dialect. If it=E2=80=99s not pronounced= as a letter, it=E2=80=99s really difficult to say the consonants =E2=80=9C= thz" together in a way that can be heard and understood.
* BeBAuthZ =C2=A0 =C2=A0Back-end Based Authorization Protocol
The definition of =E2=80=9Cback = end=E2=80=9D is going to change depending on your perspective in the stack,= but even if it were consistent, the flexibility around user interaction is= a huge motivator for many getting involved in this work.
This is close to =E2=80=9CBBAuth=E2= =80=9D, which was a commercial predecessor to OAuth 1, so much that it=E2= =80=99s nearly impossible to disambiguate when talking.
Same comment as above focus on Authoriz= ation.
Same comment = as above about Zed/Zee confusion.

* BYOAuthZ =C2=A0 =C2=A0Bui= ld-Your-Own Authorization Protocol
This is the opposite of what we=E2=80=99re doing here. We do= n=E2=80=99t want a bunch of disparate pieces that people can use to build a= protocol, we want a protocol with the right kind of flexibility to fit dif= ferent use cases. This name tells developers that they aren=E2=80=99t getti= ng a solution and incompatibility is likely.
Same comment as above focus on Authorization.=
Same comment as abo= ve about Zed/Zee confusion.

* CPAAP =C2=A0 = =C2=A0Comprehensive Privileged Authentication Authorization Protocol
<= div> This makes me think of CPA= P, a breathing assistance device. Not something I=E2=80=99m keen to call to= mind in the middle of a global pandemic of a respiratory disease.
The expansion doesn=E2=80=99= t really tell me anything.
= What does =E2=80=9Cprivileged=E2=80=9D mean here, and does it apply = to the authentication (which seems implied)?

* DIY= AuthZ =C2=A0 =C2=A0Do-It-Yourself Authorization Protocol
As above in BYOAuthZ, this is the oppo= site of what we=E2=80=99re trying to do by creating a standard.=C2=A0
=
Same comment as= above focus on Authorization.
Same comment as above about Zed/Zee confusion.
<= br>
* GranPro =C2=A0 =C2=A0GRAnt Negotiation Protocol
The acronym is a really awkward cons= truction.=C2=A0
As a= bove,=C2=A0=E2=80=9Cgrant=E2=80=9D is an often misunderstood term from OAut= h 2. Plus, the =E2=80=9Cgrant=E2=80=9D isn=E2=80=99t really what=E2=80=99s = being negotiated here.

* IDPAuthZ =C2=A0 =C2=A0Intent Driven = Protocol for Authorization
= =E2=80=9CIDP=E2=80=9D is already well understood in this space to me= an =E2=80=9Cidentity provider=E2=80=9D, so we should not try to overload it= .
Same comment as= above focus on Authorization.
Same comment as above about Zed/Zee confusion.
<= br>
* PAuthZ =C2=A0 =C2=A0Protocol for Authorization
It was suggested this would be pronou= nced =E2=80=9Cpaws=E2=80=9D but I can=E2=80=99t think of a single reason so= meone looking at the word would try to pronounce it that way.=C2=A0
It=E2=80=99s also completel= y generic and doesn=E2=80=99t say anything about the work.
Same comment as above focus on Au= thorization.
Same co= mment as above about Zed/Zee confusion.

* RefAuth= Z =C2=A0 =C2=A0Refactored Authorization Protocol
Refactored from what? What if someone refactor= s this? What are the factors?
Same comment as above focus on Authorization.
Same comment as above about Zed/Zee = confusion.

* ReAuthZ =C2=A0 =C2=A0Reimagined Auth= orization Protocol
The sh= ort form is already a short term for =E2=80=9Cre-authorization=E2=80=9D, wh= ich is not what we are doing.
Reimagined from what, and by whom?
The expansion=C2=A0sounds like it=E2=80= =99s imaginary and not real.
Same comment as above focus on Authorization.
= Same comment as above about Ze= d/Zee confusion.

* TIAAP =C2=A0 =C2=A0Tokenized I= dentity and Access Protocol
= I don=E2=80=99t think =E2=80=9Ctokenized=E2=80=9D is used in a mean= ingful way here. It produced =E2=80=9Ctokens=E2=80=9D, but tokenization is = the splitting up of an input into pieces, which is not what=E2=80=99s happe= ning here.

* TIDEAuth =C2=A0 =C2=A0Trust via Intent Driven Ex= tension Auth
The exp= ansion is really awkward.
<= /span>It sounds like it=E2=80=99s an extension to an existing protocol (som= ething that we are explicitly NOT doing per the charter).

* TIDYAuth =C2=A0 =C2=A0Trust via= Intent Driven Yield Auth
<= /span>I actually really like the acronym but the expansion is super awkward= . What is being yielded here?

* TIEAuth =C2=A0 =C2=A0Trust vi= a Intent Extension Auth
What is =E2=80=9Cintent extension=E2=80=9D?=C2=A0
As above, it sounds like an extension not= a protocol.

* TINOA =C2=A0 This Is Not OAuth
This says nothing about what this w= ork is, only what it isn=E2=80=99t. And on that regard,=C2=A0it doesn=E2=80= =99t matter that this isn=E2=80=99t OAuth. OAuth 2 isn=E2=80=99t OAuth 1, e= ither.=C2=A0
And giv= en that ease of transition from OAuth 2 is part of the charter, this isn=E2= =80=99t a helpful distinction.

* TXAuth =C2=A0 =C2=A0Testable= eXtensible Authorization
<= /span>I don=E2=80=99t get the focus on =E2=80=9Ctestable=E2=80=9D in the na= me. Testable in what way? Can other protocols not be tested?
Extensibility is not a differ= entiating feature of this work.

* TXAuth =C2=A0 =C2=A0 = =C2=A0Truly eXtensible Authorization
Extensibility is not a differentiating feature of this work.=
What makes somethin= g =E2=80=9Ctruly extensible=E2=80=9D as opposed to =E2=80=9Cnot truly exten= sible=E2=80=9D?

* XAuthZ =C2=A0 =C2=A0eXtensible author= iZation protocol
= Extensibility is not a differentiating feature of this work.
The acronym is just pulling random= letters from the middle of words in the expansion to try to work.
Same comment as above focus = on Authorization.
Sa= me comment as above about Zed/Zee confusion.

* WR= AC =C2=A0 =C2=A0 Web Resource Access Collaboration
This is not a collaboration protocol or syst= em. Collaboration, within computer science, is established to refer to when= two or more :people: work and communicate together. This protocol does not= facilitate human communication, and so the use of this term is not appropr= iate here.=C2=A0
Thi= s is very close to=C2=A0=E2=80=9Cwrack=E2=80=9D which is a common enough En= glish verb, as in =E2=80=9Cwracked nerves=E2=80=9D or =E2=80=9Cto wrack one= =E2=80=99s brain=E2=80=9D, which derives from the medieval torture process = of stretching someone over a rack. This=C2=A0

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

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


--
Nat Sakimura (=3Dnat)
Chairman, OpenID Found= ation
http://nat.= sakimura.org/
@_nat_en
--00000000000006ab4005a71ccfbc-- From nobody Tue Jun 2 14:30:12 2020 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 73D0B3A1023 for ; Tue, 2 Jun 2020 14:30:10 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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=123-do.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 vSk5PHPp_NyD for ; Tue, 2 Jun 2020 14:30:09 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 607F63A101F for ; Tue, 2 Jun 2020 14:30:09 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id h3so311668ilh.13 for ; Tue, 02 Jun 2020 14:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=123-do.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=yhFx8+eKpYRFk6mYnwtRdCQ73rtnTYg2woiymePMRfc=; b=VtwP/jjjmAm3rBgzdrqWa7Jjg8lYMtk9fUMKIPVSiq4zs96bvNLRruoB/A6Dz9GA54 o/TH8P0R3FXrRqnQWn0acjk3A6tYbP84lL1a7TX9MvdWRiLZg5eEe5V1Lzafv5MKGK5Z ZFL+h0+DA62/Nigj3z5pFZ0nCkmqNFOSrZLbdglpVxLHfFPSz0TrKqcU9lkXvoSIrCjB xqBL2/BpnBaTkj8CzQWImVukwFTC1NdgDscILGc2Yz7N7dBBz34hAz1CFUBdazV2YbB7 4LeKv1PsXvRJmlPZCNc1CcgrbgzhB/Z/7dp4y9Uo/FaTsHXv67nVRQrPkJUHpbhK35gF EUoA== 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=yhFx8+eKpYRFk6mYnwtRdCQ73rtnTYg2woiymePMRfc=; b=ZUg7rXefvi5791BVoeYeWUDQIZuEoCXf4dw+Y2QSbmwatiZbs417w8szePAChCSX4l cNdLG70oSb/rWfAXP7chZN370GqPfaCG52gFkYezMH+h7uQRRtMvcsUs6zl8bJaAjwRy ucfv0mPTCPoLfk+6fS5nhH25Go2d1GmUsKUDUG73+ec2NMMroOrb7vKno73opWqYARXx veDJrcj7SkOFKNHbwWfpGrzdXxNeTHUOetB4a0PBkVTv/zXNb/yqGuJBBqcILJtsC922 2JJBtyZJjUQKpZokWCtd23SIzcASnvbDk9r2TIONDUOOhzJfZPq11XXvPznK8dSamRrO OrUA== X-Gm-Message-State: AOAM532GFVusDzjIWEFJz6z7RKC+zW/vahO5tHVjdHLPwQEDEwo1waRB XIdnB0HFqxBFYuSAGyp/AoU0lIDTgeZJpNC7tRLx6p7O5KK8Tw== X-Google-Smtp-Source: ABdhPJxepyf1GQVJny9LB8I4cKs2mo8pgN1b2ZUdFD7xblvURMIO1k/q5Ti2cj7un/O7le7sC50IpbUTPsfs8U6d9Ds= X-Received: by 2002:a92:b11:: with SMTP id b17mr1146645ilf.257.1591133408084; Tue, 02 Jun 2020 14:30:08 -0700 (PDT) MIME-Version: 1.0 From: Nigel Hamilton Date: Tue, 2 Jun 2020 22:29:57 +0100 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000945a4905a7209d6f" Archived-At: Subject: [Txauth] naming 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, 02 Jun 2020 21:30:10 -0000 --000000000000945a4905a7209d6f Content-Type: text/plain; charset="UTF-8" Hi, Just wanted to suggest some alternative expansions for GATAR: - Give Authorisation To Access Resources - Gain Authorisation To Access Resources - Get Authorisation To Access Resources Nige --000000000000945a4905a7209d6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Just wanted to suggest some alt= ernative expansions for GATAR:

- Give Authorisatio= n To Access Resources
- Gain Authorisation To Access Resourc= es
- Get Authorisation To Access Resources

Nige
--000000000000945a4905a7209d6f-- From nobody Tue Jun 2 14:59:18 2020 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 0D4803A07E2 for ; Tue, 2 Jun 2020 14:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 KhSNol9M6Bn5 for ; Tue, 2 Jun 2020 14:59:14 -0700 (PDT) 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 0F0733A07E0 for ; Tue, 2 Jun 2020 14:59:14 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id o9so158599ljj.6 for ; Tue, 02 Jun 2020 14:59:13 -0700 (PDT) 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=xG7I+U6MpmWE3FW53nKKkci+kYEkBRcBJvp/k7suKTM=; b=dA2OSE1OfXxelE0E6FvTsExynZa1OQK8SUa5SdpCq3zg8PfYQiizHJrf1SkaHiDpK9 EvhYTRInRCBd1WJx4N24ZDnGEOO6b90nMUsN9uU6GlAjqI4NJyJRPDieNJ61uprQLHKA 7cu3WpeoiA71Ba194G2LplF5fBXA+pKAnSbGgTJKImnSG5HYoicWo0/pCJi+2otjPgbX LKOiqDnCWsPGJBx49MUyv1MKTkfeSOTgJgRAAdBhoyIjNRSU04mV9HC0Kz8eGwRbqVY1 jsho/BEv41wkLQBn082KB9MS8Z2S+YQkDRvXASGq+Sj9zFvMznWo4JB6BlqEzKOZE/WP /qtA== 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=xG7I+U6MpmWE3FW53nKKkci+kYEkBRcBJvp/k7suKTM=; b=iLlQ3GTt1084bT/zYDEknHjmGXiVFI4Cyh+gSs9mlrDJjXejTMU2QKaoRLHY85HBd/ ABLvWfXzNTe9Csl3NsGjWvfbSFmL/i5Uv+K8tt3qySMmNrjhCBqgYaFPwMCdHvEylbi2 kHLLvhifu6gWm3BJMR3+Iff9dqGr7S5LJxhPPI3KgrWwhFaQ1jFn767y2oShqw4oZ4BW 4s1HiYBo09yhtP9pfdvmEHf7ZvyF45FjlC8LJPFP/U7JS+ScM5STDQYyR27EuZzleQP5 lcRTGgSiwyX3zMEki9mpS8fT8VVp+vNXBBlNWXcfyu3dSVXhlACwyI7Ocf/Jlz/Y/Kl/ dlGg== X-Gm-Message-State: AOAM532KijBr6mqF1lhZKnL21WQHUvr/thufQxJNJmi1a9teFYBAnu8H fDFWlmaAZo6/JmrvV8CiJt9qAeMrM1Lh3ZTWlTU= X-Google-Smtp-Source: ABdhPJwNqMLkjHIv6ZUc6bH4SIhfl/Q2bodi6kRMwv6wYa3b71+w70ylGqTFWEOC5Zj7/ptkC9JuIR5jDypAqyBlzNY= X-Received: by 2002:a2e:140a:: with SMTP id u10mr553734ljd.56.1591135152048; Tue, 02 Jun 2020 14:59:12 -0700 (PDT) MIME-Version: 1.0 References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> In-Reply-To: From: Dick Hardt Date: Tue, 2 Jun 2020 14:58:46 -0700 Message-ID: To: Justin Richer Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000087111805a7210513" Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 02 Jun 2020 21:59:17 -0000 --00000000000087111805a7210513 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Justin, Per your comment "Extensibility is not a differentiating feature of this work.", extensibility is explicitly called out in the charter (and is not in the OAuth WG charter): 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 - Mechanisms for conveying user, software, organization, and other pieces of information used in authorization decisions - Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys - Optimized inclusion of additional information through the delegation process (including identifiers and identity assertions) Milestones to include: - Guidelines for use of protocol extension points [1] https://datatracker.ietf.org/wg/txauth/about/ =E1=90=A7 On Thu, May 28, 2020 at 2:47 PM Justin Richer wrote: > Thanks to everyone in the community for suggesting names, and thanks to > the chairs for putting this list together. > > Here=E2=80=99s my personal take on the candidates. > > > > *Wouldn=E2=80=99t Object:* > > * TxAuth Transmission of Authority > This is my personal favorite of the lot because it avoids the > =E2=80=9Cauthorization/authentication=E2=80=9D question and gets at the h= eart of what this > protocol does: delegation, which is to say, transmitting the authority to > do something from one party to another. That delegation allows for > authorized access to resources, but can also allow different rights to fl= ow > as needed. Additionally, =E2=80=9Ctx=E2=80=9D has long been used to stand= for > =E2=80=9Ctransmission=E2=80=9D in computer science and networking. > > * AZARP AuthoriZed Access to Resources Protocol > The use of =E2=80=9CAZ=E2=80=9D to stand for =E2=80=9Cauthorized=E2=80=9D= is awkward, but the > pronunciation kinda works as something memorable. The expansion is a twis= t > of words to make it fit, and I like that less. > Resource access is only part of the story, but it=E2=80=99s an important = part. > This leaves out what we want to do around non-authorization cases (like > identity conveyance). > > * AZARAP AuthoriZation And Resource Access Protocol > I like the expansion here more than the one for AZARP but I like the > acronym less with the additional =E2=80=9CA=E2=80=9D. > Same comment as above for AZ standing for Authorization. > Same comment as above for resource access. > > * DAZARAP Delegated AuthoriZation And Resource Access Protocol > I like the expansion here, but the acronym is awkward and weak. > Same comment as above for AZ standing for Authorized. > Same comment as above for resource access. > > * GNAP Grant Negotiation and Authorization Protocol > This is ok, but it has a couple downsides. The pronunciation of a hard = =E2=80=9Cg=E2=80=9D > or not is going to potentially be confusing, as is the fact that it looks > like it=E2=80=99s part of the GNU project because of that. > The term =E2=80=9CGrant=E2=80=9D is one of the more confusing things that= was introduced > in OAuth 2, and while it=E2=80=99s established in the lexicon today, I=E2= =80=99ve yet to > meet many engineering teams that actually know what a =E2=80=9Cgrant=E2= =80=9D is. Most > think it=E2=80=99s another name for the authorization code. > Also it means =E2=80=9Cto bite=E2=80=9D, which may or may not be desirabl= e. > > * NIRAD Negotiation of Intent Registration and Authority Delegation > This is a somewhat weak construct, but it mostly works. It spells out mor= e > what the protocol will do (if we go with the currently proposed solution > designs) than what it solves, but that might be ok. > It makes me think of NORAD (a positive, they do weather radar and track > Santa Claus each year), but also =E2=80=9Cnimrod=E2=80=9D, a pejorative t= erm. And before > anyone chimes in with =E2=80=9CBut Nimrod was a mighty hunter of ancient = times=E2=80=9D, it > doesn=E2=80=99t mean that to any modern listener. > > * GATAR Grant Authorization To Access Resources > This one isn=E2=80=99t bad, and I can appreciate the =E2=80=9Cguitar=E2= =80=9D pronunciation and > imagery. As above, resource access isonly part of the story. > Same comment about =E2=80=9CGrant=E2=80=9D as above in GNAP. > > > > *Object:* > > * AAuthZ Alternative Authorization Protocol (AAuthZ) > It=E2=80=99s an alternative to what, exactly? And what happens when someo= ne makes > an alternative to it? > The focus on =E2=80=9CAuthorization=E2=80=9D as a core part of the name t= ells only part of > the story. > Assuming the =E2=80=9CZ=E2=80=9D is pronounced as its letter name (which = is implied by the > capitalization), there=E2=80=99s an issue with pronouncing the final =E2= =80=9CZ=E2=80=9D as either > =E2=80=9CZee=E2=80=9D or =E2=80=9CZed=E2=80=9D depending on dialect. If i= t=E2=80=99s not pronounced as a letter, > it=E2=80=99s really difficult to say the consonants =E2=80=9Cthz" togethe= r in a way that > can be heard and understood. > > * BeBAuthZ Back-end Based Authorization Protocol > The definition of =E2=80=9Cback end=E2=80=9D is going to change depending= on your > perspective in the stack, but even if it were consistent, the flexibility > around user interaction is a huge motivator for many getting involved in > this work. > This is close to =E2=80=9CBBAuth=E2=80=9D, which was a commercial predece= ssor to OAuth 1, > so much that it=E2=80=99s nearly impossible to disambiguate when talking. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * BYOAuthZ Build-Your-Own Authorization Protocol > This is the opposite of what we=E2=80=99re doing here. We don=E2=80=99t w= ant a bunch of > disparate pieces that people can use to build a protocol, we want a > protocol with the right kind of flexibility to fit different use cases. > This name tells developers that they aren=E2=80=99t getting a solution an= d > incompatibility is likely. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * CPAAP Comprehensive Privileged Authentication Authorization Protocol > This makes me think of CPAP, a breathing assistance device. Not something > I=E2=80=99m keen to call to mind in the middle of a global pandemic of a > respiratory disease. > The expansion doesn=E2=80=99t really tell me anything. > What does =E2=80=9Cprivileged=E2=80=9D mean here, and does it apply to th= e authentication > (which seems implied)? > > * DIYAuthZ Do-It-Yourself Authorization Protocol > As above in BYOAuthZ, this is the opposite of what we=E2=80=99re trying t= o do by > creating a standard. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * GranPro GRAnt Negotiation Protocol > The acronym is a really awkward construction. > As above, =E2=80=9Cgrant=E2=80=9D is an often misunderstood term from OAu= th 2. Plus, the > =E2=80=9Cgrant=E2=80=9D isn=E2=80=99t really what=E2=80=99s being negotia= ted here. > > * IDPAuthZ Intent Driven Protocol for Authorization > =E2=80=9CIDP=E2=80=9D is already well understood in this space to mean = =E2=80=9Cidentity > provider=E2=80=9D, so we should not try to overload it. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * PAuthZ Protocol for Authorization > It was suggested this would be pronounced =E2=80=9Cpaws=E2=80=9D but I ca= n=E2=80=99t think of a > single reason someone looking at the word would try to pronounce it that > way. > It=E2=80=99s also completely generic and doesn=E2=80=99t say anything abo= ut the work. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * RefAuthZ Refactored Authorization Protocol > Refactored from what? What if someone refactors this? What are the factor= s? > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * ReAuthZ Reimagined Authorization Protocol > The short form is already a short term for =E2=80=9Cre-authorization=E2= =80=9D, which is > not what we are doing. > Reimagined from what, and by whom? > The expansion sounds like it=E2=80=99s imaginary and not real. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * TIAAP Tokenized Identity and Access Protocol > I don=E2=80=99t think =E2=80=9Ctokenized=E2=80=9D is used in a meaningful= way here. It produced > =E2=80=9Ctokens=E2=80=9D, but tokenization is the splitting up of an inpu= t into pieces, > which is not what=E2=80=99s happening here. > > * TIDEAuth Trust via Intent Driven Extension Auth > The expansion is really awkward. > It sounds like it=E2=80=99s an extension to an existing protocol (somethi= ng that > we are explicitly NOT doing per the charter). > > * TIDYAuth Trust via Intent Driven Yield Auth > I actually really like the acronym but the expansion is super awkward. > What is being yielded here? > > * TIEAuth Trust via Intent Extension Auth > What is =E2=80=9Cintent extension=E2=80=9D? > As above, it sounds like an extension not a protocol. > > * TINOA This Is Not OAuth > This says nothing about what this work is, only what it isn=E2=80=99t. An= d on that > regard, it doesn=E2=80=99t matter that this isn=E2=80=99t OAuth. OAuth 2 = isn=E2=80=99t OAuth 1, > either. > And given that ease of transition from OAuth 2 is part of the charter, > this isn=E2=80=99t a helpful distinction. > > * TXAuth Testable eXtensible Authorization > I don=E2=80=99t get the focus on =E2=80=9Ctestable=E2=80=9D in the name. = Testable in what way? Can > other protocols not be tested? > Extensibility is not a differentiating feature of this work. > > * TXAuth Truly eXtensible Authorization > Extensibility is not a differentiating feature of this work. > What makes something =E2=80=9Ctruly extensible=E2=80=9D as opposed to =E2= =80=9Cnot truly > extensible=E2=80=9D? > > * XAuthZ eXtensible authoriZation protocol > Extensibility is not a differentiating feature of this work. > The acronym is just pulling random letters from the middle of words in th= e > expansion to try to work. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. > > * WRAC Web Resource Access Collaboration > This is not a collaboration protocol or system. Collaboration, within > computer science, is established to refer to when two or more :people: wo= rk > and communicate together. This protocol does not facilitate human > communication, and so the use of this term is not appropriate here. > This is very close to =E2=80=9Cwrack=E2=80=9D which is a common enough En= glish verb, as in > =E2=80=9Cwracked nerves=E2=80=9D or =E2=80=9Cto wrack one=E2=80=99s brain= =E2=80=9D, which derives from the medieval > torture process of stretching someone over a rack. This > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000087111805a7210513 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Justin,

Per your comment "= Extensibility is not a differentiating feature of this work.", extensi= bility is explicitly called out in the charter (and is not in the OAuth WG = charter):

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

- Cryptographic agility for keys, message signatures, and proof of po= ssession
- User interaction mechanisms including web and non-web = methods
- Mechanisms for conveying user, software, organization, = and other pieces of information used in authorization decisions
-= Mechanisms for presenting tokens to resource servers and binding resource = requests to tokens and associated cryptographic keys
- Optimized = inclusion of additional information through the delegation process (includi= ng identifiers and identity assertions)

Milestones= to include:
<snip>
- Guidelines for use of proto= col extension points

[1]=C2=A0<= a href=3D"https://datatracker.ietf.org/wg/txauth/about/" target=3D"_blank">= https://datatracker.ietf.org/wg/txauth/about/
3D""=E1= =90=A7

On Thu, May 28, 2020 at 2:47 PM Justin Richer <jricher@mit.edu> wrote:
=
Thanks to= everyone in the community for suggesting names, and thanks to the chairs f= or putting this list together.

Here=E2=80=99s my p= ersonal take on the candidates.


Wouldn=E2=80=99t Object:

* TxAuth = =C2=A0 =C2=A0 =C2=A0Transmission of Authority
This is my personal favorite of the lot because it avoi= ds the =E2=80=9Cauthorization/authentication=E2=80=9D question and gets at = the heart of what this protocol does: delegation, which is to say, transmit= ting the authority to do something from one party to another. That delegati= on allows for authorized access to resources, but can also allow different = rights to flow as needed. Additionally, =E2=80=9Ctx=E2=80=9D has long been = used to stand for =E2=80=9Ctransmission=E2=80=9D in computer science and ne= tworking.

* AZARP =C2=A0 =C2=A0AuthoriZed Access to Reso= urces Protocol
T= he use of =E2=80=9CAZ=E2=80=9D to stand for =E2=80=9Cauthorized=E2=80=9D is= awkward, but the pronunciation kinda works as something memorable. The exp= ansion is a twist of words to make it fit, and I like that less.
= Resource access is only part o= f the story, but it=E2=80=99s an important part. This leaves out what we wa= nt to do around non-authorization cases (like identity conveyance).

* AZARAP =C2=A0 =C2=A0AuthoriZation And Resource Access Protoc= ol
I like the expans= ion here more than the one for AZARP but I like the acronym less with the a= dditional =E2=80=9CA=E2=80=9D.
Same comment as above for AZ standing for Authorization.
Same comment as above for r= esource access.

* DAZARAP =C2=A0 =C2=A0Delegated Authori= Zation And Resource Access Protocol
I like the expansion here, but the acronym is awkward a= nd weak.=C2=A0
Same = comment as above for AZ standing for Authorized.
Same comment as above for resource access= .

* GNAP =C2=A0 =C2=A0Grant Negotiation and = Authorization Protocol
= This is ok, but it has a couple downsides. The pronunciation of a ha= rd =E2=80=9Cg=E2=80=9D or not is going to potentially be confusing, as is t= he fact that it looks like it=E2=80=99s part of the GNU project because of = that.
The term =E2= =80=9CGrant=E2=80=9D is one of the more confusing things that was introduce= d in OAuth 2, and while it=E2=80=99s established in the lexicon today, I=E2= =80=99ve yet to meet many engineering teams that actually know what a =E2= =80=9Cgrant=E2=80=9D is. Most think it=E2=80=99s another name for the autho= rization code.
Also = it means =E2=80=9Cto bite=E2=80=9D, which may or may not be desirable.

* NIRAD =C2=A0 =C2=A0Negotiation of Intent Registratio= n and Authority Delegation
This is a somewhat weak construct, but it mostly works. It spell= s out more what the protocol will do (if we go with the currently proposed = solution designs) than what it solves, but that might be ok.
It makes me think of NORAD (a posi= tive, they do weather radar and track Santa Claus each year), but also =E2= =80=9Cnimrod=E2=80=9D, a pejorative term. And before anyone chimes in with = =E2=80=9CBut Nimrod was a mighty hunter of ancient times=E2=80=9D, it doesn= =E2=80=99t mean that to any modern listener.

* GAT= AR =C2=A0 =C2=A0 =C2=A0Grant Authorization To Access Resources=C2=A0
<= div> This one isn=E2=80=99t bad= , and I can appreciate the =E2=80=9Cguitar=E2=80=9D pronunciation and image= ry. As above, resource access isonly part of the story.
Same comment about =E2=80=9CGrant=E2=80= =9D as above in GNAP.



Object:

* AAuthZ =C2=A0 =C2=A0Alternative Auth= orization Protocol (AAuthZ)
= It=E2=80=99s an alternative to what, exactly? And what happens when= someone makes an alternative to it?
The focus on =E2=80=9CAuthorization=E2=80=9D as a core par= t of the name tells only part of the story.=C2=A0
Assuming the =E2=80=9CZ=E2=80=9D is pronounce= d as its letter name (which is implied by the capitalization),=C2=A0there= =E2=80=99s an issue with pronouncing the final =E2=80=9CZ=E2=80=9D as eithe= r =E2=80=9CZee=E2=80=9D or =E2=80=9CZed=E2=80=9D depending on dialect. If i= t=E2=80=99s not pronounced as a letter, it=E2=80=99s really difficult to sa= y the consonants =E2=80=9Cthz" together in a way that can be heard and= understood.

* BeBAuthZ =C2=A0 =C2=A0Back-end Based Authoriza= tion Protocol
The de= finition of =E2=80=9Cback end=E2=80=9D is going to change depending on your= perspective in the stack, but even if it were consistent, the flexibility = around user interaction is a huge motivator for many getting involved in th= is work.
This is clo= se to =E2=80=9CBBAuth=E2=80=9D, which was a commercial predecessor to OAuth= 1, so much that it=E2=80=99s nearly impossible to disambiguate when talkin= g.
Same comment as a= bove focus on Authorization.
Same comment as above about Zed/Zee confusion.

* BYO= AuthZ =C2=A0 =C2=A0Build-Your-Own Authorization Protocol
This is the opposite of what we=E2=80= =99re doing here. We don=E2=80=99t want a bunch of disparate pieces that pe= ople can use to build a protocol, we want a protocol with the right kind of= flexibility to fit different use cases. This name tells developers that th= ey aren=E2=80=99t getting a solution and incompatibility is likely.
Same comment as above = focus on Authorization.
Same comment as above about Zed/Zee confusion.

* CPAAP =C2=A0 =C2=A0Comprehensive Privileged Authentication Authori= zation Protocol
This= makes me think of CPAP, a breathing assistance device. Not something I=E2= =80=99m keen to call to mind in the middle of a global pandemic of a respir= atory disease.
The e= xpansion doesn=E2=80=99t really tell me anything.
What does =E2=80=9Cprivileged=E2=80=9D mean h= ere, and does it apply to the authentication (which seems implied)?

* DIYAuthZ =C2=A0 =C2=A0Do-It-Yourself Authorization Prot= ocol
As above in BYO= AuthZ, this is the opposite of what we=E2=80=99re trying to do by creating = a standard.=C2=A0
= Same comment as above focus on Authorization.
Same comment as above about Zed/Zee confu= sion.

* GranPro =C2=A0 =C2=A0GRAnt Negotiation Pr= otocol
The acronym i= s a really awkward construction.=C2=A0
As above,=C2=A0=E2=80=9Cgrant=E2=80=9D is an often misun= derstood term from OAuth 2. Plus, the =E2=80=9Cgrant=E2=80=9D isn=E2=80=99t= really what=E2=80=99s being negotiated here.

* IDPAuthZ =C2= =A0 =C2=A0Intent Driven Protocol for Authorization
=E2=80=9CIDP=E2=80=9D is already well unders= tood in this space to mean =E2=80=9Cidentity provider=E2=80=9D, so we shoul= d not try to overload it.
Same comment as above focus on Authorization.
Same comment as above about Zed/Zee conf= usion.

* PAuthZ =C2=A0 =C2=A0Protocol for Authori= zation
It was sugges= ted this would be pronounced =E2=80=9Cpaws=E2=80=9D but I can=E2=80=99t thi= nk of a single reason someone looking at the word would try to pronounce it= that way.=C2=A0
It= =E2=80=99s also completely generic and doesn=E2=80=99t say anything about t= he work.
Same com= ment as above focus on Authorization.
Same comment as above about Zed/Zee confusion.

* RefAuthZ =C2=A0 =C2=A0Refactored Authorization Protocol
Refactored from what?= What if someone refactors this? What are the factors?
Same comment as above focus on Author= ization.
Same commen= t as above about Zed/Zee confusion.

* ReAuthZ =C2= =A0 =C2=A0Reimagined Authorization Protocol
The short form is already a short term for =E2=80=9Cre-a= uthorization=E2=80=9D, which is not what we are doing.
<= span style=3D"white-space:pre-wrap"> Reimagined from what, and by wh= om?
The expansion=C2= =A0sounds like it=E2=80=99s imaginary and not real.
Same comment as above focus on Au= thorization.
Same co= mment as above about Zed/Zee confusion.

* TIAAP = =C2=A0 =C2=A0Tokenized Identity and Access Protocol
I don=E2=80=99t think =E2=80=9Ctokenized= =E2=80=9D is used in a meaningful way here. It produced =E2=80=9Ctokens=E2= =80=9D, but tokenization is the splitting up of an input into pieces, which= is not what=E2=80=99s happening here.

* TIDEAuth =C2=A0 =C2= =A0Trust via Intent Driven Extension Auth
The expansion is really awkward.
It sounds like it=E2=80=99s an extension= to an existing protocol (something that we are explicitly NOT doing per th= e charter).

* TI= DYAuth =C2=A0 =C2=A0Trust via Intent Driven Yield Auth
I actually really like the acronym but t= he expansion is super awkward. What is being yielded here?

* = TIEAuth =C2=A0 =C2=A0Trust via Intent Extension Auth
What is =E2=80=9Cintent extension=E2=80= =9D?=C2=A0
As above,= it sounds like an extension not a protocol.

* TINOA =C2=A0 T= his Is Not OAuth
Thi= s says nothing about what this work is, only what it isn=E2=80=99t. And on = that regard,=C2=A0it doesn=E2=80=99t matter that this isn=E2=80=99t OAuth. = OAuth 2 isn=E2=80=99t OAuth 1, either.=C2=A0
And given that ease of transition from OAuth 2 is = part of the charter, this isn=E2=80=99t a helpful distinction.
* TXAuth =C2=A0 =C2=A0Testable eXtensible Authorization
I don=E2=80=99t get the focus on =E2= =80=9Ctestable=E2=80=9D in the name. Testable in what way? Can other protoc= ols not be tested?
Extensibility is not a differentiating feature of this work.
=
* TXAuth =C2=A0 =C2=A0 =C2=A0Truly eXtensible Authorization
Extensibility is not a diff= erentiating feature of this work.
What makes something =E2=80=9Ctruly extensible=E2=80=9D as op= posed to =E2=80=9Cnot truly extensible=E2=80=9D?

* XAut= hZ =C2=A0 =C2=A0eXtensible authoriZation protocol
Extensibility is not a differentiating fe= ature of this work.
= The acronym is just pulling random letters from the middle of words in the = expansion to try to work.
<= /span>Same comment as above focus on Authorization.
Same comment as above about Zed/Zee confu= sion.

* WRAC =C2=A0 =C2=A0 Web Resource Access Co= llaboration
This is = not a collaboration protocol or system. Collaboration, within computer scie= nce, is established to refer to when two or more :people: work and communic= ate together. This protocol does not facilitate human communication, and so= the use of this term is not appropriate here.=C2=A0
This is very close to=C2=A0=E2=80=9Cwrack= =E2=80=9D which is a common enough English verb, as in =E2=80=9Cwracked ner= ves=E2=80=9D or =E2=80=9Cto wrack one=E2=80=99s brain=E2=80=9D, which deriv= es from the medieval torture process of stretching someone over a rack. Thi= s=C2=A0

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000087111805a7210513-- From nobody Tue Jun 2 14:59:24 2020 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 ECDB33A1065 for ; Tue, 2 Jun 2020 14:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 s6iXlDJg2uk0 for ; Tue, 2 Jun 2020 14:59:16 -0700 (PDT) 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 1CD1D3A103C for ; Tue, 2 Jun 2020 14:59:16 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id m18so164677ljo.5 for ; Tue, 02 Jun 2020 14:59:15 -0700 (PDT) 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; bh=K7EsBoUymzMHmFAAW4PzvtUgFNEdGG/U7tQKO0boMKE=; b=GEEKqaGYmxSWMtzFO+jiHiND9Qq6E51frQpZ+AnYXCLynQ2Kzi1KLHJIeO9Y8Gn0xO P/elj6xxq/35sxCUTO56EVKxNw+d8BWDrkAoj8uNTkdxetwYzOt9CL3i17Ae04bqTz3m q+AUUDXY+ND4MroilUkkyz1I2LH0A/BsuT66vCjNLml7Z1Tb/Lc76xDZ9ULA7jEmJcrV fgtulrKx0tsT62HMVa1dv3yXjfCYN4APsowvfS65CCjMSw7Y7MXaORjLsZK3ZvdgvJ30 okGqfYEzElAMYfIumvDsh2ja1AfaIffkXJ6IMcPArMxj40l3ImfMkFZUrSUz6JwJL2iv YuIw== 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; bh=K7EsBoUymzMHmFAAW4PzvtUgFNEdGG/U7tQKO0boMKE=; b=KhIDNSr0m6f2/CarvWuYfbnSoSQPbrp4gcS+yfVq2NR4WglH7jQ6jda1awR6ByP+dn pLnjQ8hlWzW4NqoDRhOll4Bhh9lGRsAXXLz43SkQieTgPPFWeB/1fjSoXtgH411tSZqY CW7YL+SQJ0fym2OwN3K3rlCeSGZhjSUYX0LHrS5hwlVczde2vJqUdEGWy0iAQXHHmA+E t+VMDrIbbVlh4v8ZHGEUMHZDlumnz/jiVgzgxBPq+p+/t1mHySH3sBC8+fwoQmktiTVC QXw2sIhDMyfUSexmD3UYjxeNbUdgoqq0ElKOmsIKf0/8bDdvAAd4sXCDxVHbPcr7tTno 1iXw== X-Gm-Message-State: AOAM532DBF1nif9luMcOh3Nr5QcmrvN2I30ojWRP2KgU5fdVAczuorCh stRLkBGh4+MXbsIX8XUjqDtSaYTnRYLWbFL1W6TZEA+FtKs= X-Google-Smtp-Source: ABdhPJy0C86ZLANmtZxqm+x+eJIE8Zab0VZrCQi3XdsFOpr7j7hPJu0yxyzMvVYioDpIDG0tMAtzLZFxzlE2hjqGb24= X-Received: by 2002:a2e:9641:: with SMTP id z1mr497996ljh.215.1591135143614; Tue, 02 Jun 2020 14:59:03 -0700 (PDT) MIME-Version: 1.0 References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> In-Reply-To: <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> From: Dick Hardt Date: Tue, 2 Jun 2020 14:58:37 -0700 Message-ID: To: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000065d3205a72105d7" Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 02 Jun 2020 21:59:24 -0000 --000000000000065d3205a72105d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was waiting for others to post before I posted, but I'll post now to get some more conversation going ... *Would not Object* * GNAP Grant Negotiation and Authorization Protocol - This one is my favorite as it captures what is being the protocol does. In the OAuth 2.0 and OpenID Connect specifications, the user and authorization server "grant" something. Using "grant" as a noun covers both access tokens and user identifiers and claims, which are all part of the charter[1]. Negotiation is a new feature of this work and covers client / AS negotiation and client / RO negotiation. [1] https://datatracker.ietf.org/wg/txauth/about/ proposed charter introduction sentence, "This group is chartered to develop a fine-grained delegation protocol for authorization and API access, as well as requesting and providing user identifiers and claims.", wrt. pronounciation, it could be gee-nap, guh-nap, or nap (as in gnaw) -- while not ideal, we can teach everyone the pronunciation as was done with OAuth (which could be pronounced oath rather than o-auth) * PAuthZ Protocol for Authorization * GranPro GRAnt Negotiation Protocol - not as good as GNAP, but no objection as they are correct in what is happening * XAuthZ eXtensible authoriZation protocol Extensibility was not a focus in OAuth 2.0, in contrast to the proposed charter which explicitly includes extensibility in the work and milestones: 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 - Mechanisms for conveying user, software, organization, and other pieces of information used in authorization decisions - Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys - Optimized inclusion of additional information through the delegation process (including identifiers and identity assertions) Milestones to include: - Guidelines for use of protocol extension points * TXAuth Testable eXtensible Authorization * TXAuth Truly eXtensible Authorization - not as good as XAuthZ as the confusion of AuthZ and AuthN is clarified in XAuthZ, and Testable and Truly are distracting, but create backronyms for "txauth". *Would Object* * AAuthZ Alternative Authorization Protocol (AAuthZ) * TINOA This Is Not OAuth * RefAuthZ Refactored Authorization Protocol * ReAuthZ Reimagined Authorization Protocol - these names are descriptive of what work is not rather than what it is * BYOAuthZ Build-Your-Own Authorization Protocol * DIYAuthZ Do-It-Yourself Authorization Protocol - these names make it sound like a hobby and not professional * AZARP AuthoriZed Access to Resources Protocol * AZARAP AuthoriZation And Resource Access Protocol * DAZARAP Delegated AuthoriZation And Resource Access Protocol - these names focus on the resource, and ignore the identity aspect of the work * BeBAuthZ Back-end Based Authorization Protocol - back-end based is a confusing adjective. Could be interpreted to mean that it is all back channel authorization, which is not correct. * CPAAP Comprehensive Privileged Authentication Authorization Protocol - similar to BeBAuthZ, "Comprehensive" and "Privileged" imply something other than what is happening - authentication is not in the charter scope * TIAAP Tokenized Identity and Access Protocol - Not all the identity in this work is tokenized. * NIRAD Negotiation of Intent Registration and Authority Delegation * IDPAuthZ Intent Driven Protocol for Authorization * TIDEAuth Trust via Intent Driven Extension Auth * TIDYAuth Trust via Intent Driven Yield Auth * TIEAuth Trust via Intent Extension Auth - All of these use intent in the description. I don't see how Intent is a descriptive adjective. The word "intent" is not in the charter anywhere. * TxAuth Transmission of Authority - I think this name is misleading. As it is Justin's favorite, I'll elaborate more than I have on the others ... starting with definitions of the words: Transmission: the action or process of transmitting something or the state of being transmitted. "the transmission of the virus" Transmit: cause (something) to pass on from one place or person to another. Authority: a power or right delegated or given; authorization: "Who has the authority to grant permission?" Authorization: the act of authorizing. permission or power granted by an authority; sanction. Building on these definitions, "Transmission of Authority" means passing a power to another person. The power is the ability to authorize. Someone familiar with a certificate authority (CA), a related area, "transmission of authority" could mean the CA passing authority to another entity, which would then be another CA. Using OAuth terms, the AS has the authority to issue tokens to the client. The AS is not passing the authority to issue tokens to the client. - =E1=90=A7 On Fri, May 22, 2020 at 3:32 AM Yaron Sheffer wrote= : > Thank you David for pointing out the loophole in my previous mail. As a > result, we have decided to limit the time when new names may be proposed. > If you have new name ideas, please make sure to share them until 0800 UTC= , > Tuesday, May 26. > > All others, if you want to make sure you are commenting on the full name > list, please hold off until after Monday. > > Apologies for the process confusion, we are building it as we go. > > Thanks, > Yaron > > =EF=BB=BFOn 5/21/20, 11:53, "Yaron Sheffer" wrote= : > > Thank you to those who contributed early replies! > > As a refinement/clarification to the process below: we are now > focusing on discussion and making sure there are no strong objections, > rather than voting on people's favorite name. > > With that in mind, we strongly encourage people to attach an > explanation to each name they object to. Therefore for names that are on > neither of your lists ("wouldn't object to" and "object to"), our default > assumption is that you would NOT object to them. > > With the process now finalized, please take a few minutes and provide > us with your name lists. As a reminder, the deadline is 0800 UTC June 4, > 2020. > > Thanks, > Yaron > > > =EF=BB=BFOn 5/19/20, 23:34, "Yaron Sheffer" w= rote: > > Hi! > > After reviewing the community feedback and discussions with the > AD, we=E2=80=99d like to again launch a process to elicit feedback on nam= ing. Our > proposal is below. We=E2=80=99d appreciate any clarifying questions, pro= posed > improvements or objections by 0800 UTC, Thursday, May 21st . > > Thanks, > Yaron and Dick > > PS, I=E2=80=99m sharing the load with Dick and taking point on th= is > consensus call -- Yaron > > ---- > > Before we submit the draft charter [1] to the IESG, we wanted to > explore the name of the group. During the chartering discussions, some > people objected to the BoF name being the WG name. We=E2=80=99d like to = get > consensus on what the WG name should be. Our first attempt to elicit inp= ut > [2] wasn=E2=80=99t successful, and this is a second attempt to get consen= sus from > the community. > > To get to consensus, we want to gather preferences on the > currently known WG name candidates. Our goal is not to select the most > popular name -- it is to select a name everyone can live with and ensure > that we understand and weigh any objections there might be with that > choice. To that end, we=E2=80=99d like to elicit your name preferences i= n the > following way: > > (1) In previous discussions, the following candidate names have > been voiced (we have listed only these names that received at least one > vote previously): > > * AAuthZ Alternative Authorization Protocol (AAuthZ) > * AZARP AuthoriZed Access to Resources Protocol > * AZARAP AuthoriZation And Resource Access Protocol > * BeBAuthZ Back-end Based Authorization Protocol > * BYOAuthZ Build-Your-Own Authorization Protocol > * CPAAP Comprehensive Privileged Authentication Authorization > Protocol > * DAZARAP Delegated AuthoriZation And Resource Access Protocol > * DIYAuthZ Do-It-Yourself Authorization Protocol > * GNAP Grant Negotiation and Authorization Protocol > * GranPro GRAnt Negotiation Protocol > * IDPAuthZ Intent Driven Protocol for Authorization > * NIRAD Negotiation of Intent Registration and Authority > Delegation > * PAuthZ Protocol for Authorization > * RefAuthZ Refactored Authorization Protocol > * ReAuthZ Reimagined Authorization Protocol > * TIAAP Tokenized Identity and Access Protocol > * TIDEAuth Trust via Intent Driven Extension Auth > * TIDYAuth Trust via Intent Driven Yield Auth > * TIEAuth Trust via Intent Extension Auth > * TINOA This Is Not OAuth > * TXAuth Testable eXtensible Authorization > * TxAuth Transmission of Authority > * TXAuth Truly eXtensible Authorization > * XAuthZ eXtensible authoriZation protocol > > We would ask that you consider these names, and respond to the > list with your selection of the following two categories: > > * =E2=80=9CWouldn=E2=80=99t Object=E2=80=9D -- this is not necess= arily your preferred > name, but you would be comfortable with it being the name of the WG (choo= se > as many names as you want) > * =E2=80=9CObject=E2=80=9D -- you would be uncomfortable with the= WG being named > in this way (choose as many names as you want; please provide an > explanation) > > (2) If your preferred name isn=E2=80=99t in the list per (1), you= can send > a note to the mailing list stating that you=E2=80=99d like the WG to cons= ider a new > name. Please ensure the name adheres to the previously discussed naming > criteria at [3]. We still request that you provide your other preferences > and objections. > > (3) If you previously sent in your preferences, but a new name > suggestion or someone=E2=80=99s objection changed your mind, then send an= other > message to the mailing list with your revised preferences. For the > purposes of consensus, we=E2=80=99ll assume that everyone who hasn=E2=80= =99t commented on a > new name introduced per (2) =E2=80=9Cobjects=E2=80=9D to it (i.e., we wan= t to hear positive > confirmation of preference on new names). > > (4) Please provide your input by 0800 UTC June 4, 2020. > > With that input, our plan is to assess rough consensus in the > following way: > > (a) See if there is consensus for a name identified given the > =E2=80=9Cwouldn=E2=80=99t object to being the WG name=E2=80=9D preference= and the level of =E2=80=9Cwould > object=E2=80=9D feedback > > (b) If there isn=E2=80=99t clear consensus with (a), but a signif= icantly > reduced set of candidates around which there is enthusiasm, the chairs wi= ll > share the results and request feedback > > (c) If rough consensus appears to be reached through steps (a) = =E2=80=93 > (b), revisit the objections to this candidate name, elicit additional > objections and see if they change the consensus. > > Regards, > Yaron and Dick > > [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/ > [2] > https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg/ > [3] > https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/ > > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000065d3205a72105d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was waiting for others to post before I posted, but= I'll post now to get some more conversation going ...=C2=A0
=
Would not Object

* GNAP =C2=A0 =C2=A0Grant Negotiation an= d Authorization Protocol

- This one is my favorite as it captures wh= at is being the protocol does. In the OAuth 2.0 and OpenID Connect specific= ations, the user and authorization server "grant" something.
= Using "grant" as a noun covers both access tokens and user identi= fiers and claims, which are all part of the charter[1].
Negotiation is a= new feature of this work and covers client / AS negotiation and client / R= O negotiation.


[1] https://datatracker.ietf.org/wg/txauth/about/ proposed ch= arter introduction sentence, "This group is chartered to develop a fin= e-grained delegation protocol for authorization and API access, as well as = requesting and providing user identifiers and claims.",

wrt. p= ronounciation, it could be gee-nap, guh-nap, or nap (as in gnaw) -- while n= ot ideal, we can teach everyone the pronunciation as was done with OAuth (w= hich could be pronounced oath rather than o-auth)


* PAuthZ =C2= =A0 =C2=A0Protocol for Authorization
* GranPro =C2=A0 =C2=A0GRAnt Negoti= ation Protocol

- not as good as GNAP, but no objection as they are c= orrect in what is happening

* XAuthZ =C2=A0 =C2=A0eXtensible authori= Zation protocol

Extensibility was not a focus in OAuth 2.0, in contr= ast to the proposed charter which explicitly includes extensibility in the = work and milestones:

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

- Cryptograph= ic agility for keys, message signatures, and proof of possession
- User = interaction mechanisms including web and non-web methods
- Mechanisms fo= r conveying user, software, organization, and other pieces of information u= sed in authorization decisions
- Mechanisms for presenting tokens to res= ource servers and binding resource requests to tokens and associated crypto= graphic keys
- Optimized inclusion of additional information through the= delegation process (including identifiers and identity assertions)

= Milestones to include:
<snip>
- Guidelines for use of protocol = extension points

* TXAuth =C2=A0 =C2=A0Testable eXtensible Authoriza= tion
* TXAuth =C2=A0 =C2=A0 =C2=A0Truly eXtensible Authorization

= - not as good as XAuthZ as the confusion of AuthZ and AuthN is clarified in= XAuthZ, and Testable and Truly are distracting, but create backronyms for = "txauth".

Would Object

* AAuthZ =C2=A0 =C2= =A0Alternative Authorization Protocol (AAuthZ)
* TINOA =C2=A0 This Is No= t OAuth
* RefAuthZ =C2=A0 =C2=A0Refactored Authorization Protocol
* R= eAuthZ =C2=A0 =C2=A0Reimagined Authorization Protocol

- these names = are descriptive of what work is not rather than what it is

* BYOAuth= Z =C2=A0 =C2=A0Build-Your-Own Authorization Protocol
* DIYAuthZ =C2=A0 = =C2=A0Do-It-Yourself Authorization Protocol

- these names make it so= und like a hobby and not professional


* AZARP =C2=A0 =C2=A0Autho= riZed Access to Resources Protocol
* AZARAP =C2=A0 =C2=A0AuthoriZation A= nd Resource Access Protocol
* DAZARAP =C2=A0 =C2=A0Delegated AuthoriZati= on And Resource Access Protocol

- these names focus on the resource,= and ignore the identity aspect of the work

* BeBAuthZ =C2=A0 =C2=A0= Back-end Based Authorization Protocol

- back-end based is a confusin= g adjective. Could be interpreted to mean that it is all back channel autho= rization, which is not correct.

* CPAAP =C2=A0 =C2=A0Comprehensive P= rivileged Authentication Authorization Protocol

- similar to BeBAuth= Z, "Comprehensive" and "Privileged" imply something oth= er than what is happening
- authentication is not in the charter scope
* TIAAP =C2=A0 =C2=A0Tokenized Identity and Access Protocol

- = Not all the identity in this work is tokenized.

* NIRAD =C2=A0 =C2= =A0Negotiation of Intent Registration and Authority Delegation
* IDPAuth= Z =C2=A0 =C2=A0Intent Driven Protocol for Authorization
* TIDEAuth =C2= =A0 =C2=A0Trust via Intent Driven Extension Auth
* TIDYAuth =C2=A0 =C2= =A0Trust via Intent Driven Yield Auth
* TIEAuth =C2=A0 =C2=A0Trust via I= ntent Extension Auth

- All of these use intent in the description. I= don't see how Intent is a descriptive adjective. The word "intent= " is not in the charter anywhere.


* TxAuth =C2=A0 =C2=A0 = =C2=A0Transmission of Authority

- I think this name is misleading. A= s it is Justin's favorite, I'll elaborate more than I have on the o= thers ... starting with definitions of the words:

Transmission:
= the action or process of transmitting something or the state of being trans= mitted. "the transmission of the virus"

Transmit:
caus= e (something) to pass on from one place or person to another.

Author= ity:
a power or right delegated or given; authorization: "Who has t= he authority to grant permission?"

Authorization:
the act of= authorizing. permission or power granted by an authority; sanction.
Building on these=C2=A0definitions, "Transmission of Authority" = means passing a power to another person. The power is the ability to author= ize.=C2=A0

Someone familiar with a certificate aut= hority (CA), a related area, "transmission of authority" could me= an the CA passing authority to another entity, which would then be another = CA.

Using OAuth terms, the AS has the authority to issue tokens to = the client. The AS is not passing the authority to issue tokens to the clie= nt.





    • <= /ul>


3D""=E1=90= =A7

On Fri, May 22, 2020 at 3:32 AM Yaron Sheffer <yaronf.ietf@gmail.com> w= rote:
Thank you = David for pointing out the loophole in my previous mail. As a result, we ha= ve decided to limit the time when new names may be proposed. If you have ne= w name ideas, please make sure to share them until 0800 UTC, Tuesday, May 2= 6.

All others, if you want to make sure you are commenting on the full name li= st, please hold off until after Monday.

Apologies for the process confusion, we are building it as we go.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

=EF=BB=BFOn 5/21/20, 11:53, "Yaron Sheffer" <yaronf.ietf@gmail.com> wro= te:

=C2=A0 =C2=A0 Thank you to those who contributed early replies!

=C2=A0 =C2=A0 As a refinement/clarification to the process below: we are no= w focusing on discussion and making sure there are no strong objections, ra= ther than voting on people's favorite name.

=C2=A0 =C2=A0 With that in mind, we strongly encourage people to attach an = explanation to each name they object to. Therefore for names that are on ne= ither of your lists ("wouldn't object to" and "object to= "), our default assumption is that you would NOT object to them.

=C2=A0 =C2=A0 With the process now finalized, please take a few minutes and= provide us with your name lists. As a reminder, the deadline is 0800 UTC J= une 4, 2020.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


=C2=A0 =C2=A0 =EF=BB=BFOn 5/19/20, 23:34, "Yaron Sheffer" <yaronf.ietf@gmail.c= om> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 After reviewing the community feedback and disc= ussions with the AD, we=E2=80=99d like to again launch a process to elicit = feedback on naming.=C2=A0 Our proposal is below.=C2=A0 We=E2=80=99d appreci= ate any clarifying questions, proposed improvements or objections by 0800 U= TC, Thursday, May 21st .

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron and Dick=C2= =A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 PS, I=E2=80=99m sharing the load with Dick and = taking point on this consensus call -- Yaron

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Before we submit the draft charter [1] to the I= ESG, we wanted to explore the name of the group. During the chartering disc= ussions, some people objected to the BoF name being the WG name.=C2=A0 We= =E2=80=99d like to get consensus on what the WG name should be.=C2=A0 Our f= irst attempt to elicit input [2] wasn=E2=80=99t successful, and this is a s= econd attempt to get consensus from the community.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 To get to consensus, we want to gather preferen= ces on the currently known WG name candidates. Our goal is not to select th= e most popular name -- it is to select a name everyone can live with and en= sure that we understand and weigh any objections there might be with that c= hoice.=C2=A0 To that end, we=E2=80=99d like to elicit your name preferences= in the following way:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(1) In previous discussions, the followin= g candidate names have been voiced (we have listed only these names that re= ceived at least one vote previously):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 * AAuthZ=C2=A0 =C2=A0 Alternative Authorization= Protocol (AAuthZ)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * AZARP=C2=A0 =C2=A0 AuthoriZed Access to Resou= rces Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * AZARAP=C2=A0 =C2=A0 AuthoriZation And Resourc= e Access Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * BeBAuthZ=C2=A0 =C2=A0 Back-end Based Authoriz= ation Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * BYOAuthZ=C2=A0 =C2=A0 Build-Your-Own Authoriz= ation Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * CPAAP=C2=A0 =C2=A0 Comprehensive Privileged A= uthentication Authorization Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * DAZARAP=C2=A0 =C2=A0 Delegated AuthoriZation = And Resource Access Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * DIYAuthZ=C2=A0 =C2=A0 Do-It-Yourself Authoriz= ation Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * GNAP=C2=A0 =C2=A0 Grant Negotiation and Autho= rization Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * GranPro=C2=A0 =C2=A0 GRAnt Negotiation Protoc= ol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * IDPAuthZ=C2=A0 =C2=A0 Intent Driven Protocol = for Authorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * NIRAD=C2=A0 =C2=A0 Negotiation of Intent Regi= stration and Authority Delegation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * PAuthZ=C2=A0 =C2=A0 Protocol for Authorizatio= n
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * RefAuthZ=C2=A0 =C2=A0 Refactored Authorizatio= n Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * ReAuthZ=C2=A0 =C2=A0 Reimagined Authorization= Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TIAAP=C2=A0 =C2=A0 Tokenized Identity and Acc= ess Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TIDEAuth=C2=A0 =C2=A0 Trust via Intent Driven= Extension Auth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TIDYAuth=C2=A0 =C2=A0 Trust via Intent Driven= Yield Auth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TIEAuth=C2=A0 =C2=A0 Trust via Intent Extensi= on Auth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TINOA=C2=A0 =C2=A0This Is Not OAuth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TXAuth=C2=A0 =C2=A0 Testable eXtensible Autho= rization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TxAuth=C2=A0 =C2=A0 =C2=A0 Transmission of Au= thority
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TXAuth=C2=A0 =C2=A0 =C2=A0 Truly eXtensible A= uthorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * XAuthZ=C2=A0 =C2=A0 eXtensible authoriZation = protocol

=C2=A0 =C2=A0 =C2=A0 =C2=A0 We would ask that you consider these names, and= respond to the list with your selection of the following two categories:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =E2=80=9CWouldn=E2=80=99t Object=E2=80=9D -- = this is not necessarily your preferred name, but you would be comfortable w= ith it being the name of the WG (choose as many names as you want)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =E2=80=9CObject=E2=80=9D -- you would be unco= mfortable with the WG being named in this way (choose as many names as you = want; please provide an explanation)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (2) If your preferred name isn=E2=80=99t in the= list per (1), you can send a note to the mailing list stating that you=E2= =80=99d like the WG to consider a new name.=C2=A0 Please ensure the name ad= heres to the previously discussed naming criteria at [3]. We still request = that you provide your other preferences and objections.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (3) If you previously sent in your preferences,= but a new name suggestion or someone=E2=80=99s objection changed your mind= , then send another message to the mailing list with your revised preferenc= es.=C2=A0 For the purposes of consensus, we=E2=80=99ll assume that everyone= who hasn=E2=80=99t commented on a new name introduced per (2) =E2=80=9Cobj= ects=E2=80=9D to it (i.e., we want to hear positive confirmation of prefere= nce on new names).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (4) Please provide your input by 0800 UTC June = 4, 2020.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 With that input, our plan is to assess rough co= nsensus in the following way:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (a) See if there is consensus for a name identi= fied given the =E2=80=9Cwouldn=E2=80=99t object to being the WG name=E2=80= =9D preference and the level of =E2=80=9Cwould object=E2=80=9D feedback

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (b) If there isn=E2=80=99t clear consensus with= (a), but a significantly reduced set of candidates around which there is e= nthusiasm, the chairs will share the results and request feedback

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (c) If rough consensus appears to be reached th= rough steps (a) =E2=80=93 (b), revisit the objections to this candidate nam= e, elicit additional objections and see if they change the consensus.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron and Dick

=C2=A0 =C2=A0 =C2=A0 =C2=A0 [1] https://datatra= cker.ietf.org/doc/charter-ietf-txauth/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [2] https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0= Wg/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [3] https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnU= a8/




--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000065d3205a72105d7-- From nobody Wed Jun 3 04:57:35 2020 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 68CFF3A106E for ; Wed, 3 Jun 2020 04:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 FjuwK6X6_Q_j for ; Wed, 3 Jun 2020 04:57:32 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 4BBC83A106D for ; Wed, 3 Jun 2020 04:57:32 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id h4so1868513iob.10 for ; Wed, 03 Jun 2020 04:57:32 -0700 (PDT) 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=IeIYv8eY20wUUpgKmQIuIjCIsER26BluxdAM8SmQC2E=; b=mlJR2eoV642I3poNQw5AcJK1cjSjWse7+STaOOj1TJQtSAgXKSnfn8iafIFcGQJvkh V7+eqecmmjD1NrMQitKQk/CSUpQhCjA8lD4qoEdE0B/lDO+0NMOJx5ZAkfffLmI5XMLQ kKq3P8iKTKG61yDCGeKRlE0riFP3gOUWcdDt/nQ2xvv/fY2n+wL2a70peKtSHgzrLqLv D1oIg93rwXDrXDGingAAitYjulvNWh6ZQLvcb42sn2BCR4lOdubhgBT3eBfpZIoI5LtN tOIReesDe2DzXXBB3+oGMnG5W63OFX9OKO0tYRTddakSbvuq5y6f1LHfJfMjQgIAeYuy r5iw== 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=IeIYv8eY20wUUpgKmQIuIjCIsER26BluxdAM8SmQC2E=; b=BDZuzvCg9HRs/Z5cHQ7y+KPPrlQ1X/zYcUhMBw8iDS52o9zrPrAmdkWGr4mQr+6+UD HHr7VMgZ6MPhJ2/6NKHlcCSca163jPmc6prg7K8uYsPZJCvL2ulFD1Rpl5jk9GQlTOVF wQ/AbdvNAxWYNN8xWiMVBjnlzL8HXPqVmSbcSeiXcVCjZ3sTXWbu2QAumkw3/CwGLr// TZu4GfTT3jnvC8fqm9LIm+L16v+PrVPAZWsuD1ZUss2Lt8H69jrbI4aufwdPhMI5aod0 GCjUjgr16KRJy0apWOYbWGT8ATfZqYeSKCRtQdFK+3YX9OLF02gSlZcI7lsVoBd74i4k 47Yw== X-Gm-Message-State: AOAM532SjSwMAAurHmAQTzZiWl9CPn698zFW9auyqzBLwAEVlWCJoRD8 nk8ULlVQdnhI4gjT8r9SbQSDH/iKbvLitrW0DnfXI5My4jg= X-Google-Smtp-Source: ABdhPJwgZGDQ+KMdtEy2toYDapQHESV1haiC4KFRfjhWMcUrgwZeVUya/yUvfwnsq/+LqR3frXcd853n5fyePHHMS7U= X-Received: by 2002:a02:1a08:: with SMTP id 8mr28082213jai.124.1591185451239; Wed, 03 Jun 2020 04:57:31 -0700 (PDT) MIME-Version: 1.0 From: Fabien Imbault Date: Wed, 3 Jun 2020 13:57:20 +0200 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000097d0aa05a72cbb8a" Archived-At: Subject: [Txauth] Call for WG name preferences - process clarification 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, 03 Jun 2020 11:57:33 -0000 --00000000000097d0aa05a72cbb8a Content-Type: text/plain; charset="UTF-8" Dear all, A quick personal feedback on the "TxAuth - Transmission of Authority", following Dick's comment. I previously agreed that transaction may be incorrectly understood in an IT context, due to its widespread use in database engineering. I however disagree with the interpretation that "transmission" would mean that the AS would be passing the authority to issue tokens to the client, except maybe if the token itself allows for delegation (but that's a really uncommon case, since JWT doesn't allow that, so I don't think people would even think of it). Since I'm not the creator of the acronym, I believe it simply means you're passing to the client the authority borne by the token, so that the client can make a call on behalf of the user. I don't see where there could be ambiguity and it does fit pretty well with the scope of work. One drawback is whether users would actually remember tx means transmission (instead of transaction), which seems perhaps a bit far stretched and results from our previous internal discussions. As far as I'm concerned, I still think it's one of the best available proposition (alongside GATAR which came after my "would object"/"wouldn't object" comments). What are the next steps after today's deadline ? Fabien --00000000000097d0aa05a72cbb8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

A quick personal=C2=A0f= eedback=C2=A0on the "TxAuth - Transmission of Authority", followi= ng Dick's comment.=C2=A0

I previously agreed t= hat transaction may be incorrectly=C2=A0understood in an IT context,=C2=A0d= ue to its widespread use in database engineering.

= I however disagree with the interpretation that "transmission" wo= uld mean that the AS would be=C2=A0passing the authority to issue tokens to= the client,=C2=A0except maybe if the token itself allows for delegation (b= ut that's a really uncommon=C2=A0case, since JWT doesn't allow that= , so I don't think people would even think of it).=C2=A0
Sinc= e I'm not the creator of the acronym, I=C2=A0believe it simply means yo= u're passing to the client the authority borne by the token,=C2=A0so th= at the client can make a call on behalf of the user. I don't see where = there could be ambiguity and it does fit pretty well with the scope of work= .

One drawback is whether users would actually rem= ember tx means transmission (instead of transaction), which seems perhaps a= bit far stretched and results from our previous internal discussions.=C2= =A0=C2=A0

As far as I'm concerned, I still thi= nk it's one of the best available proposition (alongside GATAR which ca= me after my "would object"/"wouldn't object" commen= ts).=C2=A0

What are the next steps after today'= ;s deadline ?

Fabien
--00000000000097d0aa05a72cbb8a-- From nobody Wed Jun 3 05:19:19 2020 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 BC63A3A1080 for ; Wed, 3 Jun 2020 05:19:17 -0700 (PDT) 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 F-65m4AAjo6a for ; Wed, 3 Jun 2020 05:19:12 -0700 (PDT) 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 EC6D43A108F for ; Wed, 3 Jun 2020 05:19:11 -0700 (PDT) Received: from [192.168.1.12] (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 053CJ7HN017515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Jun 2020 08:19:07 -0400 From: Justin Richer Message-Id: <3E18041D-DDF1-4DFD-ACA2-8C37E46495D7@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_F341B5CE-2728-4793-A998-7076F9A6EF26" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 3 Jun 2020 08:19:07 -0400 In-Reply-To: Cc: "txauth@ietf.org" To: Dick Hardt References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 03 Jun 2020 12:19:18 -0000 --Apple-Mail=_F341B5CE-2728-4793-A998-7076F9A6EF26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dick, Yes, I am pretty familiar with the charter text, but thank you for = posting it to the group as a reminder. The original charter text for the OAuth WG[1] does in fact call out = extensibility explicitly in several places, including: The Working Group will produce one or more documents suitable for consideration as Proposed Standard that will: ... * Provide guidelines for extensibility. The difference here is that we=E2=80=99re being more explicit about what = is extensible and how, in the charter. But one of the biggest = innovations in OAuth 2, as I=E2=80=99m sure you know, is that it allowed = for explicit extensibility in ways that OAuth 1 did not: grant types, = token types, scopes (and therefore resource types), client auth types = (and therefore client types), etc. The very fact that OAuth 2 is a = *framework* fundamentally speaks to its goals of extensibility.=20 The TxAuth charter text that you quoted carries much of that tradition = forward, which is why I said that extensibility is not a :defining: = feature of this work. It=E2=80=99s absolutely a feature and an important = one, but extensibility itself is hardly new or unique as a goal. = What=E2=80=99s unique is :what: we=E2=80=99re targeting for = extensibility points, which is why those are listed below in the = proposed charter text. I also worry that a focus on =E2=80=98extensibility=E2=80=99 above all = else will slide us back into the world of incompatible framework pieces. = As the proposed charter also states that we=E2=80=99re building a = protocol, not a framework, this is counter to what we=E2=80=99re coming = together for. =E2=80=94 Justin [1] = https://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2009-05-13.t= xt > On Jun 2, 2020, at 5:58 PM, Dick Hardt wrote: >=20 > Hey Justin, >=20 > Per your comment "Extensibility is not a differentiating feature of = this work.", extensibility is explicitly called out in the charter (and = is not in the OAuth WG charter): >=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 > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation = process (including identifiers and identity assertions) >=20 > Milestones to include: > > - Guidelines for use of protocol extension points >=20 > [1] https://datatracker.ietf.org/wg/txauth/about/ = > =E1=90=A7 >=20 > On Thu, May 28, 2020 at 2:47 PM Justin Richer > wrote: > Thanks to everyone in the community for suggesting names, and thanks = to the chairs for putting this list together. >=20 > Here=E2=80=99s my personal take on the candidates. >=20 >=20 >=20 > Wouldn=E2=80=99t Object: >=20 > * TxAuth Transmission of Authority > This is my personal favorite of the lot because it avoids the = =E2=80=9Cauthorization/authentication=E2=80=9D question and gets at the = heart of what this protocol does: delegation, which is to say, = transmitting the authority to do something from one party to another. = That delegation allows for authorized access to resources, but can also = allow different rights to flow as needed. Additionally, =E2=80=9Ctx=E2=80=9D= has long been used to stand for =E2=80=9Ctransmission=E2=80=9D in = computer science and networking. >=20 > * AZARP AuthoriZed Access to Resources Protocol > The use of =E2=80=9CAZ=E2=80=9D to stand for =E2=80=9Cauthorized=E2= =80=9D is awkward, but the pronunciation kinda works as something = memorable. The expansion is a twist of words to make it fit, and I like = that less. > Resource access is only part of the story, but it=E2=80=99s an = important part. This leaves out what we want to do around = non-authorization cases (like identity conveyance). >=20 > * AZARAP AuthoriZation And Resource Access Protocol > I like the expansion here more than the one for AZARP but I like = the acronym less with the additional =E2=80=9CA=E2=80=9D. > Same comment as above for AZ standing for Authorization. > Same comment as above for resource access. >=20 > * DAZARAP Delegated AuthoriZation And Resource Access Protocol > I like the expansion here, but the acronym is awkward and weak.=20= > Same comment as above for AZ standing for Authorized. > Same comment as above for resource access. >=20 > * GNAP Grant Negotiation and Authorization Protocol > This is ok, but it has a couple downsides. The pronunciation of = a hard =E2=80=9Cg=E2=80=9D or not is going to potentially be confusing, = as is the fact that it looks like it=E2=80=99s part of the GNU project = because of that. > The term =E2=80=9CGrant=E2=80=9D is one of the more confusing = things that was introduced in OAuth 2, and while it=E2=80=99s = established in the lexicon today, I=E2=80=99ve yet to meet many = engineering teams that actually know what a =E2=80=9Cgrant=E2=80=9D is. = Most think it=E2=80=99s another name for the authorization code. > Also it means =E2=80=9Cto bite=E2=80=9D, which may or may not be = desirable. >=20 > * NIRAD Negotiation of Intent Registration and Authority Delegation > This is a somewhat weak construct, but it mostly works. It = spells out more what the protocol will do (if we go with the currently = proposed solution designs) than what it solves, but that might be ok. > It makes me think of NORAD (a positive, they do weather radar = and track Santa Claus each year), but also =E2=80=9Cnimrod=E2=80=9D, a = pejorative term. And before anyone chimes in with =E2=80=9CBut Nimrod = was a mighty hunter of ancient times=E2=80=9D, it doesn=E2=80=99t mean = that to any modern listener. >=20 > * GATAR Grant Authorization To Access Resources=20 > This one isn=E2=80=99t bad, and I can appreciate the = =E2=80=9Cguitar=E2=80=9D pronunciation and imagery. As above, resource = access isonly part of the story. > Same comment about =E2=80=9CGrant=E2=80=9D as above in GNAP. >=20 >=20 >=20 > Object: >=20 > * AAuthZ Alternative Authorization Protocol (AAuthZ) > It=E2=80=99s an alternative to what, exactly? And what happens = when someone makes an alternative to it? > The focus on =E2=80=9CAuthorization=E2=80=9D as a core part of = the name tells only part of the story.=20 > Assuming the =E2=80=9CZ=E2=80=9D is pronounced as its letter = name (which is implied by the capitalization), there=E2=80=99s an issue = with pronouncing the final =E2=80=9CZ=E2=80=9D as either =E2=80=9CZee=E2=80= =9D or =E2=80=9CZed=E2=80=9D depending on dialect. If it=E2=80=99s not = pronounced as a letter, it=E2=80=99s really difficult to say the = consonants =E2=80=9Cthz" together in a way that can be heard and = understood. >=20 > * BeBAuthZ Back-end Based Authorization Protocol > The definition of =E2=80=9Cback end=E2=80=9D is going to change = depending on your perspective in the stack, but even if it were = consistent, the flexibility around user interaction is a huge motivator = for many getting involved in this work. > This is close to =E2=80=9CBBAuth=E2=80=9D, which was a = commercial predecessor to OAuth 1, so much that it=E2=80=99s nearly = impossible to disambiguate when talking. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * BYOAuthZ Build-Your-Own Authorization Protocol > This is the opposite of what we=E2=80=99re doing here. We = don=E2=80=99t want a bunch of disparate pieces that people can use to = build a protocol, we want a protocol with the right kind of flexibility = to fit different use cases. This name tells developers that they = aren=E2=80=99t getting a solution and incompatibility is likely. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * CPAAP Comprehensive Privileged Authentication Authorization = Protocol > This makes me think of CPAP, a breathing assistance device. Not = something I=E2=80=99m keen to call to mind in the middle of a global = pandemic of a respiratory disease. > The expansion doesn=E2=80=99t really tell me anything. > What does =E2=80=9Cprivileged=E2=80=9D mean here, and does it = apply to the authentication (which seems implied)? >=20 > * DIYAuthZ Do-It-Yourself Authorization Protocol > As above in BYOAuthZ, this is the opposite of what we=E2=80=99re = trying to do by creating a standard.=20 > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * GranPro GRAnt Negotiation Protocol > The acronym is a really awkward construction.=20 > As above, =E2=80=9Cgrant=E2=80=9D is an often misunderstood term = from OAuth 2. Plus, the =E2=80=9Cgrant=E2=80=9D isn=E2=80=99t really = what=E2=80=99s being negotiated here. >=20 > * IDPAuthZ Intent Driven Protocol for Authorization > =E2=80=9CIDP=E2=80=9D is already well understood in this space = to mean =E2=80=9Cidentity provider=E2=80=9D, so we should not try to = overload it. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * PAuthZ Protocol for Authorization > It was suggested this would be pronounced =E2=80=9Cpaws=E2=80=9D = but I can=E2=80=99t think of a single reason someone looking at the word = would try to pronounce it that way.=20 > It=E2=80=99s also completely generic and doesn=E2=80=99t say = anything about the work. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * RefAuthZ Refactored Authorization Protocol > Refactored from what? What if someone refactors this? What are = the factors? > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * ReAuthZ Reimagined Authorization Protocol > The short form is already a short term for = =E2=80=9Cre-authorization=E2=80=9D, which is not what we are doing. > Reimagined from what, and by whom? > The expansion sounds like it=E2=80=99s imaginary and not real. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * TIAAP Tokenized Identity and Access Protocol > I don=E2=80=99t think =E2=80=9Ctokenized=E2=80=9D is used in a = meaningful way here. It produced =E2=80=9Ctokens=E2=80=9D, but = tokenization is the splitting up of an input into pieces, which is not = what=E2=80=99s happening here. >=20 > * TIDEAuth Trust via Intent Driven Extension Auth > The expansion is really awkward. > It sounds like it=E2=80=99s an extension to an existing protocol = (something that we are explicitly NOT doing per the charter). > =09 > * TIDYAuth Trust via Intent Driven Yield Auth > I actually really like the acronym but the expansion is super = awkward. What is being yielded here? >=20 > * TIEAuth Trust via Intent Extension Auth > What is =E2=80=9Cintent extension=E2=80=9D?=20 > As above, it sounds like an extension not a protocol. >=20 > * TINOA This Is Not OAuth > This says nothing about what this work is, only what it isn=E2=80=99= t. And on that regard, it doesn=E2=80=99t matter that this isn=E2=80=99t = OAuth. OAuth 2 isn=E2=80=99t OAuth 1, either.=20 > And given that ease of transition from OAuth 2 is part of the = charter, this isn=E2=80=99t a helpful distinction. >=20 > * TXAuth Testable eXtensible Authorization > I don=E2=80=99t get the focus on =E2=80=9Ctestable=E2=80=9D in = the name. Testable in what way? Can other protocols not be tested? > Extensibility is not a differentiating feature of this work. >=20 > * TXAuth Truly eXtensible Authorization > Extensibility is not a differentiating feature of this work. > What makes something =E2=80=9Ctruly extensible=E2=80=9D as = opposed to =E2=80=9Cnot truly extensible=E2=80=9D? >=20 > * XAuthZ eXtensible authoriZation protocol > Extensibility is not a differentiating feature of this work. > The acronym is just pulling random letters from the middle of = words in the expansion to try to work. > Same comment as above focus on Authorization. > Same comment as above about Zed/Zee confusion. >=20 > * WRAC Web Resource Access Collaboration > This is not a collaboration protocol or system. Collaboration, = within computer science, is established to refer to when two or more = :people: work and communicate together. This protocol does not = facilitate human communication, and so the use of this term is not = appropriate here.=20 > This is very close to =E2=80=9Cwrack=E2=80=9D which is a common = enough English verb, as in =E2=80=9Cwracked nerves=E2=80=9D or =E2=80=9Cto= wrack one=E2=80=99s brain=E2=80=9D, which derives from the medieval = torture process of stretching someone over a rack. This=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_F341B5CE-2728-4793-A998-7076F9A6EF26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Dick,

Yes, I am = pretty familiar with the charter text, but thank you for posting it to = the group as a reminder.

The original charter text for the OAuth WG[1] does in fact = call out extensibility explicitly in several places, = including:

The Working Group will produce one or more =
documents
suitable for consideration as Proposed Standard that =
will:
 ...
* Provide guidelines for extensibility.

The difference here is that we=E2=80=99re being more = explicit about what is extensible and how, in the charter. But one of = the biggest innovations in OAuth 2, as I=E2=80=99m sure you know, is = that it allowed for explicit extensibility in ways that OAuth 1 did not: = grant types, token types, scopes (and therefore resource types), client = auth types (and therefore client types), etc. The very fact that OAuth 2 = is a *framework* fundamentally speaks to its goals of = extensibility. 

The TxAuth = charter text that you quoted carries much of that tradition forward, = which is why I said that extensibility is not a :defining: feature of = this work. It=E2=80=99s absolutely a feature and an important one, but = extensibility itself is hardly new or unique as a goal. What=E2=80=99s = unique is :what: we=E2=80=99re targeting for extensibility points, which = is why those are listed below in the proposed charter = text.

I also worry that a focus on = =E2=80=98extensibility=E2=80=99 above all else will slide us back into = the world of incompatible framework pieces. As the proposed charter also = states that we=E2=80=99re building a protocol, not a framework, this is = counter to what we=E2=80=99re coming together for.

 =E2=80=94 Justin


On Jun 2, 2020, at 5:58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hey Justin,

Per your comment = "Extensibility is not a differentiating feature of this work.", = extensibility is explicitly called out in the charter (and is not in the = OAuth WG charter):

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
- Mechanisms for conveying user, software, = organization, and other pieces of information used in authorization = decisions
- Mechanisms for presenting tokens to = resource servers and binding resource requests to tokens and associated = cryptographic keys
- Optimized inclusion of = additional information through the delegation process (including = identifiers and identity assertions)

Milestones to include:
<snip>
- Guidelines for use of = protocol extension points

[1] https://datatracker.ietf.org/wg/txauth/about/
3D""=E1=90=A7

On Thu, May = 28, 2020 at 2:47 PM Justin Richer <jricher@mit.edu> wrote:
Thanks = to everyone in the community for suggesting names, and thanks to the = chairs for putting this list together.

Here=E2=80=99s my personal take on the = candidates.



Wouldn=E2=80=99t Object:

* TxAuth      Transmission of = Authority
= This is my personal favorite of the lot because it avoids the = =E2=80=9Cauthorization/authentication=E2=80=9D question and gets at the = heart of what this protocol does: delegation, which is to say, = transmitting the authority to do something from one party to another. = That delegation allows for authorized access to resources, but can also = allow different rights to flow as needed. Additionally, =E2=80=9Ctx=E2=80=9D= has long been used to stand for =E2=80=9Ctransmission=E2=80=9D in = computer science and networking.

* AZARP    AuthoriZed Access to Resources = Protocol
The use of = =E2=80=9CAZ=E2=80=9D to stand for =E2=80=9Cauthorized=E2=80=9D is = awkward, but the pronunciation kinda works as something memorable. The = expansion is a twist of words to make it fit, and I like that = less.
Resource access is only part of the story, but = it=E2=80=99s an important part. This leaves out what we want to do = around non-authorization cases (like identity conveyance).

* AZARAP    AuthoriZation And = Resource Access Protocol
I like the = expansion here more than the one for AZARP but I like the acronym less = with the additional =E2=80=9CA=E2=80=9D.
Same comment as = above for AZ standing for Authorization.
Same comment as = above for resource access.

* DAZARAP    Delegated AuthoriZation And Resource = Access Protocol
I like the = expansion here, but the acronym is awkward and weak. 
= Same comment as above for AZ standing for Authorized.
Same comment as above for resource = access.

* = GNAP    Grant Negotiation and Authorization Protocol
This is ok, but it has a couple downsides. The = pronunciation of a hard =E2=80=9Cg=E2=80=9D or not is going to = potentially be confusing, as is the fact that it looks like it=E2=80=99s = part of the GNU project because of that.
The term = =E2=80=9CGrant=E2=80=9D is one of the more confusing things that was = introduced in OAuth 2, and while it=E2=80=99s established in the lexicon = today, I=E2=80=99ve yet to meet many engineering teams that actually = know what a =E2=80=9Cgrant=E2=80=9D is. Most think it=E2=80=99s another = name for the authorization code.
Also it means = =E2=80=9Cto bite=E2=80=9D, which may or may not be desirable.

* NIRAD   =  Negotiation of Intent Registration and Authority Delegation
This is a somewhat weak construct, but it mostly = works. It spells out more what the protocol will do (if we go with the = currently proposed solution designs) than what it solves, but that might = be ok.
It makes me think of NORAD (a positive, they do = weather radar and track Santa Claus each year), but also =E2=80=9Cnimrod=E2= =80=9D, a pejorative term. And before anyone chimes in with =E2=80=9CBut = Nimrod was a mighty hunter of ancient times=E2=80=9D, it doesn=E2=80=99t = mean that to any modern listener.

* GATAR      Grant = Authorization To Access Resources 
This one isn=E2=80=99= t bad, and I can appreciate the =E2=80=9Cguitar=E2=80=9D pronunciation = and imagery. As above, resource access isonly part of the = story.
Same comment about =E2=80=9CGrant=E2=80=9D as = above in GNAP.



Object:

* AAuthZ    Alternative Authorization = Protocol (AAuthZ)
It=E2=80=99s an = alternative to what, exactly? And what happens when someone makes an = alternative to it?
The focus on = =E2=80=9CAuthorization=E2=80=9D as a core part of the name tells only = part of the story. 
Assuming the = =E2=80=9CZ=E2=80=9D is pronounced as its letter name (which is implied = by the capitalization), there=E2=80=99s an issue with pronouncing = the final =E2=80=9CZ=E2=80=9D as either =E2=80=9CZee=E2=80=9D or = =E2=80=9CZed=E2=80=9D depending on dialect. If it=E2=80=99s not = pronounced as a letter, it=E2=80=99s really difficult to say the = consonants =E2=80=9Cthz" together in a way that can be heard and = understood.

* BeBAuthZ   =  Back-end Based Authorization Protocol
The definition of = =E2=80=9Cback end=E2=80=9D is going to change depending on your = perspective in the stack, but even if it were consistent, the = flexibility around user interaction is a huge motivator for many getting = involved in this work.
This is close to = =E2=80=9CBBAuth=E2=80=9D, which was a commercial predecessor to OAuth 1, = so much that it=E2=80=99s nearly impossible to disambiguate when = talking.
Same comment as above focus on = Authorization.
Same comment as above about Zed/Zee = confusion.

* BYOAuthZ   =  Build-Your-Own Authorization Protocol
This is the = opposite of what we=E2=80=99re doing here. We don=E2=80=99t want a bunch = of disparate pieces that people can use to build a protocol, we want a = protocol with the right kind of flexibility to fit different use cases. = This name tells developers that they aren=E2=80=99t getting a solution = and incompatibility is likely.
Same comment as = above focus on Authorization.
Same comment as = above about Zed/Zee confusion.

* CPAAP    Comprehensive = Privileged Authentication Authorization Protocol
= This makes me think of CPAP, a breathing assistance device. Not = something I=E2=80=99m keen to call to mind in the middle of a global = pandemic of a respiratory disease.
The expansion = doesn=E2=80=99t really tell me anything.
What does = =E2=80=9Cprivileged=E2=80=9D mean here, and does it apply to the = authentication (which seems implied)?

* DIYAuthZ    Do-It-Yourself = Authorization Protocol
As above in = BYOAuthZ, this is the opposite of what we=E2=80=99re trying to do by = creating a standard. 
= Same comment as above focus on Authorization.
= Same comment as above about Zed/Zee confusion.

* GranPro    GRAnt Negotiation = Protocol
The acronym is a really awkward = construction. 
As = above, =E2=80=9Cgrant=E2=80=9D is an often misunderstood term from = OAuth 2. Plus, the =E2=80=9Cgrant=E2=80=9D isn=E2=80=99t really what=E2=80= =99s being negotiated here.

* = IDPAuthZ    Intent Driven Protocol for Authorization
= =E2=80=9CIDP=E2=80=9D is already well understood in this space to = mean =E2=80=9Cidentity provider=E2=80=9D, so we should not try to = overload it.
Same comment as = above focus on Authorization.
Same comment as = above about Zed/Zee confusion.

* PAuthZ    Protocol for = Authorization
It was suggested this would be pronounced = =E2=80=9Cpaws=E2=80=9D but I can=E2=80=99t think of a single reason = someone looking at the word would try to pronounce it that = way. 
It=E2=80=99s also completely generic and = doesn=E2=80=99t say anything about the work.
Same comment as above focus on = Authorization.
Same comment as above about Zed/Zee = confusion.

* RefAuthZ =    Refactored Authorization Protocol
Refactored from = what? What if someone refactors this? What are the factors?
Same comment as = above focus on Authorization.
Same comment as = above about Zed/Zee confusion.

* ReAuthZ    Reimagined Authorization = Protocol
= The short form is already a short term for = =E2=80=9Cre-authorization=E2=80=9D, which is not what we are doing.
Reimagined from = what, and by whom?
The = expansion sounds like it=E2=80=99s imaginary and not = real.
Same comment as = above focus on Authorization.
Same comment as = above about Zed/Zee confusion.

* TIAAP    Tokenized Identity and Access = Protocol
I don=E2=80=99t think =E2=80=9Ctokenized=E2=80=9D = is used in a meaningful way here. It produced =E2=80=9Ctokens=E2=80=9D, = but tokenization is the splitting up of an input into pieces, which is = not what=E2=80=99s happening here.

* = TIDEAuth    Trust via Intent Driven Extension Auth
= The expansion is really awkward.
It sounds like = it=E2=80=99s an extension to an existing protocol (something that we are = explicitly NOT doing per the charter).

* = TIDYAuth    Trust via Intent Driven Yield Auth
I = actually really like the acronym but the expansion is super awkward. = What is being yielded here?

* = TIEAuth    Trust via Intent Extension Auth
= What is =E2=80=9Cintent extension=E2=80=9D? 
= As above, it sounds like an extension not a protocol.

* TINOA   This Is Not OAuth
= This says nothing about what this work is, only what it isn=E2=80=99= t. And on that regard, it doesn=E2=80=99t matter that this isn=E2=80=99= t OAuth. OAuth 2 isn=E2=80=99t OAuth 1, either. 
= And given that ease of transition from OAuth 2 is part of the = charter, this isn=E2=80=99t a helpful distinction.

* TXAuth    Testable eXtensible = Authorization
I don=E2=80=99t get the focus on =E2=80=9Ctestable=E2= =80=9D in the name. Testable in what way? Can other protocols not be = tested?
Extensibility is = not a differentiating feature of this work.

* TXAuth      Truly eXtensible = Authorization
Extensibility is = not a differentiating feature of this work.
What makes = something =E2=80=9Ctruly extensible=E2=80=9D as opposed to =E2=80=9Cnot = truly extensible=E2=80=9D?

* = XAuthZ    eXtensible authoriZation protocol
Extensibility is not a differentiating feature of = this work.
The acronym is just pulling random letters from = the middle of words in the expansion to try to work.
= Same comment as above focus on Authorization.
= Same comment as above about Zed/Zee confusion.

* WRAC     Web Resource Access = Collaboration
This is not a collaboration protocol or system. = Collaboration, within computer science, is established to refer to when = two or more :people: work and communicate together. This protocol does = not facilitate human communication, and so the use of this term is not = appropriate here. 
This is very = close to =E2=80=9Cwrack=E2=80=9D which is a common enough English = verb, as in =E2=80=9Cwracked nerves=E2=80=9D or =E2=80=9Cto wrack = one=E2=80=99s brain=E2=80=9D, which derives from the medieval torture = process of stretching someone over a rack. This 

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

= --Apple-Mail=_F341B5CE-2728-4793-A998-7076F9A6EF26-- From nobody Wed Jun 3 05:28:00 2020 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 A1FA63A108F for ; Wed, 3 Jun 2020 05:27:58 -0700 (PDT) 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 BPsSE8v3UueD for ; Wed, 3 Jun 2020 05:27:56 -0700 (PDT) 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 B73803A108D for ; Wed, 3 Jun 2020 05:27:55 -0700 (PDT) Received: from [192.168.1.12] (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 053CRpbY019624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Jun 2020 08:27:52 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F2F0EDAA-CC38-47E0-A87B-CFFBC25D6127" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 3 Jun 2020 08:27:51 -0400 In-Reply-To: Cc: "txauth@ietf.org" To: Dick Hardt References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 03 Jun 2020 12:27:59 -0000 --Apple-Mail=_F2F0EDAA-CC38-47E0-A87B-CFFBC25D6127 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I wanted to provide feedback on this point specifically: >=20 > * TxAuth Transmission of Authority >=20 > - I think this name is misleading. As it is Justin's favorite, I'll = elaborate more than I have on the others ... starting with definitions = of the words: >=20 > Transmission:=20 > the action or process of transmitting something or the state of being = transmitted. "the transmission of the virus" >=20 > Transmit:=20 > cause (something) to pass on from one place or person to another. >=20 > Authority: > a power or right delegated or given; authorization: "Who has the = authority to grant permission?" >=20 > Authorization: > the act of authorizing. permission or power granted by an authority; = sanction. >=20 > Building on these definitions, "Transmission of Authority" means = passing a power to another person. The power is the ability to = authorize.=20 >=20 > Someone familiar with a certificate authority (CA), a related area, = "transmission of authority" could mean the CA passing authority to = another entity, which would then be another CA.=20 >=20 > Using OAuth terms, the AS has the authority to issue tokens to the = client. The AS is not passing the authority to issue tokens to the = client.=20 I think you=E2=80=99ve got an odd twist of the words in your = interpretation here. The authority is embodied in the access token, the = result of the delegation process. This authority is transmitted from the = RO through the AS to the client, via the token. I don=E2=80=99t think it = at all implies that the AS is transmitting authority to issue tokens. If = that=E2=80=99s an issue with this name, then it should also be an issue = with any suggestion with =E2=80=9CGrant=E2=80=9D in the name because it = could imply that the AS is granting the client authority to make its own = tokens, by the same leap of logic.=20 It=E2=80=99s very important to see that the AS holds authority only in = trust from the resource owner, who has the actual power to grant = authority. The transmission of authority in OAuth as in our proposed = work is from the resource owner to the client, embodied by the access = token issued by the AS. It=E2=80=99s from a party with authority, = normally a user but sometimes not, to a piece of software =E2=80=94 not = another user directly. This is the core of the entire =E2=80=9Cgrant=E2=80= =9D concept. It isn=E2=80=99t misleading at all. =E2=80=94 Justin > =E1=90=A7 >=20 > On Fri, May 22, 2020 at 3:32 AM Yaron Sheffer > wrote: > Thank you David for pointing out the loophole in my previous mail. As = a result, we have decided to limit the time when new names may be = proposed. If you have new name ideas, please make sure to share them = until 0800 UTC, Tuesday, May 26. >=20 > All others, if you want to make sure you are commenting on the full = name list, please hold off until after Monday. >=20 > Apologies for the process confusion, we are building it as we go. >=20 > Thanks, > Yaron >=20 > =EF=BB=BFOn 5/21/20, 11:53, "Yaron Sheffer" > wrote: >=20 > Thank you to those who contributed early replies! >=20 > As a refinement/clarification to the process below: we are now = focusing on discussion and making sure there are no strong objections, = rather than voting on people's favorite name. >=20 > With that in mind, we strongly encourage people to attach an = explanation to each name they object to. Therefore for names that are on = neither of your lists ("wouldn't object to" and "object to"), our = default assumption is that you would NOT object to them. >=20 > With the process now finalized, please take a few minutes and = provide us with your name lists. As a reminder, the deadline is 0800 UTC = June 4, 2020. >=20 > Thanks, > Yaron >=20 >=20 > =EF=BB=BFOn 5/19/20, 23:34, "Yaron Sheffer" > wrote: >=20 > Hi! >=20 > After reviewing the community feedback and discussions with = the AD, we=E2=80=99d like to again launch a process to elicit feedback = on naming. Our proposal is below. We=E2=80=99d appreciate any = clarifying questions, proposed improvements or objections by 0800 UTC, = Thursday, May 21st . >=20 > Thanks, > Yaron and Dick =20 >=20 > PS, I=E2=80=99m sharing the load with Dick and taking point on = this consensus call -- Yaron >=20 > ---- >=20 > Before we submit the draft charter [1] to the IESG, we wanted = to explore the name of the group. During the chartering discussions, = some people objected to the BoF name being the WG name. We=E2=80=99d = like to get consensus on what the WG name should be. Our first attempt = to elicit input [2] wasn=E2=80=99t successful, and this is a second = attempt to get consensus from the community. >=20 > To get to consensus, we want to gather preferences on the = currently known WG name candidates. Our goal is not to select the most = popular name -- it is to select a name everyone can live with and ensure = that we understand and weigh any objections there might be with that = choice. To that end, we=E2=80=99d like to elicit your name preferences = in the following way: >=20 > (1) In previous discussions, the following candidate names = have been voiced (we have listed only these names that received at least = one vote previously): >=20 > * AAuthZ Alternative Authorization Protocol (AAuthZ) > * AZARP AuthoriZed Access to Resources Protocol > * AZARAP AuthoriZation And Resource Access Protocol > * BeBAuthZ Back-end Based Authorization Protocol > * BYOAuthZ Build-Your-Own Authorization Protocol > * CPAAP Comprehensive Privileged Authentication = Authorization Protocol > * DAZARAP Delegated AuthoriZation And Resource Access = Protocol > * DIYAuthZ Do-It-Yourself Authorization Protocol > * GNAP Grant Negotiation and Authorization Protocol > * GranPro GRAnt Negotiation Protocol > * IDPAuthZ Intent Driven Protocol for Authorization > * NIRAD Negotiation of Intent Registration and Authority = Delegation > * PAuthZ Protocol for Authorization > * RefAuthZ Refactored Authorization Protocol > * ReAuthZ Reimagined Authorization Protocol > * TIAAP Tokenized Identity and Access Protocol > * TIDEAuth Trust via Intent Driven Extension Auth > * TIDYAuth Trust via Intent Driven Yield Auth > * TIEAuth Trust via Intent Extension Auth > * TINOA This Is Not OAuth > * TXAuth Testable eXtensible Authorization > * TxAuth Transmission of Authority > * TXAuth Truly eXtensible Authorization > * XAuthZ eXtensible authoriZation protocol >=20 > We would ask that you consider these names, and respond to the = list with your selection of the following two categories: >=20 > * =E2=80=9CWouldn=E2=80=99t Object=E2=80=9D -- this is not = necessarily your preferred name, but you would be comfortable with it = being the name of the WG (choose as many names as you want) > * =E2=80=9CObject=E2=80=9D -- you would be uncomfortable with = the WG being named in this way (choose as many names as you want; please = provide an explanation) >=20 > (2) If your preferred name isn=E2=80=99t in the list per (1), = you can send a note to the mailing list stating that you=E2=80=99d like = the WG to consider a new name. Please ensure the name adheres to the = previously discussed naming criteria at [3]. We still request that you = provide your other preferences and objections. >=20 > (3) If you previously sent in your preferences, but a new name = suggestion or someone=E2=80=99s objection changed your mind, then send = another message to the mailing list with your revised preferences. For = the purposes of consensus, we=E2=80=99ll assume that everyone who = hasn=E2=80=99t commented on a new name introduced per (2) =E2=80=9Cobjects= =E2=80=9D to it (i.e., we want to hear positive confirmation of = preference on new names). >=20 > (4) Please provide your input by 0800 UTC June 4, 2020. >=20 > With that input, our plan is to assess rough consensus in the = following way: >=20 > (a) See if there is consensus for a name identified given the = =E2=80=9Cwouldn=E2=80=99t object to being the WG name=E2=80=9D = preference and the level of =E2=80=9Cwould object=E2=80=9D feedback >=20 > (b) If there isn=E2=80=99t clear consensus with (a), but a = significantly reduced set of candidates around which there is = enthusiasm, the chairs will share the results and request feedback >=20 > (c) If rough consensus appears to be reached through steps (a) = =E2=80=93 (b), revisit the objections to this candidate name, elicit = additional objections and see if they change the consensus. >=20 > Regards, > Yaron and Dick >=20 > [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/ = > [2] = https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg/ = > [3] = https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/ = >=20 >=20 >=20 >=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=_F2F0EDAA-CC38-47E0-A87B-CFFBC25D6127 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = wanted to provide feedback on this point specifically:


* TxAuth      Transmission of = Authority

- I think this name is = misleading. As it is Justin's favorite, I'll elaborate more than I have = on the others ... starting with definitions of the words:

Transmission:
the action or = process of transmitting something or the state of being transmitted. = "the transmission of the virus"

Transmit: =
cause (something) to pass on from one place or person to = another.

Authority:
a power = or right delegated or given; authorization: "Who has the authority to = grant permission?"

Authorization:
the act of authorizing. permission or power granted by an = authority; sanction.

Building on = these definitions, "Transmission of Authority" means passing a = power to another person. The power is the ability to = authorize. 

Someone familiar with a certificate authority (CA), a related = area, "transmission of authority" could mean the CA passing authority to = another entity, which would then be another CA.

Using OAuth terms, the AS has the authority to issue tokens = to the client. The AS is not passing the authority to issue tokens to = the client.

I think you=E2=80=99ve got an odd twist of the = words in your interpretation here. The authority is embodied in the = access token, the result of the delegation process. This authority is = transmitted from the RO through the AS to the client, via the token. I = don=E2=80=99t think it at all implies that the AS is transmitting = authority to issue tokens. If that=E2=80=99s an issue with this name, = then it should also be an issue with any suggestion with =E2=80=9CGrant=E2= =80=9D in the name because it could imply that the AS is granting the = client authority to make its own tokens, by the same leap of = logic. 

It=E2=80=99s very = important to see that the AS holds authority only in trust from the = resource owner, who has the actual power to grant authority. The = transmission of authority in OAuth as in our proposed work is from the = resource owner to the client, embodied by the access token issued by the = AS. It=E2=80=99s from a party with authority, normally a user but = sometimes not, to a piece of software =E2=80=94 not another user = directly. This is the core of the entire =E2=80=9Cgrant=E2=80=9D = concept.

It isn=E2=80=99t misleading = at all.

 =E2=80=94 = Justin

3D""=E1=90=A7

On Fri, May = 22, 2020 at 3:32 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Thank you David for pointing out the = loophole in my previous mail. As a result, we have decided to limit the = time when new names may be proposed. If you have new name ideas, please = make sure to share them until 0800 UTC, Tuesday, May 26.

All others, if you want to make sure you are commenting on the full name = list, please hold off until after Monday.

Apologies for the process confusion, we are building it as we go.

Thanks,
        Yaron

=EF=BB=BFOn 5/21/20, 11:53, "Yaron Sheffer" <yaronf.ietf@gmail.com> wrote:

    Thank you to those who contributed early replies!

    As a refinement/clarification to the process below: we are = now focusing on discussion and making sure there are no strong = objections, rather than voting on people's favorite name.

    With that in mind, we strongly encourage people to attach = an explanation to each name they object to. Therefore for names that are = on neither of your lists ("wouldn't object to" and "object to"), our = default assumption is that you would NOT object to them.

    With the process now finalized, please take a few minutes = and provide us with your name lists. As a reminder, the deadline is 0800 = UTC June 4, 2020.

    Thanks,
        Yaron


    =EF=BB=BFOn 5/19/20, 23:34, "Yaron Sheffer" <yaronf.ietf@gmail.com> wrote:

        Hi!

        After reviewing the community feedback and = discussions with the AD, we=E2=80=99d like to again launch a process to = elicit feedback on naming.  Our proposal is below.  We=E2=80=99d= appreciate any clarifying questions, proposed improvements or = objections by 0800 UTC, Thursday, May 21st .

        Thanks,
                Yaron and = Dick 

        PS, I=E2=80=99m sharing the load with Dick = and taking point on this consensus call -- Yaron

        ----

        Before we submit the draft charter [1] to = the IESG, we wanted to explore the name of the group. During the = chartering discussions, some people objected to the BoF name being the = WG name.  We=E2=80=99d like to get consensus on what the WG name = should be.  Our first attempt to elicit input [2] wasn=E2=80=99t = successful, and this is a second attempt to get consensus from the = community.

        To get to consensus, we want to gather = preferences on the currently known WG name candidates. Our goal is not = to select the most popular name -- it is to select a name everyone can = live with and ensure that we understand and weigh any objections there = might be with that choice.  To that end, we=E2=80=99d like to = elicit your name preferences in the following way:

         (1) In previous discussions, the = following candidate names have been voiced (we have listed only these = names that received at least one vote previously):

        * AAuthZ    Alternative = Authorization Protocol (AAuthZ)
        * AZARP    AuthoriZed Access to = Resources Protocol
        * AZARAP    AuthoriZation And = Resource Access Protocol
        * BeBAuthZ    Back-end Based = Authorization Protocol
        * BYOAuthZ    Build-Your-Own = Authorization Protocol
        * CPAAP    Comprehensive = Privileged Authentication Authorization Protocol
        * DAZARAP    Delegated = AuthoriZation And Resource Access Protocol
        * DIYAuthZ    Do-It-Yourself = Authorization Protocol
        * GNAP    Grant Negotiation and = Authorization Protocol
        * GranPro    GRAnt Negotiation = Protocol
        * IDPAuthZ    Intent Driven = Protocol for Authorization
        * NIRAD    Negotiation of Intent = Registration and Authority Delegation
        * PAuthZ    Protocol for = Authorization
        * RefAuthZ    Refactored = Authorization Protocol
        * ReAuthZ    Reimagined = Authorization Protocol
        * TIAAP    Tokenized Identity and = Access Protocol
        * TIDEAuth    Trust via Intent = Driven Extension Auth
        * TIDYAuth    Trust via Intent = Driven Yield Auth
        * TIEAuth    Trust via Intent = Extension Auth
        * TINOA   This Is Not OAuth
        * TXAuth    Testable eXtensible = Authorization
        * TxAuth      Transmission of = Authority
        * TXAuth      Truly = eXtensible Authorization
        * XAuthZ    eXtensible = authoriZation protocol

        We would ask that you consider these names, = and respond to the list with your selection of the following two = categories:

        * =E2=80=9CWouldn=E2=80=99t Object=E2=80=9D = -- this is not necessarily your preferred name, but you would be = comfortable with it being the name of the WG (choose as many names as = you want)
        * =E2=80=9CObject=E2=80=9D -- you would be = uncomfortable with the WG being named in this way (choose as many names = as you want; please provide an explanation)

        (2) If your preferred name isn=E2=80=99t in = the list per (1), you can send a note to the mailing list stating that = you=E2=80=99d like the WG to consider a new name.  Please ensure = the name adheres to the previously discussed naming criteria at [3]. We = still request that you provide your other preferences and objections.

        (3) If you previously sent in your = preferences, but a new name suggestion or someone=E2=80=99s objection = changed your mind, then send another message to the mailing list with = your revised preferences.  For the purposes of consensus, we=E2=80=99= ll assume that everyone who hasn=E2=80=99t commented on a new name = introduced per (2) =E2=80=9Cobjects=E2=80=9D to it (i.e., we want to = hear positive confirmation of preference on new names).

        (4) Please provide your input by 0800 UTC = June 4, 2020.

        With that input, our plan is to assess rough = consensus in the following way:

        (a) See if there is consensus for a name = identified given the =E2=80=9Cwouldn=E2=80=99t object to being the WG = name=E2=80=9D preference and the level of =E2=80=9Cwould object=E2=80=9D = feedback

        (b) If there isn=E2=80=99t clear consensus = with (a), but a significantly reduced set of candidates around which = there is enthusiasm, the chairs will share the results and request = feedback

        (c) If rough consensus appears to be reached = through steps (a) =E2=80=93 (b), revisit the objections to this = candidate name, elicit additional objections and see if they change the = consensus.

        Regards,
                Yaron and = Dick

        [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/
        [2] https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3= VTqkYi0Wg/
        [3] https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWV= Dcq8rnUa8/




--
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=_F2F0EDAA-CC38-47E0-A87B-CFFBC25D6127-- From nobody Wed Jun 3 05:37:11 2020 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 F10733A10A3 for ; Wed, 3 Jun 2020 05:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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=udelt-no.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 tBTJ65mCirT8 for ; Wed, 3 Jun 2020 05:37:07 -0700 (PDT) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0: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 1A5463A10A4 for ; Wed, 3 Jun 2020 05:37:07 -0700 (PDT) Received: by mail-oi1-x229.google.com with SMTP id k4so101935oik.2 for ; Wed, 03 Jun 2020 05:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udelt-no.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CRcaZywlU+3bu8+GledIkni2ud35mTAgMItxF9zHbFQ=; b=fSya4IjesHS36XDFhXLd0ByeSqDwDPm2WESy5QjM8mV4KxxoM3D4DCCOs8Xg/zLFj1 sesKXf+/gZB4veumuv68DgRgto9OsX1+Np6nlDiClu7bcqsqanhfHCdRopkbXjStjlzc tOA+4iadXi53h2yF0uy8Z9JE1SYmCa1BtR7E6kUnWhpOztr1ak7Vac3IWd8Qg7KgqMz1 ICIXAEdW9Cb+rtiymPZQfjWCbxvn4PRGD+wKJchBh9uMaNlMbsWnU79cACFfMWwPWF/P Bq08+oy/DLxn4JpoyF7Spbtne+boC9uU+zRsHQjKeLVcUxC/Iasfaw8/mAk55TB2Fk9i ecgg== 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=CRcaZywlU+3bu8+GledIkni2ud35mTAgMItxF9zHbFQ=; b=WU6RCgi2XaAFK6x7jMnTg9Z5qFHwFXqgsiSL+ELnr97AVBWnTBDuZp7BXIn2FH+vyz cUE+gSNpZeRfdHOWBlirKGseCa51NpzT8jT3DPEtypuDrE3D1/VZcpth0GeXYQpFm5P+ sa+X3uM7CVBd9AKOhY7lWmS7CqZ3vXQXhhQdEUb9ZxXOqH6dojNkMMZ4NpqSx5+JOrO+ FmZB2tRKrgxfq2wJqJy+wB2bwOU+BkrkNr3hTdoKnFWOBmN6LPwhsVCtdcRKmu4pJj8N fDzXmGRaWRlpmHUghZuyVa74pHDZ+f90Oulo0Br9Att3DjVMAg998lzkkR+Zy6ixBcf/ sZrw== X-Gm-Message-State: AOAM531+KfT87YuNAR9i2Qlt7aMEcwpToDRi9VYFmgBzxLAaxtj7/7Cm 808BcjJXXFSwqLzY+xgf+a19iXU7zsStk0Uu18eolA== X-Google-Smtp-Source: ABdhPJzJfj74LVuqz5urdgkOSYW4ecjP75stuYFm9fmzizE+SVkn8c96wD3URqxQpNA4i/COG5h40qUk/cj6/V9MSLA= X-Received: by 2002:aca:fccf:: with SMTP id a198mr6078602oii.91.1591187826162; Wed, 03 Jun 2020 05:37:06 -0700 (PDT) MIME-Version: 1.0 References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> In-Reply-To: From: Steinar Noem Date: Wed, 3 Jun 2020 14:36:55 +0200 Message-ID: To: Justin Richer Cc: Dick Hardt , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000026505f05a72d492f" Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 03 Jun 2020 12:37:10 -0000 --00000000000026505f05a72d492f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Regarding the word "transmission": I'm norwegian - so I often find it difficult to detect nuances in the english language :) I also know that the time for new suggestions has passed. But I wonder, would "Transferral" be a better word in this case? S ons. 3. jun. 2020 kl. 14:28 skrev Justin Richer : > I wanted to provide feedback on this point specifically: > > > * TxAuth Transmission of Authority > > - I think this name is misleading. As it is Justin's favorite, I'll > elaborate more than I have on the others ... starting with definitions of > the words: > > Transmission: > the action or process of transmitting something or the state of being > transmitted. "the transmission of the virus" > > Transmit: > cause (something) to pass on from one place or person to another. > > Authority: > a power or right delegated or given; authorization: "Who has the authorit= y > to grant permission?" > > Authorization: > the act of authorizing. permission or power granted by an authority; > sanction. > > Building on these definitions, "Transmission of Authority" means passing = a > power to another person. The power is the ability to authorize. > > Someone familiar with a certificate authority (CA), a related area, > "transmission of authority" could mean the CA passing authority to anothe= r > entity, which would then be another CA. > > Using OAuth terms, the AS has the authority to issue tokens to the client= . > The AS is not passing the authority to issue tokens to the client. > > > I think you=E2=80=99ve got an odd twist of the words in your interpretati= on here. > The authority is embodied in the access token, the result of the delegati= on > process. This authority is transmitted from the RO through the AS to the > client, via the token. I don=E2=80=99t think it at all implies that the A= S is > transmitting authority to issue tokens. If that=E2=80=99s an issue with t= his name, > then it should also be an issue with any suggestion with =E2=80=9CGrant= =E2=80=9D in the > name because it could imply that the AS is granting the client authority = to > make its own tokens, by the same leap of logic. > > It=E2=80=99s very important to see that the AS holds authority only in tr= ust from > the resource owner, who has the actual power to grant authority. The > transmission of authority in OAuth as in our proposed work is from the > resource owner to the client, embodied by the access token issued by the > AS. It=E2=80=99s from a party with authority, normally a user but sometim= es not, to > a piece of software =E2=80=94 not another user directly. This is the core= of the > entire =E2=80=9Cgrant=E2=80=9D concept. > > It isn=E2=80=99t misleading at all. > > =E2=80=94 Justin > > =E1=90=A7 > > On Fri, May 22, 2020 at 3:32 AM Yaron Sheffer > wrote: > >> Thank you David for pointing out the loophole in my previous mail. As a >> result, we have decided to limit the time when new names may be proposed= . >> If you have new name ideas, please make sure to share them until 0800 UT= C, >> Tuesday, May 26. >> >> All others, if you want to make sure you are commenting on the full name >> list, please hold off until after Monday. >> >> Apologies for the process confusion, we are building it as we go. >> >> Thanks, >> Yaron >> >> =EF=BB=BFOn 5/21/20, 11:53, "Yaron Sheffer" wrot= e: >> >> Thank you to those who contributed early replies! >> >> As a refinement/clarification to the process below: we are now >> focusing on discussion and making sure there are no strong objections, >> rather than voting on people's favorite name. >> >> With that in mind, we strongly encourage people to attach an >> explanation to each name they object to. Therefore for names that are on >> neither of your lists ("wouldn't object to" and "object to"), our defaul= t >> assumption is that you would NOT object to them. >> >> With the process now finalized, please take a few minutes and provid= e >> us with your name lists. As a reminder, the deadline is 0800 UTC June 4, >> 2020. >> >> Thanks, >> Yaron >> >> >> =EF=BB=BFOn 5/19/20, 23:34, "Yaron Sheffer" = wrote: >> >> Hi! >> >> After reviewing the community feedback and discussions with the >> AD, we=E2=80=99d like to again launch a process to elicit feedback on na= ming. Our >> proposal is below. We=E2=80=99d appreciate any clarifying questions, pr= oposed >> improvements or objections by 0800 UTC, Thursday, May 21st . >> >> Thanks, >> Yaron and Dick >> >> PS, I=E2=80=99m sharing the load with Dick and taking point on t= his >> consensus call -- Yaron >> >> ---- >> >> Before we submit the draft charter [1] to the IESG, we wanted to >> explore the name of the group. During the chartering discussions, some >> people objected to the BoF name being the WG name. We=E2=80=99d like to= get >> consensus on what the WG name should be. Our first attempt to elicit in= put >> [2] wasn=E2=80=99t successful, and this is a second attempt to get conse= nsus from >> the community. >> >> To get to consensus, we want to gather preferences on the >> currently known WG name candidates. Our goal is not to select the most >> popular name -- it is to select a name everyone can live with and ensure >> that we understand and weigh any objections there might be with that >> choice. To that end, we=E2=80=99d like to elicit your name preferences = in the >> following way: >> >> (1) In previous discussions, the following candidate names have >> been voiced (we have listed only these names that received at least one >> vote previously): >> >> * AAuthZ Alternative Authorization Protocol (AAuthZ) >> * AZARP AuthoriZed Access to Resources Protocol >> * AZARAP AuthoriZation And Resource Access Protocol >> * BeBAuthZ Back-end Based Authorization Protocol >> * BYOAuthZ Build-Your-Own Authorization Protocol >> * CPAAP Comprehensive Privileged Authentication Authorization >> Protocol >> * DAZARAP Delegated AuthoriZation And Resource Access Protoco= l >> * DIYAuthZ Do-It-Yourself Authorization Protocol >> * GNAP Grant Negotiation and Authorization Protocol >> * GranPro GRAnt Negotiation Protocol >> * IDPAuthZ Intent Driven Protocol for Authorization >> * NIRAD Negotiation of Intent Registration and Authority >> Delegation >> * PAuthZ Protocol for Authorization >> * RefAuthZ Refactored Authorization Protocol >> * ReAuthZ Reimagined Authorization Protocol >> * TIAAP Tokenized Identity and Access Protocol >> * TIDEAuth Trust via Intent Driven Extension Auth >> * TIDYAuth Trust via Intent Driven Yield Auth >> * TIEAuth Trust via Intent Extension Auth >> * TINOA This Is Not OAuth >> * TXAuth Testable eXtensible Authorization >> * TxAuth Transmission of Authority >> * TXAuth Truly eXtensible Authorization >> * XAuthZ eXtensible authoriZation protocol >> >> We would ask that you consider these names, and respond to the >> list with your selection of the following two categories: >> >> * =E2=80=9CWouldn=E2=80=99t Object=E2=80=9D -- this is not neces= sarily your preferred >> name, but you would be comfortable with it being the name of the WG (cho= ose >> as many names as you want) >> * =E2=80=9CObject=E2=80=9D -- you would be uncomfortable with th= e WG being named >> in this way (choose as many names as you want; please provide an >> explanation) >> >> (2) If your preferred name isn=E2=80=99t in the list per (1), yo= u can >> send a note to the mailing list stating that you=E2=80=99d like the WG t= o consider >> a new name. Please ensure the name adheres to the previously discussed >> naming criteria at [3]. We still request that you provide your other >> preferences and objections. >> >> (3) If you previously sent in your preferences, but a new name >> suggestion or someone=E2=80=99s objection changed your mind, then send a= nother >> message to the mailing list with your revised preferences. For the >> purposes of consensus, we=E2=80=99ll assume that everyone who hasn=E2=80= =99t commented on a >> new name introduced per (2) =E2=80=9Cobjects=E2=80=9D to it (i.e., we wa= nt to hear positive >> confirmation of preference on new names). >> >> (4) Please provide your input by 0800 UTC June 4, 2020. >> >> With that input, our plan is to assess rough consensus in the >> following way: >> >> (a) See if there is consensus for a name identified given the >> =E2=80=9Cwouldn=E2=80=99t object to being the WG name=E2=80=9D preferenc= e and the level of =E2=80=9Cwould >> object=E2=80=9D feedback >> >> (b) If there isn=E2=80=99t clear consensus with (a), but a signi= ficantly >> reduced set of candidates around which there is enthusiasm, the chairs w= ill >> share the results and request feedback >> >> (c) If rough consensus appears to be reached through steps (a) = =E2=80=93 >> (b), revisit the objections to this candidate name, elicit additional >> objections and see if they change the consensus. >> >> Regards, >> Yaron and Dick >> >> [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/ >> [2] >> https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg= / >> [3] >> https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8= / >> >> >> >> >> -- >> 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 > --=20 Vennlig hilsen Steinar Noem Partner Udelt AS Systemutvikler | steinar@udelt.no | hei@udelt.no | +47 955 21 620 | www.udelt.no | --00000000000026505f05a72d492f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Regarding the word "transmission":
I'm n= orwegian - so I often find it difficult to detect nuances in the english la= nguage :)=C2=A0
I also know that the time for new suggestions has= passed. But I wonder, would "Transferral" be a better word in th= is case?=C2=A0 =C2=A0

S

ons. 3. jun. 2020 kl= . 14:28 skrev Justin Richer <jricher@= mit.edu>:
I wanted to provide feedback on = this point specifically:


* TxAuth =C2=A0 =C2=A0 =C2=A0Transmission of = Authority

- I think this name is misleading. As it is Justin's f= avorite, I'll elaborate more than I have on the others ... starting wit= h definitions of the words:

Transmission:
the action or process = of transmitting something or the state of being transmitted. "the tran= smission of the virus"

Transmit:
cause (something) to pass = on from one place or person to another.

Authority:
a power or rig= ht delegated or given; authorization: "Who has the authority to grant = permission?"

Authorization:
the act of authorizing. permissi= on or power granted by an authority; sanction.

Building on these=C2= =A0definitions, "Transmission of Authority" means passing a power= to another person. The power is the ability to authorize.=C2=A0
=
Someone familiar with a certificate authority (CA), a relate= d area, "transmission of authority" could mean the CA passing aut= hority to another entity, which would then be another CA.

Using OAu= th terms, the AS has the authority to issue tokens to the client. The AS is= not passing the authority to issue tokens to the client.
<= /div>

I think you=E2=80=99ve got an odd twi= st of the words in your interpretation here. The authority is embodied in t= he access token, the result of the delegation process. This authority is tr= ansmitted from the RO through the AS to the client, via the token. I don=E2= =80=99t think it at all implies that the AS is transmitting authority to is= sue tokens. If that=E2=80=99s an issue with this name, then it should also = be an issue with any suggestion with =E2=80=9CGrant=E2=80=9D in the name be= cause it could imply that the AS is granting the client authority to make i= ts own tokens, by the same leap of logic.=C2=A0

It= =E2=80=99s very important to see that the AS holds authority only in trust = from the resource owner, who has the actual power to grant authority. The t= ransmission of authority in OAuth as in our proposed work is from the resou= rce owner to the client, embodied by the access token issued by the AS. It= =E2=80=99s from a party with authority, normally a user but sometimes not, = to a piece of software =E2=80=94 not another user directly. This is the cor= e of the entire =E2=80=9Cgrant=E2=80=9D concept.

I= t isn=E2=80=99t misleading at all.

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

3D""=E1=90=A7<= /div>
O= n Fri, May 22, 2020 at 3:32 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Thank you David for p= ointing out the loophole in my previous mail. As a result, we have decided = to limit the time when new names may be proposed. If you have new name idea= s, please make sure to share them until 0800 UTC, Tuesday, May 26.

All others, if you want to make sure you are commenting on the full name li= st, please hold off until after Monday.

Apologies for the process confusion, we are building it as we go.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

=EF=BB=BFOn 5/21/20, 11:53, "Yaron Sheffer" <yaronf.ietf@gmail.com> wro= te:

=C2=A0 =C2=A0 Thank you to those who contributed early replies!

=C2=A0 =C2=A0 As a refinement/clarification to the process below: we are no= w focusing on discussion and making sure there are no strong objections, ra= ther than voting on people's favorite name.

=C2=A0 =C2=A0 With that in mind, we strongly encourage people to attach an = explanation to each name they object to. Therefore for names that are on ne= ither of your lists ("wouldn't object to" and "object to= "), our default assumption is that you would NOT object to them.

=C2=A0 =C2=A0 With the process now finalized, please take a few minutes and= provide us with your name lists. As a reminder, the deadline is 0800 UTC J= une 4, 2020.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


=C2=A0 =C2=A0 =EF=BB=BFOn 5/19/20, 23:34, "Yaron Sheffer" <yaronf.ietf@gmail.c= om> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 After reviewing the community feedback and disc= ussions with the AD, we=E2=80=99d like to again launch a process to elicit = feedback on naming.=C2=A0 Our proposal is below.=C2=A0 We=E2=80=99d appreci= ate any clarifying questions, proposed improvements or objections by 0800 U= TC, Thursday, May 21st .

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron and Dick=C2= =A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 PS, I=E2=80=99m sharing the load with Dick and = taking point on this consensus call -- Yaron

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Before we submit the draft charter [1] to the I= ESG, we wanted to explore the name of the group. During the chartering disc= ussions, some people objected to the BoF name being the WG name.=C2=A0 We= =E2=80=99d like to get consensus on what the WG name should be.=C2=A0 Our f= irst attempt to elicit input [2] wasn=E2=80=99t successful, and this is a s= econd attempt to get consensus from the community.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 To get to consensus, we want to gather preferen= ces on the currently known WG name candidates. Our goal is not to select th= e most popular name -- it is to select a name everyone can live with and en= sure that we understand and weigh any objections there might be with that c= hoice.=C2=A0 To that end, we=E2=80=99d like to elicit your name preferences= in the following way:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(1) In previous discussions, the followin= g candidate names have been voiced (we have listed only these names that re= ceived at least one vote previously):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 * AAuthZ=C2=A0 =C2=A0 Alternative Authorization= Protocol (AAuthZ)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * AZARP=C2=A0 =C2=A0 AuthoriZed Access to Resou= rces Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * AZARAP=C2=A0 =C2=A0 AuthoriZation And Resourc= e Access Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * BeBAuthZ=C2=A0 =C2=A0 Back-end Based Authoriz= ation Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * BYOAuthZ=C2=A0 =C2=A0 Build-Your-Own Authoriz= ation Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * CPAAP=C2=A0 =C2=A0 Comprehensive Privileged A= uthentication Authorization Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * DAZARAP=C2=A0 =C2=A0 Delegated AuthoriZation = And Resource Access Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * DIYAuthZ=C2=A0 =C2=A0 Do-It-Yourself Authoriz= ation Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * GNAP=C2=A0 =C2=A0 Grant Negotiation and Autho= rization Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * GranPro=C2=A0 =C2=A0 GRAnt Negotiation Protoc= ol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * IDPAuthZ=C2=A0 =C2=A0 Intent Driven Protocol = for Authorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * NIRAD=C2=A0 =C2=A0 Negotiation of Intent Regi= stration and Authority Delegation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * PAuthZ=C2=A0 =C2=A0 Protocol for Authorizatio= n
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * RefAuthZ=C2=A0 =C2=A0 Refactored Authorizatio= n Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * ReAuthZ=C2=A0 =C2=A0 Reimagined Authorization= Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TIAAP=C2=A0 =C2=A0 Tokenized Identity and Acc= ess Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TIDEAuth=C2=A0 =C2=A0 Trust via Intent Driven= Extension Auth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TIDYAuth=C2=A0 =C2=A0 Trust via Intent Driven= Yield Auth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TIEAuth=C2=A0 =C2=A0 Trust via Intent Extensi= on Auth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TINOA=C2=A0 =C2=A0This Is Not OAuth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TXAuth=C2=A0 =C2=A0 Testable eXtensible Autho= rization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TxAuth=C2=A0 =C2=A0 =C2=A0 Transmission of Au= thority
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TXAuth=C2=A0 =C2=A0 =C2=A0 Truly eXtensible A= uthorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * XAuthZ=C2=A0 =C2=A0 eXtensible authoriZation = protocol

=C2=A0 =C2=A0 =C2=A0 =C2=A0 We would ask that you consider these names, and= respond to the list with your selection of the following two categories:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =E2=80=9CWouldn=E2=80=99t Object=E2=80=9D -- = this is not necessarily your preferred name, but you would be comfortable w= ith it being the name of the WG (choose as many names as you want)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =E2=80=9CObject=E2=80=9D -- you would be unco= mfortable with the WG being named in this way (choose as many names as you = want; please provide an explanation)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (2) If your preferred name isn=E2=80=99t in the= list per (1), you can send a note to the mailing list stating that you=E2= =80=99d like the WG to consider a new name.=C2=A0 Please ensure the name ad= heres to the previously discussed naming criteria at [3]. We still request = that you provide your other preferences and objections.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (3) If you previously sent in your preferences,= but a new name suggestion or someone=E2=80=99s objection changed your mind= , then send another message to the mailing list with your revised preferenc= es.=C2=A0 For the purposes of consensus, we=E2=80=99ll assume that everyone= who hasn=E2=80=99t commented on a new name introduced per (2) =E2=80=9Cobj= ects=E2=80=9D to it (i.e., we want to hear positive confirmation of prefere= nce on new names).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (4) Please provide your input by 0800 UTC June = 4, 2020.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 With that input, our plan is to assess rough co= nsensus in the following way:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (a) See if there is consensus for a name identi= fied given the =E2=80=9Cwouldn=E2=80=99t object to being the WG name=E2=80= =9D preference and the level of =E2=80=9Cwould object=E2=80=9D feedback

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (b) If there isn=E2=80=99t clear consensus with= (a), but a significantly reduced set of candidates around which there is e= nthusiasm, the chairs will share the results and request feedback

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (c) If rough consensus appears to be reached th= rough steps (a) =E2=80=93 (b), revisit the objections to this candidate nam= e, elicit additional objections and see if they change the consensus.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron and Dick

=C2=A0 =C2=A0 =C2=A0 =C2=A0 [1] https://datatra= cker.ietf.org/doc/charter-ietf-txauth/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [2] https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0= Wg/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [3] https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnU= a8/




--
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


--
Vennlig hilsen=

Steinar Noem
Partner Udelt AS
Systemutvikler<= /div>
=C2=A0
|=C2=A0steinar@udelt.no=C2=A0|=C2=A0hei@udelt.n= o=C2=A0=C2=A0|=C2=A0+47 955 21 620=C2=A0|=C2=A0www.udelt.= no=C2=A0|=C2=A0
--00000000000026505f05a72d492f-- From nobody Wed Jun 3 06:01:58 2020 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 ECD793A0817 for ; Wed, 3 Jun 2020 06:01:56 -0700 (PDT) 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 8wwkvsom3rfa for ; Wed, 3 Jun 2020 06:01:54 -0700 (PDT) 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 F09543A0819 for ; Wed, 3 Jun 2020 06:01:53 -0700 (PDT) Received: from [192.168.1.12] (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 053D1mLa028940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Jun 2020 09:01:49 -0400 From: Justin Richer Message-Id: <0AFEFB54-3787-4EAF-9FEF-3FA133000DFC@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_9E66768E-E51C-423A-81F8-C043BD0EF722" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 3 Jun 2020 09:01:47 -0400 In-Reply-To: Cc: "txauth@ietf.org" , Dick Hardt To: Steinar Noem References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 03 Jun 2020 13:01:57 -0000 --Apple-Mail=_9E66768E-E51C-423A-81F8-C043BD0EF722 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think =E2=80=9CTransferral=E2=80=9D would have been fine to = communicate the concept, but I was looking for something that more = naturally went with =E2=80=9Ctx=E2=80=9D since Dick has said he would be = fine with a different expansion of =E2=80=9CTx=E2=80=9D in the name = =E2=80=9CTxAuth=E2=80=9D. Using =E2=80=9Ctx=E2=80=9D to mean = =E2=80=9Ctransmission=E2=80=9D or =E2=80=9Ctransmitter=E2=80=9D is even = more common in computer science than using =E2=80=9Ctx" to mean = =E2=80=9Ctransaction=E2=80=9D, and there you see it along side =E2=80=9Crx= =E2=80=9D to mean =E2=80=9Creceiver=E2=80=9D or =E2=80=9Creception=E2=80=9D= .=20 =E2=80=94 Justin > On Jun 3, 2020, at 8:36 AM, Steinar Noem wrote: >=20 > Regarding the word "transmission": > I'm norwegian - so I often find it difficult to detect nuances in the = english language :)=20 > I also know that the time for new suggestions has passed. But I = wonder, would "Transferral" be a better word in this case? =20 >=20 > S >=20 > ons. 3. jun. 2020 kl.. 14:28 skrev Justin Richer >: > I wanted to provide feedback on this point specifically: >=20 >>=20 >> * TxAuth Transmission of Authority >>=20 >> - I think this name is misleading. As it is Justin's favorite, I'll = elaborate more than I have on the others ... starting with definitions = of the words: >>=20 >> Transmission:=20 >> the action or process of transmitting something or the state of being = transmitted. "the transmission of the virus" >>=20 >> Transmit:=20 >> cause (something) to pass on from one place or person to another. >>=20 >> Authority: >> a power or right delegated or given; authorization: "Who has the = authority to grant permission?" >>=20 >> Authorization: >> the act of authorizing. permission or power granted by an authority; = sanction. >>=20 >> Building on these definitions, "Transmission of Authority" means = passing a power to another person. The power is the ability to = authorize.=20 >>=20 >> Someone familiar with a certificate authority (CA), a related area, = "transmission of authority" could mean the CA passing authority to = another entity, which would then be another CA.=20 >>=20 >> Using OAuth terms, the AS has the authority to issue tokens to the = client. The AS is not passing the authority to issue tokens to the = client.=20 >=20 > I think you=E2=80=99ve got an odd twist of the words in your = interpretation here. The authority is embodied in the access token, the = result of the delegation process. This authority is transmitted from the = RO through the AS to the client, via the token. I don=E2=80=99t think it = at all implies that the AS is transmitting authority to issue tokens. If = that=E2=80=99s an issue with this name, then it should also be an issue = with any suggestion with =E2=80=9CGrant=E2=80=9D in the name because it = could imply that the AS is granting the client authority to make its own = tokens, by the same leap of logic.=20 >=20 > It=E2=80=99s very important to see that the AS holds authority only in = trust from the resource owner, who has the actual power to grant = authority. The transmission of authority in OAuth as in our proposed = work is from the resource owner to the client, embodied by the access = token issued by the AS. It=E2=80=99s from a party with authority, = normally a user but sometimes not, to a piece of software =E2=80=94 not = another user directly. This is the core of the entire =E2=80=9Cgrant=E2=80= =9D concept. >=20 > It isn=E2=80=99t misleading at all. >=20 > =E2=80=94 Justin >=20 >> =E1=90=A7 >>=20 >> On Fri, May 22, 2020 at 3:32 AM Yaron Sheffer > wrote: >> Thank you David for pointing out the loophole in my previous mail. As = a result, we have decided to limit the time when new names may be = proposed. If you have new name ideas, please make sure to share them = until 0800 UTC, Tuesday, May 26. >>=20 >> All others, if you want to make sure you are commenting on the full = name list, please hold off until after Monday. >>=20 >> Apologies for the process confusion, we are building it as we go. >>=20 >> Thanks, >> Yaron >>=20 >> =EF=BB=BFOn 5/21/20, 11:53, "Yaron Sheffer" > wrote: >>=20 >> Thank you to those who contributed early replies! >>=20 >> As a refinement/clarification to the process below: we are now = focusing on discussion and making sure there are no strong objections, = rather than voting on people's favorite name. >>=20 >> With that in mind, we strongly encourage people to attach an = explanation to each name they object to. Therefore for names that are on = neither of your lists ("wouldn't object to" and "object to"), our = default assumption is that you would NOT object to them. >>=20 >> With the process now finalized, please take a few minutes and = provide us with your name lists. As a reminder, the deadline is 0800 UTC = June 4, 2020. >>=20 >> Thanks, >> Yaron >>=20 >>=20 >> =EF=BB=BFOn 5/19/20, 23:34, "Yaron Sheffer" = > wrote: >>=20 >> Hi! >>=20 >> After reviewing the community feedback and discussions with = the AD, we=E2=80=99d like to again launch a process to elicit feedback = on naming. Our proposal is below. We=E2=80=99d appreciate any = clarifying questions, proposed improvements or objections by 0800 UTC, = Thursday, May 21st . >>=20 >> Thanks, >> Yaron and Dick =20 >>=20 >> PS, I=E2=80=99m sharing the load with Dick and taking point = on this consensus call -- Yaron >>=20 >> ---- >>=20 >> Before we submit the draft charter [1] to the IESG, we wanted = to explore the name of the group. During the chartering discussions, = some people objected to the BoF name being the WG name. We=E2=80=99d = like to get consensus on what the WG name should be. Our first attempt = to elicit input [2] wasn=E2=80=99t successful, and this is a second = attempt to get consensus from the community. >>=20 >> To get to consensus, we want to gather preferences on the = currently known WG name candidates. Our goal is not to select the most = popular name -- it is to select a name everyone can live with and ensure = that we understand and weigh any objections there might be with that = choice. To that end, we=E2=80=99d like to elicit your name preferences = in the following way: >>=20 >> (1) In previous discussions, the following candidate names = have been voiced (we have listed only these names that received at least = one vote previously): >>=20 >> * AAuthZ Alternative Authorization Protocol (AAuthZ) >> * AZARP AuthoriZed Access to Resources Protocol >> * AZARAP AuthoriZation And Resource Access Protocol >> * BeBAuthZ Back-end Based Authorization Protocol >> * BYOAuthZ Build-Your-Own Authorization Protocol >> * CPAAP Comprehensive Privileged Authentication = Authorization Protocol >> * DAZARAP Delegated AuthoriZation And Resource Access = Protocol >> * DIYAuthZ Do-It-Yourself Authorization Protocol >> * GNAP Grant Negotiation and Authorization Protocol >> * GranPro GRAnt Negotiation Protocol >> * IDPAuthZ Intent Driven Protocol for Authorization >> * NIRAD Negotiation of Intent Registration and Authority = Delegation >> * PAuthZ Protocol for Authorization >> * RefAuthZ Refactored Authorization Protocol >> * ReAuthZ Reimagined Authorization Protocol >> * TIAAP Tokenized Identity and Access Protocol >> * TIDEAuth Trust via Intent Driven Extension Auth >> * TIDYAuth Trust via Intent Driven Yield Auth >> * TIEAuth Trust via Intent Extension Auth >> * TINOA This Is Not OAuth >> * TXAuth Testable eXtensible Authorization >> * TxAuth Transmission of Authority >> * TXAuth Truly eXtensible Authorization >> * XAuthZ eXtensible authoriZation protocol >>=20 >> We would ask that you consider these names, and respond to = the list with your selection of the following two categories: >>=20 >> * =E2=80=9CWouldn=E2=80=99t Object=E2=80=9D -- this is not = necessarily your preferred name, but you would be comfortable with it = being the name of the WG (choose as many names as you want) >> * =E2=80=9CObject=E2=80=9D -- you would be uncomfortable with = the WG being named in this way (choose as many names as you want; please = provide an explanation) >>=20 >> (2) If your preferred name isn=E2=80=99t in the list per (1), = you can send a note to the mailing list stating that you=E2=80=99d like = the WG to consider a new name. Please ensure the name adheres to the = previously discussed naming criteria at [3]. We still request that you = provide your other preferences and objections. >>=20 >> (3) If you previously sent in your preferences, but a new = name suggestion or someone=E2=80=99s objection changed your mind, then = send another message to the mailing list with your revised preferences. = For the purposes of consensus, we=E2=80=99ll assume that everyone who = hasn=E2=80=99t commented on a new name introduced per (2) =E2=80=9Cobjects= =E2=80=9D to it (i.e., we want to hear positive confirmation of = preference on new names). >>=20 >> (4) Please provide your input by 0800 UTC June 4, 2020. >>=20 >> With that input, our plan is to assess rough consensus in the = following way: >>=20 >> (a) See if there is consensus for a name identified given the = =E2=80=9Cwouldn=E2=80=99t object to being the WG name=E2=80=9D = preference and the level of =E2=80=9Cwould object=E2=80=9D feedback >>=20 >> (b) If there isn=E2=80=99t clear consensus with (a), but a = significantly reduced set of candidates around which there is = enthusiasm, the chairs will share the results and request feedback >>=20 >> (c) If rough consensus appears to be reached through steps = (a) =E2=80=93 (b), revisit the objections to this candidate name, elicit = additional objections and see if they change the consensus. >>=20 >> Regards, >> Yaron and Dick >>=20 >> [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/ = >> [2] = https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg/ = >> [3] = https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/ = >>=20 >>=20 >>=20 >>=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 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 >=20 > --=20 > Vennlig hilsen >=20 > Steinar Noem > Partner Udelt AS > Systemutvikler > =20 > | steinar@udelt.no | hei@udelt.no = | +47 955 21 620 <> | www.udelt.no = |=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_9E66768E-E51C-423A-81F8-C043BD0EF722 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think =E2=80=9CTransferral=E2=80=9D would have been fine to communicate = the concept, but I was looking for something that more naturally went = with =E2=80=9Ctx=E2=80=9D since Dick has said he would be fine with a = different expansion of =E2=80=9CTx=E2=80=9D in the name =E2=80=9CTxAuth=E2= =80=9D. Using =E2=80=9Ctx=E2=80=9D to mean =E2=80=9Ctransmission=E2=80=9D = or =E2=80=9Ctransmitter=E2=80=9D is even more common in computer science = than using =E2=80=9Ctx" to mean =E2=80=9Ctransaction=E2=80=9D, and there = you see it along side =E2=80=9Crx=E2=80=9D to mean =E2=80=9Creceiver=E2=80= =9D or =E2=80=9Creception=E2=80=9D. 

 =E2=80=94 Justin

On Jun 3, 2020, at 8:36 AM, Steinar Noem <steinar@udelt.no> = wrote:

Regarding the word = "transmission":
I'm norwegian - so I often find it = difficult to detect nuances in the english language :) 
I also know that the time for new suggestions has passed. But = I wonder, would "Transferral" be a better word in this case?  =  

S

ons. 3. jun. 2020 kl.. 14:28 skrev = Justin Richer <jricher@mit.edu>:
I wanted to provide feedback on this point = specifically:


* TxAuth   =    Transmission of Authority

- I = think this name is misleading. As it is Justin's favorite, I'll = elaborate more than I have on the others ... starting with definitions = of the words:

Transmission:
the action or process of transmitting something or the state = of being transmitted. "the transmission of the virus"

Transmit:
cause (something) to pass on from = one place or person to another.

Authority:a power or right delegated or given; authorization: "Who has = the authority to grant permission?"

Authorization:
the act of authorizing. = permission or power granted by an authority; sanction.

Building on these definitions, "Transmission of = Authority" means passing a power to another person. The power is the = ability to authorize. 

Someone familiar with a certificate authority (CA), a = related area, "transmission of authority" could mean the CA passing = authority to another entity, which would then be another CA.

Using OAuth terms, the AS has the authority to = issue tokens to the client. The AS is not passing the authority to issue = tokens to the client.

I think you=E2=80=99ve = got an odd twist of the words in your interpretation here. The authority = is embodied in the access token, the result of the delegation process. = This authority is transmitted from the RO through the AS to the client, = via the token. I don=E2=80=99t think it at all implies that the AS is = transmitting authority to issue tokens. If that=E2=80=99s an issue with = this name, then it should also be an issue with any suggestion with = =E2=80=9CGrant=E2=80=9D in the name because it could imply that the AS = is granting the client authority to make its own tokens, by the same = leap of logic. 

It=E2=80=99s very important to see that the AS holds = authority only in trust from the resource owner, who has the actual = power to grant authority. The transmission of authority in OAuth as in = our proposed work is from the resource owner to the client, embodied by = the access token issued by the AS. It=E2=80=99s from a party with = authority, normally a user but sometimes not, to a piece of software =E2=80= =94 not another user directly. This is the core of the entire = =E2=80=9Cgrant=E2=80=9D concept.

It isn=E2=80=99t misleading at = all.

 =E2=80= =94 Justin

3D""=E1=90=A7

On Fri, May = 22, 2020 at 3:32 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Thank you David for pointing out the = loophole in my previous mail. As a result, we have decided to limit the = time when new names may be proposed. If you have new name ideas, please = make sure to share them until 0800 UTC, Tuesday, May 26.

All others, if you want to make sure you are commenting on the full name = list, please hold off until after Monday.

Apologies for the process confusion, we are building it as we go.

Thanks,
        Yaron

=EF=BB=BFOn 5/21/20, 11:53, "Yaron Sheffer" <yaronf.ietf@gmail.com> wrote:

    Thank you to those who contributed early replies!

    As a refinement/clarification to the process below: we are = now focusing on discussion and making sure there are no strong = objections, rather than voting on people's favorite name.

    With that in mind, we strongly encourage people to attach = an explanation to each name they object to. Therefore for names that are = on neither of your lists ("wouldn't object to" and "object to"), our = default assumption is that you would NOT object to them.

    With the process now finalized, please take a few minutes = and provide us with your name lists. As a reminder, the deadline is 0800 = UTC June 4, 2020.

    Thanks,
        Yaron


    =EF=BB=BFOn 5/19/20, 23:34, "Yaron Sheffer" <yaronf.ietf@gmail.com> wrote:

        Hi!

        After reviewing the community feedback and = discussions with the AD, we=E2=80=99d like to again launch a process to = elicit feedback on naming.  Our proposal is below.  We=E2=80=99d= appreciate any clarifying questions, proposed improvements or = objections by 0800 UTC, Thursday, May 21st .

        Thanks,
                Yaron and = Dick 

        PS, I=E2=80=99m sharing the load with Dick = and taking point on this consensus call -- Yaron

        ----

        Before we submit the draft charter [1] to = the IESG, we wanted to explore the name of the group. During the = chartering discussions, some people objected to the BoF name being the = WG name.  We=E2=80=99d like to get consensus on what the WG name = should be.  Our first attempt to elicit input [2] wasn=E2=80=99t = successful, and this is a second attempt to get consensus from the = community.

        To get to consensus, we want to gather = preferences on the currently known WG name candidates. Our goal is not = to select the most popular name -- it is to select a name everyone can = live with and ensure that we understand and weigh any objections there = might be with that choice.  To that end, we=E2=80=99d like to = elicit your name preferences in the following way:

         (1) In previous discussions, the = following candidate names have been voiced (we have listed only these = names that received at least one vote previously):

        * AAuthZ    Alternative = Authorization Protocol (AAuthZ)
        * AZARP    AuthoriZed Access to = Resources Protocol
        * AZARAP    AuthoriZation And = Resource Access Protocol
        * BeBAuthZ    Back-end Based = Authorization Protocol
        * BYOAuthZ    Build-Your-Own = Authorization Protocol
        * CPAAP    Comprehensive = Privileged Authentication Authorization Protocol
        * DAZARAP    Delegated = AuthoriZation And Resource Access Protocol
        * DIYAuthZ    Do-It-Yourself = Authorization Protocol
        * GNAP    Grant Negotiation and = Authorization Protocol
        * GranPro    GRAnt Negotiation = Protocol
        * IDPAuthZ    Intent Driven = Protocol for Authorization
        * NIRAD    Negotiation of Intent = Registration and Authority Delegation
        * PAuthZ    Protocol for = Authorization
        * RefAuthZ    Refactored = Authorization Protocol
        * ReAuthZ    Reimagined = Authorization Protocol
        * TIAAP    Tokenized Identity and = Access Protocol
        * TIDEAuth    Trust via Intent = Driven Extension Auth
        * TIDYAuth    Trust via Intent = Driven Yield Auth
        * TIEAuth    Trust via Intent = Extension Auth
        * TINOA   This Is Not OAuth
        * TXAuth    Testable eXtensible = Authorization
        * TxAuth      Transmission of = Authority
        * TXAuth      Truly = eXtensible Authorization
        * XAuthZ    eXtensible = authoriZation protocol

        We would ask that you consider these names, = and respond to the list with your selection of the following two = categories:

        * =E2=80=9CWouldn=E2=80=99t Object=E2=80=9D = -- this is not necessarily your preferred name, but you would be = comfortable with it being the name of the WG (choose as many names as = you want)
        * =E2=80=9CObject=E2=80=9D -- you would be = uncomfortable with the WG being named in this way (choose as many names = as you want; please provide an explanation)

        (2) If your preferred name isn=E2=80=99t in = the list per (1), you can send a note to the mailing list stating that = you=E2=80=99d like the WG to consider a new name.  Please ensure = the name adheres to the previously discussed naming criteria at [3]. We = still request that you provide your other preferences and objections.

        (3) If you previously sent in your = preferences, but a new name suggestion or someone=E2=80=99s objection = changed your mind, then send another message to the mailing list with = your revised preferences.  For the purposes of consensus, we=E2=80=99= ll assume that everyone who hasn=E2=80=99t commented on a new name = introduced per (2) =E2=80=9Cobjects=E2=80=9D to it (i.e., we want to = hear positive confirmation of preference on new names).

        (4) Please provide your input by 0800 UTC = June 4, 2020.

        With that input, our plan is to assess rough = consensus in the following way:

        (a) See if there is consensus for a name = identified given the =E2=80=9Cwouldn=E2=80=99t object to being the WG = name=E2=80=9D preference and the level of =E2=80=9Cwould object=E2=80=9D = feedback

        (b) If there isn=E2=80=99t clear consensus = with (a), but a significantly reduced set of candidates around which = there is enthusiasm, the chairs will share the results and request = feedback

        (c) If rough consensus appears to be reached = through steps (a) =E2=80=93 (b), revisit the objections to this = candidate name, elicit additional objections and see if they change the = consensus.

        Regards,
                Yaron and = Dick

        [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/
        [2] https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3= VTqkYi0Wg/
        [3] https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWV= Dcq8rnUa8/




--
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
=


--
Vennlig hilsen

Steinar Noem
Partner Udelt AS
Systemutvikler
 
| steinar@udelt.no | hei@udelt.no  | +47 955 21 620 | www.udelt.no | 
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_9E66768E-E51C-423A-81F8-C043BD0EF722-- From nobody Wed Jun 3 08:49:00 2020 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 87FAC3A0D81 for ; Wed, 3 Jun 2020 08:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, 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 dqng3iDU1fU1 for ; Wed, 3 Jun 2020 08:48:58 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271A13A0D9D for ; Wed, 3 Jun 2020 08:48:52 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id z9so3323670ljh.13 for ; Wed, 03 Jun 2020 08:48:52 -0700 (PDT) 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=ZiTYkP/hvkywB4XpD1LgRal7cYmIbukjtfB27Z+ET20=; b=TRn3/cPlUBUWPQV8PLymfAq1oDsLCO3v/0ghdqRZs91AC+PhlR62QwyR47fn13IdfV nophl+XUV3p75VbQ3f1fmGI0KhteFfQi4PMsnpOPTaCk+gB7skJ76nyFGCIDW0UQNBR0 DUKXqnPZzTYmPAKjbzRI4KyxzJtz38I1HSjioz8VJ75X69UxEZsfY28H7+VIAg0R/QDg kdg1IK9mssPnAws6an1gSTMfDsin/0TVckbNAmi6YYu8TrThgtbhRhUnxbS09A6f533l YxjB7cMxldRvQldzgb9ilyVb31eDlNbuQvRpbyIZhbbJggcVFZcR1oZVXJAUCgqJDNou bJUA== 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=ZiTYkP/hvkywB4XpD1LgRal7cYmIbukjtfB27Z+ET20=; b=iGg0KPWjOn5C8tsKeRZw5INMEXXpnZI/kPrDkvl/AQnPtWNyUhE325oFSNS7/9kLJF rsuQihleKauSi5jYmAZdkG1fTssxJ7VgPmopRuwClRBTYdi8sRHQs9BN/xevveM0e8H/ 3f9UHho9/Y4HXA0ZlOMLDQllfh+RA6IqMd1PPZonUDfPjKNF2jPwoMZ2z/sac32hWjJP B2J7BzfWafL1bPlg/Rtx/PNG1n4/VMSnwqUAeHtCQ9jjsDLrxXQ/4GCbwOOLGbK6JjDt TYFu6wG754S0Xpgp5ysRHNN8z9wwDz5kMhXhofYtNAHphD5wiINsBBC/47Qo8AFdddAp 6D9w== X-Gm-Message-State: AOAM530ybR0MkEokXLxK7J5d2WXDOtJTD/Z8Srmx3D3h7fqiwD+dFNHW UpUeP756Fm5HfAyGXDZdIfnmFJJ70lyExuREyC4= X-Google-Smtp-Source: ABdhPJzIWftZK3guos3hJFhJjmNSAF5XKqmNjgoFJzE/QmAGIQ1VSwgl6swEr0rz1Bh+pdV6Hlu3jD/2nXXUV1G2p90= X-Received: by 2002:a2e:7e0a:: with SMTP id z10mr2353609ljc.314.1591199330032; Wed, 03 Jun 2020 08:48:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Wed, 3 Jun 2020 08:48:23 -0700 Message-ID: To: Fabien Imbault Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000d5607a05a72ff6d4" Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 03 Jun 2020 15:48:59 -0000 --000000000000d5607a05a72ff6d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Fabien My concern was not with the word "transmission", but with the word "authority". Per your statement: " ... except maybe if the token itself allows for delegation (but that's a really uncommon case, since JWT doesn't allow that, so I don't think people would even think of it). " That is the confusion I am concerned about. Someone NOT familiar with what it does may easily think that the "token allows for delegation" is the purpose of the protocol as authority is commonly used as a reference to the entity that can issue assertions, not use assertions. =E1=90=A7 On Wed, Jun 3, 2020 at 4:57 AM Fabien Imbault wrote: > Dear all, > > A quick personal feedback on the "TxAuth - Transmission of Authority", > following Dick's comment. > > I previously agreed that transaction may be incorrectly understood in an > IT context, due to its widespread use in database engineering. > > I however disagree with the interpretation that "transmission" would mean > that the AS would be passing the authority to issue tokens to the > client, except maybe if the token itself allows for delegation (but that'= s > a really uncommon case, since JWT doesn't allow that, so I don't think > people would even think of it). > Since I'm not the creator of the acronym, I believe it simply means you'r= e > passing to the client the authority borne by the token, so that the clien= t > can make a call on behalf of the user. I don't see where there could be > ambiguity and it does fit pretty well with the scope of work.. > > One drawback is whether users would actually remember tx means > transmission (instead of transaction), which seems perhaps a bit far > stretched and results from our previous internal discussions. > > As far as I'm concerned, I still think it's one of the best available > proposition (alongside GATAR which came after my "would object"/"wouldn't > object" comments). > > What are the next steps after today's deadline ? > > Fabien > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000d5607a05a72ff6d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fabien

My concern was not with the w= ord "transmission", but with the word "authority". Per = your statement:

" ... except maybe if the tok= en itself allows for delegation (but that's a really uncommon=C2=A0case= , since JWT doesn't allow that, so I don't think people would even = think of it). "

That is the confusion I a= m concerned about. Someone NOT familiar with what it does may easily think = that the "token allows for delegation" is the purpose of the prot= ocol as authority is commonly used as a reference to the entity that can is= sue assertions, not use assertions.

3D""= =E1=90=A7

On Wed, Jun 3, 2020 at 4:57 AM Fabien Imbault <fabien.imbault@gmail.com> wrote= :
Dear all,=C2=A0

A quick personal=C2=A0feedback=C2=A0o= n the "TxAuth - Transmission of Authority", following Dick's = comment.=C2=A0

I previously agreed that transactio= n may be incorrectly=C2=A0understood in an IT context,=C2=A0due to its wide= spread use in database engineering.

I however disa= gree with the interpretation that "transmission" would mean that = the AS would be=C2=A0passing the authority to issue tokens to the client,= =C2=A0except maybe if the token itself allows for delegation (but that'= s a really uncommon=C2=A0case, since JWT doesn't allow that, so I don&#= 39;t think people would even think of it).=C2=A0
Since I'm no= t the creator of the acronym, I=C2=A0believe it simply means you're pas= sing to the client the authority borne by the token,=C2=A0so that the clien= t can make a call on behalf of the user. I don't see where there could = be ambiguity and it does fit pretty well with the scope of work..

One drawback is whether users would actually remember tx me= ans transmission (instead of transaction), which seems perhaps a bit far st= retched and results from our previous internal discussions.=C2=A0=C2=A0

As far as I'm concerned, I still think it's o= ne of the best available proposition (alongside GATAR which came after my &= quot;would object"/"wouldn't object" comments).=C2=A0

What are the next steps after today's deadline ?=

Fabien
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000d5607a05a72ff6d4-- From nobody Wed Jun 3 09:25:17 2020 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 22AB63A0884 for ; Wed, 3 Jun 2020 09:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 1GbBR8DKrF6F for ; Wed, 3 Jun 2020 09:25:12 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 D67E53A07DC for ; Wed, 3 Jun 2020 09:25:11 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id n23so3507518ljh.7 for ; Wed, 03 Jun 2020 09:25:11 -0700 (PDT) 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=VP9jWjxsX8XLAoGtbAiLCjIAyzOSOBdq2WPApwH7Rv4=; b=UUJx1N7BRirwXMqa0woyC2cW9BwChNAoUh/0ki5z7cXn0J5S3nWUNiYNsBUxmcg5Ug 3wHab4MRMwrs3g+it0WdnoLiafeAIuZv90cNW5uJ9Fnt3BfNV5WSKMi0uMbNzs2tkjPX ZKRL16kHp6P3TChdyZaVl5yNH2tvai3EG1e1paQRm+2Ez2QRCQqjqUEhV07wGj7iirpG 62dOIXoeo6ecF9WEXeuzfMyEjuCxzHhT3bK1nmak2VmrIaOp6cp1PViqmlX48ukmEzq9 iVlVyYG/Ndh3bVOxpxk3b8PzuulAveIR7ynoFThJ0pTmIA+lU6UsBf+IFgWmjqLM0+Kk pA/Q== 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=VP9jWjxsX8XLAoGtbAiLCjIAyzOSOBdq2WPApwH7Rv4=; b=uQWBtzMYIhbFf92rMtmuCw1MUwU7HUXR9kLR/GJYaPGwp2MtvLHP3GytMO5AqMP8wv MYxOCiCHL3YBigOy+6lcAE9WRKjasQ5T22TCCyutFSlib9E6+TGUo1Doc2aG5CZCVLPe ENzWbkiA49f/Cf6gdMoCOdsUz/Jx0RUQ4ugdNqbDHd8o7ZNHPO3+Q/B7kPD5sRlz8Szg 3YPuEtr3feCzWr8fNGcf+fqL6aTaFqB+EjHJEo6s2bx87NfquBb5tOyX7TBr32Pk8XBQ 8F5rAbZCM87a+P/+Ahfvn9WXdmICSfTIEQ8nwZWgic7opbIlXX3Mj+ajgW0HD7pd/fyg mcXQ== X-Gm-Message-State: AOAM533yAJoPWivHTFa27qyUcUNzRN7Cun2jH2vTFiBVMpiqnmNKB9J8 LIuYD/39SvagVRk1RckPReYUq45SF8QjAtk9ZgA= X-Google-Smtp-Source: ABdhPJzvQrBZ3z+aXMpa81NOJdkcdRYjGFCTJeNlanNeypj6xYIARLz5pNHmGafPqavs+4qxp+gpD53WuiumhM2lFFw= X-Received: by 2002:a2e:3a19:: with SMTP id h25mr9558lja.213.1591201506069; Wed, 03 Jun 2020 09:25:06 -0700 (PDT) MIME-Version: 1.0 References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> In-Reply-To: From: Dick Hardt Date: Wed, 3 Jun 2020 09:24:39 -0700 Message-ID: To: Justin Richer Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008926c905a73078b7" Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 03 Jun 2020 16:25:15 -0000 --0000000000008926c905a73078b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No surprise that you don't think it is misleading, as you did not think that transaction was misleading. While one way of interpreting "Transmission of Authority" is as you describe, I think that for others an "authority" is who can make assertions, which is what the AS does, and is what a Certificate Authority does. The client uses those assertions, just as a server uses a TLS certificate. Using the movie ticket analogy, where the movie ticket is a bearer token, the ticket holder does not think they have any "authority" to access the movie, they think they have been granted access to the movie. =E1=90=A7 On Wed, Jun 3, 2020 at 5:27 AM Justin Richer wrote: > I wanted to provide feedback on this point specifically: > > > * TxAuth Transmission of Authority > > - I think this name is misleading. As it is Justin's favorite, I'll > elaborate more than I have on the others ... starting with definitions of > the words: > > Transmission: > the action or process of transmitting something or the state of being > transmitted. "the transmission of the virus" > > Transmit: > cause (something) to pass on from one place or person to another. > > Authority: > a power or right delegated or given; authorization: "Who has the authorit= y > to grant permission?" > > Authorization: > the act of authorizing. permission or power granted by an authority; > sanction. > > Building on these definitions, "Transmission of Authority" means passing = a > power to another person. The power is the ability to authorize. > > Someone familiar with a certificate authority (CA), a related area, > "transmission of authority" could mean the CA passing authority to anothe= r > entity, which would then be another CA. > > Using OAuth terms, the AS has the authority to issue tokens to the client= . > The AS is not passing the authority to issue tokens to the client. > > > I think you=E2=80=99ve got an odd twist of the words in your interpretati= on here. > The authority is embodied in the access token, the result of the delegati= on > process. This authority is transmitted from the RO through the AS to the > client, via the token. I don=E2=80=99t think it at all implies that the A= S is > transmitting authority to issue tokens. If that=E2=80=99s an issue with t= his name, > then it should also be an issue with any suggestion with =E2=80=9CGrant= =E2=80=9D in the > name because it could imply that the AS is granting the client authority = to > make its own tokens, by the same leap of logic. > > It=E2=80=99s very important to see that the AS holds authority only in tr= ust from > the resource owner, who has the actual power to grant authority. The > transmission of authority in OAuth as in our proposed work is from the > resource owner to the client, embodied by the access token issued by the > AS. It=E2=80=99s from a party with authority, normally a user but sometim= es not, to > a piece of software =E2=80=94 not another user directly. This is the core= of the > entire =E2=80=9Cgrant=E2=80=9D concept. > > It isn=E2=80=99t misleading at all. > > =E2=80=94 Justin > > =E1=90=A7 > > On Fri, May 22, 2020 at 3:32 AM Yaron Sheffer > wrote: > >> Thank you David for pointing out the loophole in my previous mail. As a >> result, we have decided to limit the time when new names may be proposed= . >> If you have new name ideas, please make sure to share them until 0800 UT= C, >> Tuesday, May 26. >> >> All others, if you want to make sure you are commenting on the full name >> list, please hold off until after Monday. >> >> Apologies for the process confusion, we are building it as we go. >> >> Thanks, >> Yaron >> >> =EF=BB=BFOn 5/21/20, 11:53, "Yaron Sheffer" wrot= e: >> >> Thank you to those who contributed early replies! >> >> As a refinement/clarification to the process below: we are now >> focusing on discussion and making sure there are no strong objections, >> rather than voting on people's favorite name. >> >> With that in mind, we strongly encourage people to attach an >> explanation to each name they object to. Therefore for names that are on >> neither of your lists ("wouldn't object to" and "object to"), our defaul= t >> assumption is that you would NOT object to them. >> >> With the process now finalized, please take a few minutes and provid= e >> us with your name lists. As a reminder, the deadline is 0800 UTC June 4, >> 2020. >> >> Thanks, >> Yaron >> >> >> =EF=BB=BFOn 5/19/20, 23:34, "Yaron Sheffer" = wrote: >> >> Hi! >> >> After reviewing the community feedback and discussions with the >> AD, we=E2=80=99d like to again launch a process to elicit feedback on na= ming. Our >> proposal is below. We=E2=80=99d appreciate any clarifying questions, pr= oposed >> improvements or objections by 0800 UTC, Thursday, May 21st . >> >> Thanks, >> Yaron and Dick >> >> PS, I=E2=80=99m sharing the load with Dick and taking point on t= his >> consensus call -- Yaron >> >> ---- >> >> Before we submit the draft charter [1] to the IESG, we wanted to >> explore the name of the group. During the chartering discussions, some >> people objected to the BoF name being the WG name. We=E2=80=99d like to= get >> consensus on what the WG name should be. Our first attempt to elicit in= put >> [2] wasn=E2=80=99t successful, and this is a second attempt to get conse= nsus from >> the community. >> >> To get to consensus, we want to gather preferences on the >> currently known WG name candidates. Our goal is not to select the most >> popular name -- it is to select a name everyone can live with and ensure >> that we understand and weigh any objections there might be with that >> choice. To that end, we=E2=80=99d like to elicit your name preferences = in the >> following way: >> >> (1) In previous discussions, the following candidate names have >> been voiced (we have listed only these names that received at least one >> vote previously): >> >> * AAuthZ Alternative Authorization Protocol (AAuthZ) >> * AZARP AuthoriZed Access to Resources Protocol >> * AZARAP AuthoriZation And Resource Access Protocol >> * BeBAuthZ Back-end Based Authorization Protocol >> * BYOAuthZ Build-Your-Own Authorization Protocol >> * CPAAP Comprehensive Privileged Authentication Authorization >> Protocol >> * DAZARAP Delegated AuthoriZation And Resource Access Protoco= l >> * DIYAuthZ Do-It-Yourself Authorization Protocol >> * GNAP Grant Negotiation and Authorization Protocol >> * GranPro GRAnt Negotiation Protocol >> * IDPAuthZ Intent Driven Protocol for Authorization >> * NIRAD Negotiation of Intent Registration and Authority >> Delegation >> * PAuthZ Protocol for Authorization >> * RefAuthZ Refactored Authorization Protocol >> * ReAuthZ Reimagined Authorization Protocol >> * TIAAP Tokenized Identity and Access Protocol >> * TIDEAuth Trust via Intent Driven Extension Auth >> * TIDYAuth Trust via Intent Driven Yield Auth >> * TIEAuth Trust via Intent Extension Auth >> * TINOA This Is Not OAuth >> * TXAuth Testable eXtensible Authorization >> * TxAuth Transmission of Authority >> * TXAuth Truly eXtensible Authorization >> * XAuthZ eXtensible authoriZation protocol >> >> We would ask that you consider these names, and respond to the >> list with your selection of the following two categories: >> >> * =E2=80=9CWouldn=E2=80=99t Object=E2=80=9D -- this is not neces= sarily your preferred >> name, but you would be comfortable with it being the name of the WG (cho= ose >> as many names as you want) >> * =E2=80=9CObject=E2=80=9D -- you would be uncomfortable with th= e WG being named >> in this way (choose as many names as you want; please provide an >> explanation) >> >> (2) If your preferred name isn=E2=80=99t in the list per (1), yo= u can >> send a note to the mailing list stating that you=E2=80=99d like the WG t= o consider >> a new name. Please ensure the name adheres to the previously discussed >> naming criteria at [3]. We still request that you provide your other >> preferences and objections. >> >> (3) If you previously sent in your preferences, but a new name >> suggestion or someone=E2=80=99s objection changed your mind, then send a= nother >> message to the mailing list with your revised preferences. For the >> purposes of consensus, we=E2=80=99ll assume that everyone who hasn=E2=80= =99t commented on a >> new name introduced per (2) =E2=80=9Cobjects=E2=80=9D to it (i.e., we wa= nt to hear positive >> confirmation of preference on new names). >> >> (4) Please provide your input by 0800 UTC June 4, 2020. >> >> With that input, our plan is to assess rough consensus in the >> following way: >> >> (a) See if there is consensus for a name identified given the >> =E2=80=9Cwouldn=E2=80=99t object to being the WG name=E2=80=9D preferenc= e and the level of =E2=80=9Cwould >> object=E2=80=9D feedback >> >> (b) If there isn=E2=80=99t clear consensus with (a), but a signi= ficantly >> reduced set of candidates around which there is enthusiasm, the chairs w= ill >> share the results and request feedback >> >> (c) If rough consensus appears to be reached through steps (a) = =E2=80=93 >> (b), revisit the objections to this candidate name, elicit additional >> objections and see if they change the consensus. >> >> Regards, >> Yaron and Dick >> >> [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/ >> [2] >> https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0Wg= / >> [3] >> https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8= / >> >> >> >> >> -- >> 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 > > > --0000000000008926c905a73078b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No surprise=C2=A0that you don't think it is misleading= , as you did not think that transaction was misleading.=C2=A0

While one way of interpreting "Transmission of Authority" i= s as you describe, I think that for others an "authority" is who = can make assertions, which is what the AS does,=C2=A0and is what a Certific= ate Authority does. The client uses those assertions, just as a server uses= a TLS certificate.=C2=A0

Using the movie ticket a= nalogy, where the movie ticket is a bearer token, the ticket holder does no= t think they have any "authority" to access the movie, they think= =C2=A0they have been granted access to the movie.=C2=A0






3D"==E1=90=A7

On Wed, Jun 3, 2020 at 5:27 AM Justin Riche= r <jricher@mit.edu> wrote:
=
I wanted to provide feedback on this point specifica= lly:


* TxAuth =C2=A0 =C2=A0 =C2=A0Transmission of Authority

- I= think this name is misleading. As it is Justin's favorite, I'll el= aborate more than I have on the others ... starting with definitions of the= words:

Transmission:
the action or process of transmitting some= thing or the state of being transmitted. "the transmission of the viru= s"

Transmit:
cause (something) to pass on from one place or= person to another.

Authority:
a power or right delegated or give= n; authorization: "Who has the authority to grant permission?"
Authorization:
the act of authorizing. permission or power granted = by an authority; sanction.

Building on these=C2=A0definitions, "= ;Transmission of Authority" means passing a power to another person. T= he power is the ability to authorize.=C2=A0

Someon= e familiar with a certificate authority (CA), a related area, "transmi= ssion of authority" could mean the CA passing authority to another ent= ity, which would then be another CA.

Using OAuth terms, the AS has = the authority to issue tokens to the client. The AS is not passing the auth= ority to issue tokens to the client.

I think you=E2=80=99ve got an odd twist of the words in yo= ur interpretation here. The authority is embodied in the access token, the = result of the delegation process. This authority is transmitted from the RO= through the AS to the client, via the token. I don=E2=80=99t think it at a= ll implies that the AS is transmitting authority to issue tokens. If that= =E2=80=99s an issue with this name, then it should also be an issue with an= y suggestion with =E2=80=9CGrant=E2=80=9D in the name because it could impl= y that the AS is granting the client authority to make its own tokens, by t= he same leap of logic.=C2=A0

It=E2=80=99s very imp= ortant to see that the AS holds authority only in trust from the resource o= wner, who has the actual power to grant authority. The transmission of auth= ority in OAuth as in our proposed work is from the resource owner to the cl= ient, embodied by the access token issued by the AS. It=E2=80=99s from a pa= rty with authority, normally a user but sometimes not, to a piece of softwa= re =E2=80=94 not another user directly. This is the core of the entire =E2= =80=9Cgrant=E2=80=9D concept.

It isn=E2=80=99t mis= leading at all.

=C2=A0=E2=80=94 Justin

3D""=E1=90=A7

On Fri, May 22, 2020= at 3:32 AM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Thank you David for pointing out the loo= phole in my previous mail. As a result, we have decided to limit the time w= hen new names may be proposed. If you have new name ideas, please make sure= to share them until 0800 UTC, Tuesday, May 26.

All others, if you want to make sure you are commenting on the full name li= st, please hold off until after Monday.

Apologies for the process confusion, we are building it as we go.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

=EF=BB=BFOn 5/21/20, 11:53, "Yaron Sheffer" <yaronf.ietf@gmail.com> wro= te:

=C2=A0 =C2=A0 Thank you to those who contributed early replies!

=C2=A0 =C2=A0 As a refinement/clarification to the process below: we are no= w focusing on discussion and making sure there are no strong objections, ra= ther than voting on people's favorite name.

=C2=A0 =C2=A0 With that in mind, we strongly encourage people to attach an = explanation to each name they object to. Therefore for names that are on ne= ither of your lists ("wouldn't object to" and "object to= "), our default assumption is that you would NOT object to them.

=C2=A0 =C2=A0 With the process now finalized, please take a few minutes and= provide us with your name lists. As a reminder, the deadline is 0800 UTC J= une 4, 2020.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


=C2=A0 =C2=A0 =EF=BB=BFOn 5/19/20, 23:34, "Yaron Sheffer" <yaronf.ietf@gmail.c= om> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 After reviewing the community feedback and disc= ussions with the AD, we=E2=80=99d like to again launch a process to elicit = feedback on naming.=C2=A0 Our proposal is below.=C2=A0 We=E2=80=99d appreci= ate any clarifying questions, proposed improvements or objections by 0800 U= TC, Thursday, May 21st .

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron and Dick=C2= =A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 PS, I=E2=80=99m sharing the load with Dick and = taking point on this consensus call -- Yaron

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Before we submit the draft charter [1] to the I= ESG, we wanted to explore the name of the group. During the chartering disc= ussions, some people objected to the BoF name being the WG name.=C2=A0 We= =E2=80=99d like to get consensus on what the WG name should be.=C2=A0 Our f= irst attempt to elicit input [2] wasn=E2=80=99t successful, and this is a s= econd attempt to get consensus from the community.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 To get to consensus, we want to gather preferen= ces on the currently known WG name candidates. Our goal is not to select th= e most popular name -- it is to select a name everyone can live with and en= sure that we understand and weigh any objections there might be with that c= hoice.=C2=A0 To that end, we=E2=80=99d like to elicit your name preferences= in the following way:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(1) In previous discussions, the followin= g candidate names have been voiced (we have listed only these names that re= ceived at least one vote previously):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 * AAuthZ=C2=A0 =C2=A0 Alternative Authorization= Protocol (AAuthZ)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * AZARP=C2=A0 =C2=A0 AuthoriZed Access to Resou= rces Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * AZARAP=C2=A0 =C2=A0 AuthoriZation And Resourc= e Access Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * BeBAuthZ=C2=A0 =C2=A0 Back-end Based Authoriz= ation Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * BYOAuthZ=C2=A0 =C2=A0 Build-Your-Own Authoriz= ation Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * CPAAP=C2=A0 =C2=A0 Comprehensive Privileged A= uthentication Authorization Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * DAZARAP=C2=A0 =C2=A0 Delegated AuthoriZation = And Resource Access Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * DIYAuthZ=C2=A0 =C2=A0 Do-It-Yourself Authoriz= ation Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * GNAP=C2=A0 =C2=A0 Grant Negotiation and Autho= rization Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * GranPro=C2=A0 =C2=A0 GRAnt Negotiation Protoc= ol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * IDPAuthZ=C2=A0 =C2=A0 Intent Driven Protocol = for Authorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * NIRAD=C2=A0 =C2=A0 Negotiation of Intent Regi= stration and Authority Delegation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * PAuthZ=C2=A0 =C2=A0 Protocol for Authorizatio= n
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * RefAuthZ=C2=A0 =C2=A0 Refactored Authorizatio= n Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * ReAuthZ=C2=A0 =C2=A0 Reimagined Authorization= Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TIAAP=C2=A0 =C2=A0 Tokenized Identity and Acc= ess Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TIDEAuth=C2=A0 =C2=A0 Trust via Intent Driven= Extension Auth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TIDYAuth=C2=A0 =C2=A0 Trust via Intent Driven= Yield Auth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TIEAuth=C2=A0 =C2=A0 Trust via Intent Extensi= on Auth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TINOA=C2=A0 =C2=A0This Is Not OAuth
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TXAuth=C2=A0 =C2=A0 Testable eXtensible Autho= rization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TxAuth=C2=A0 =C2=A0 =C2=A0 Transmission of Au= thority
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TXAuth=C2=A0 =C2=A0 =C2=A0 Truly eXtensible A= uthorization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * XAuthZ=C2=A0 =C2=A0 eXtensible authoriZation = protocol

=C2=A0 =C2=A0 =C2=A0 =C2=A0 We would ask that you consider these names, and= respond to the list with your selection of the following two categories:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =E2=80=9CWouldn=E2=80=99t Object=E2=80=9D -- = this is not necessarily your preferred name, but you would be comfortable w= ith it being the name of the WG (choose as many names as you want)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * =E2=80=9CObject=E2=80=9D -- you would be unco= mfortable with the WG being named in this way (choose as many names as you = want; please provide an explanation)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (2) If your preferred name isn=E2=80=99t in the= list per (1), you can send a note to the mailing list stating that you=E2= =80=99d like the WG to consider a new name.=C2=A0 Please ensure the name ad= heres to the previously discussed naming criteria at [3]. We still request = that you provide your other preferences and objections.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (3) If you previously sent in your preferences,= but a new name suggestion or someone=E2=80=99s objection changed your mind= , then send another message to the mailing list with your revised preferenc= es.=C2=A0 For the purposes of consensus, we=E2=80=99ll assume that everyone= who hasn=E2=80=99t commented on a new name introduced per (2) =E2=80=9Cobj= ects=E2=80=9D to it (i.e., we want to hear positive confirmation of prefere= nce on new names).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (4) Please provide your input by 0800 UTC June = 4, 2020.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 With that input, our plan is to assess rough co= nsensus in the following way:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (a) See if there is consensus for a name identi= fied given the =E2=80=9Cwouldn=E2=80=99t object to being the WG name=E2=80= =9D preference and the level of =E2=80=9Cwould object=E2=80=9D feedback

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (b) If there isn=E2=80=99t clear consensus with= (a), but a significantly reduced set of candidates around which there is e= nthusiasm, the chairs will share the results and request feedback

=C2=A0 =C2=A0 =C2=A0 =C2=A0 (c) If rough consensus appears to be reached th= rough steps (a) =E2=80=93 (b), revisit the objections to this candidate nam= e, elicit additional objections and see if they change the consensus.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron and Dick

=C2=A0 =C2=A0 =C2=A0 =C2=A0 [1] https://datatra= cker.ietf.org/doc/charter-ietf-txauth/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [2] https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VTqkYi0= Wg/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [3] https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnU= a8/




--
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=

--0000000000008926c905a73078b7-- From nobody Wed Jun 3 09:25:48 2020 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 282273A0884 for ; Wed, 3 Jun 2020 09:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 IAiLvra_I3I1 for ; Wed, 3 Jun 2020 09:25:44 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450: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 509083A08A6 for ; Wed, 3 Jun 2020 09:25:41 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id x22so1714497lfd.4 for ; Wed, 03 Jun 2020 09:25:41 -0700 (PDT) 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=jzb4kZq1v8ulN/YOS7Xwe2FR/eXvFMLEV6OLZVbF2NM=; b=ODKEb0JbmoACDEcyTrCxsXDxU0WRxAuq/PPL2CGweur/lTHFb8K21kE4em58DmknPY ItBABkO/0dnSLogmqx035dAQI7PRv9UIC6ot83xR11sSiEpv93jOQrUZNSM1SxC/dcZ4 5dS+phhXu+MW02vlzmmXjjcPkCQMvppNeXqISw++8xkCVW6+ejkgEntyx0JSK9RPop3b 5zjPnp95Hv/NNaKz4UaSwXqHmDJOBjZw6txzPKyNosFoc7VR88wdOYah8NYWvZuB2YbD MbNMzzwiKsshTEPxWPjaR5H4m0PPzQcZe8008B6eofwzXQgg4VRI9sOqTYkdibDxOx6u Pl8A== 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=jzb4kZq1v8ulN/YOS7Xwe2FR/eXvFMLEV6OLZVbF2NM=; b=Gxd5Ch1eetQnLUeoc608SS10NRgkENY7hXje06dU9BJDy+bW75py/G736L4V29o5jT WXAPl+yVK0h53GaYHzFJref+jD6EB9RVwdLTNOedNwduzDALkLjPfqueqj/aPd1IU77X TsNU/9TaA9jQYTHNUUpxhU6N2f0pwpAYHVsNVWBU+EODeXYdXTVeaoiwjOLgKJ+674z4 FRYUGXVXW2C1yGBTpW8mYUlvKbZsV+kEmEAPLjj3K6ASAFC1SdU2svFW1dIHSNnx8pER b+Y+4YxlSaQEjieoISGZJ92JBpJnRkHgtt8S25M0vb+v9Pi8kyeLjBlW3aWyO52h9ZTO 7Flg== X-Gm-Message-State: AOAM533xIAIOYtr76e+bHMMUMga6haTZ7mZHQgGKEkv1WOQrbI3uU1JX EZsr6+Em2DZUzfJxPU7dSGYVXyxZ2taCniGIrVo68al3 X-Google-Smtp-Source: ABdhPJxgBgjs2MXzaeNKrW9gVjCx+cNNnzIzyMYBgsCMdMrPcJDxIkYMgr8YDtyMtHPE/SL4kYUV6T7BuYAcdUIt7kg= X-Received: by 2002:a19:150:: with SMTP id 77mr153706lfb.71.1591201539222; Wed, 03 Jun 2020 09:25:39 -0700 (PDT) MIME-Version: 1.0 References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> <3E18041D-DDF1-4DFD-ACA2-8C37E46495D7@mit.edu> In-Reply-To: <3E18041D-DDF1-4DFD-ACA2-8C37E46495D7@mit.edu> From: Dick Hardt Date: Wed, 3 Jun 2020 09:25:12 -0700 Message-ID: To: Justin Richer Cc: "txauth@ietf.org" Content-Type: multipart/related; boundary="000000000000830ded05a7307a69" Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 03 Jun 2020 16:25:47 -0000 --000000000000830ded05a7307a69 Content-Type: multipart/alternative; boundary="000000000000830dea05a7307a68" --000000000000830dea05a7307a68 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Justin Your objection to extensibility is: "Extensibility is not a differentiating feature of this work." I don't see "differentiating feature" in our selection criteria[1], We do have the following selection criteria: "4. Descriptive of protocol" And given how we are explicit in the extensibility, I would consider it descriptive of the protocol. As to the original OAuth 1.0 charter (which talks about extending OAuth 1.0 to create OAuth 1.1), extensibility was not a focus area, and definitely was not a major consideration in creating OAuth 2.0. I think careful considerations of extension points will allow this work to be a protocol rather than a framework, not the other way around. As an example, in the current XAuth document, both the authorization and claims objects contain name spaced schemas so that the protocol can be extended with other schemas than the original schemas. For example, there are other schemas for identity claims than what is in OpenID Connect. [1] https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/ On Wed, Jun 3, 2020 at 5:19 AM Justin Richer wrote: > Hi Dick, > > Yes, I am pretty familiar with the charter text, but thank you for postin= g > it to the group as a reminder. > > The original charter text for the OAuth WG[1] does in fact call out > extensibility explicitly in several places, including: > > The Working Group will produce one or more documents > suitable for consideration as Proposed Standard that will: > > ... > * Provide guidelines for extensibility. > > > The difference here is that we=E2=80=99re being more explicit about what = is > extensible and how, in the charter. But one of the biggest innovations in > OAuth 2, as I=E2=80=99m sure you know, is that it allowed for explicit > extensibility in ways that OAuth 1 did not: grant types, token types, > scopes (and therefore resource types), client auth types (and therefore > client types), etc. The very fact that OAuth 2 is a *framework* > fundamentally speaks to its goals of extensibility. > > The TxAuth charter text that you quoted carries much of that tradition > forward, which is why I said that extensibility is not a :defining: featu= re > of this work. It=E2=80=99s absolutely a feature and an important one, but > extensibility itself is hardly new or unique as a goal. What=E2=80=99s un= ique is > :what: we=E2=80=99re targeting for extensibility points, which is why tho= se are > listed below in the proposed charter text. > > I also worry that a focus on =E2=80=98extensibility=E2=80=99 above all el= se will slide us > back into the world of incompatible framework pieces. As the proposed > charter also states that we=E2=80=99re building a protocol, not a framewo= rk, this > is counter to what we=E2=80=99re coming together for. > > =E2=80=94 Justin > > [1] > https://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2009-05-13.= txt > > On Jun 2, 2020, at 5:58 PM, Dick Hardt wrote: > > Hey Justin, > > Per your comment "Extensibility is not a differentiating feature of this > work.", extensibility is explicitly called out in the charter (and is not > in the OAuth WG charter): > > > 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 > - Mechanisms for conveying user, software, organization, and other pieces > of information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding > resource requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information through the delegation > process (including identifiers and identity assertions) > > Milestones to include: > > - Guidelines for use of protocol extension points > > > [1] https://datatracker.ietf.org/wg/txauth/about/ > > [image: image.gif] > > > > > =E1=90=A7 > > On Thu, May 28, 2020 at 2:47 PM Justin Richer wrote: > >> Thanks to everyone in the community for suggesting names, and thanks to >> the chairs for putting this list together. >> >> Here=E2=80=99s my personal take on the candidates. >> >> >> >> *Wouldn=E2=80=99t Object:* >> >> * TxAuth Transmission of Authority >> This is my personal favorite of the lot because it avoids the >> =E2=80=9Cauthorization/authentication=E2=80=9D question and gets at the = heart of what this >> protocol does: delegation, which is to say, transmitting the authority t= o >> do something from one party to another. That delegation allows for >> authorized access to resources, but can also allow different rights to f= low >> as needed. Additionally, =E2=80=9Ctx=E2=80=9D has long been used to stan= d for >> =E2=80=9Ctransmission=E2=80=9D in computer science and networking. >> >> * AZARP AuthoriZed Access to Resources Protocol >> The use of =E2=80=9CAZ=E2=80=9D to stand for =E2=80=9Cauthorized=E2=80= =9D is awkward, but the >> pronunciation kinda works as something memorable. The expansion is a twi= st >> of words to make it fit, and I like that less. >> Resource access is only part of the story, but it=E2=80=99s an important= part. >> This leaves out what we want to do around non-authorization cases (like >> identity conveyance). >> >> * AZARAP AuthoriZation And Resource Access Protocol >> I like the expansion here more than the one for AZARP but I like the >> acronym less with the additional =E2=80=9CA=E2=80=9D. >> Same comment as above for AZ standing for Authorization. >> Same comment as above for resource access. >> >> * DAZARAP Delegated AuthoriZation And Resource Access Protocol >> I like the expansion here, but the acronym is awkward and weak. >> Same comment as above for AZ standing for Authorized. >> Same comment as above for resource access. >> >> * GNAP Grant Negotiation and Authorization Protocol >> This is ok, but it has a couple downsides. The pronunciation of a hard >> =E2=80=9Cg=E2=80=9D or not is going to potentially be confusing, as is t= he fact that it >> looks like it=E2=80=99s part of the GNU project because of that. >> The term =E2=80=9CGrant=E2=80=9D is one of the more confusing things tha= t was introduced >> in OAuth 2, and while it=E2=80=99s established in the lexicon today, I= =E2=80=99ve yet to >> meet many engineering teams that actually know what a =E2=80=9Cgrant=E2= =80=9D is. Most >> think it=E2=80=99s another name for the authorization code. >> Also it means =E2=80=9Cto bite=E2=80=9D, which may or may not be desirab= le. >> >> * NIRAD Negotiation of Intent Registration and Authority Delegation >> This is a somewhat weak construct, but it mostly works. It spells out >> more what the protocol will do (if we go with the currently proposed >> solution designs) than what it solves, but that might be ok. >> It makes me think of NORAD (a positive, they do weather radar and track >> Santa Claus each year), but also =E2=80=9Cnimrod=E2=80=9D, a pejorative = term. And before >> anyone chimes in with =E2=80=9CBut Nimrod was a mighty hunter of ancient= times=E2=80=9D, it >> doesn=E2=80=99t mean that to any modern listener. >> >> * GATAR Grant Authorization To Access Resources >> This one isn=E2=80=99t bad, and I can appreciate the =E2=80=9Cguitar=E2= =80=9D pronunciation and >> imagery. As above, resource access isonly part of the story. >> Same comment about =E2=80=9CGrant=E2=80=9D as above in GNAP. >> >> >> >> *Object:* >> >> * AAuthZ Alternative Authorization Protocol (AAuthZ) >> It=E2=80=99s an alternative to what, exactly? And what happens when some= one makes >> an alternative to it? >> The focus on =E2=80=9CAuthorization=E2=80=9D as a core part of the name = tells only part >> of the story. >> Assuming the =E2=80=9CZ=E2=80=9D is pronounced as its letter name (which= is implied by >> the capitalization), there=E2=80=99s an issue with pronouncing the final= =E2=80=9CZ=E2=80=9D as >> either =E2=80=9CZee=E2=80=9D or =E2=80=9CZed=E2=80=9D depending on diale= ct. If it=E2=80=99s not pronounced as a >> letter, it=E2=80=99s really difficult to say the consonants =E2=80=9Cthz= " together in a way >> that can be heard and understood. >> >> * BeBAuthZ Back-end Based Authorization Protocol >> The definition of =E2=80=9Cback end=E2=80=9D is going to change dependin= g on your >> perspective in the stack, but even if it were consistent, the flexibilit= y >> around user interaction is a huge motivator for many getting involved in >> this work. >> This is close to =E2=80=9CBBAuth=E2=80=9D, which was a commercial predec= essor to OAuth 1, >> so much that it=E2=80=99s nearly impossible to disambiguate when talking= . >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >> >> * BYOAuthZ Build-Your-Own Authorization Protocol >> This is the opposite of what we=E2=80=99re doing here. We don=E2=80=99t = want a bunch of >> disparate pieces that people can use to build a protocol, we want a >> protocol with the right kind of flexibility to fit different use cases. >> This name tells developers that they aren=E2=80=99t getting a solution a= nd >> incompatibility is likely. >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >> >> * CPAAP Comprehensive Privileged Authentication Authorization Protoco= l >> This makes me think of CPAP, a breathing assistance device. Not somethin= g >> I=E2=80=99m keen to call to mind in the middle of a global pandemic of a >> respiratory disease. >> The expansion doesn=E2=80=99t really tell me anything. >> What does =E2=80=9Cprivileged=E2=80=9D mean here, and does it apply to t= he authentication >> (which seems implied)? >> >> * DIYAuthZ Do-It-Yourself Authorization Protocol >> As above in BYOAuthZ, this is the opposite of what we=E2=80=99re trying = to do by >> creating a standard. >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >> >> * GranPro GRAnt Negotiation Protocol >> The acronym is a really awkward construction. >> As above, =E2=80=9Cgrant=E2=80=9D is an often misunderstood term from OA= uth 2. Plus, the >> =E2=80=9Cgrant=E2=80=9D isn=E2=80=99t really what=E2=80=99s being negoti= ated here. >> >> * IDPAuthZ Intent Driven Protocol for Authorization >> =E2=80=9CIDP=E2=80=9D is already well understood in this space to mean = =E2=80=9Cidentity >> provider=E2=80=9D, so we should not try to overload it. >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >> >> * PAuthZ Protocol for Authorization >> It was suggested this would be pronounced =E2=80=9Cpaws=E2=80=9D but I c= an=E2=80=99t think of a >> single reason someone looking at the word would try to pronounce it that >> way. >> It=E2=80=99s also completely generic and doesn=E2=80=99t say anything ab= out the work. >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >> >> * RefAuthZ Refactored Authorization Protocol >> Refactored from what? What if someone refactors this? What are the >> factors? >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >> >> * ReAuthZ Reimagined Authorization Protocol >> The short form is already a short term for =E2=80=9Cre-authorization=E2= =80=9D, which is >> not what we are doing. >> Reimagined from what, and by whom? >> The expansion sounds like it=E2=80=99s imaginary and not real. >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >> >> * TIAAP Tokenized Identity and Access Protocol >> I don=E2=80=99t think =E2=80=9Ctokenized=E2=80=9D is used in a meaningfu= l way here. It produced >> =E2=80=9Ctokens=E2=80=9D, but tokenization is the splitting up of an inp= ut into pieces, >> which is not what=E2=80=99s happening here. >> >> * TIDEAuth Trust via Intent Driven Extension Auth >> The expansion is really awkward. >> It sounds like it=E2=80=99s an extension to an existing protocol (someth= ing that >> we are explicitly NOT doing per the charter). >> >> * TIDYAuth Trust via Intent Driven Yield Auth >> I actually really like the acronym but the expansion is super awkward. >> What is being yielded here? >> >> * TIEAuth Trust via Intent Extension Auth >> What is =E2=80=9Cintent extension=E2=80=9D? >> As above, it sounds like an extension not a protocol. >> >> * TINOA This Is Not OAuth >> This says nothing about what this work is, only what it isn=E2=80=99t. A= nd on >> that regard, it doesn=E2=80=99t matter that this isn=E2=80=99t OAuth. OA= uth 2 isn=E2=80=99t OAuth >> 1, either. >> And given that ease of transition from OAuth 2 is part of the charter, >> this isn=E2=80=99t a helpful distinction. >> >> * TXAuth Testable eXtensible Authorization >> I don=E2=80=99t get the focus on =E2=80=9Ctestable=E2=80=9D in the name.= Testable in what way? >> Can other protocols not be tested? >> Extensibility is not a differentiating feature of this work. >> >> * TXAuth Truly eXtensible Authorization >> Extensibility is not a differentiating feature of this work. >> What makes something =E2=80=9Ctruly extensible=E2=80=9D as opposed to = =E2=80=9Cnot truly >> extensible=E2=80=9D? >> >> * XAuthZ eXtensible authoriZation protocol >> Extensibility is not a differentiating feature of this work. >> The acronym is just pulling random letters from the middle of words in >> the expansion to try to work. >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >> >> * WRAC Web Resource Access Collaboration >> This is not a collaboration protocol or system. Collaboration, within >> computer science, is established to refer to when two or more :people: w= ork >> and communicate together. This protocol does not facilitate human >> communication, and so the use of this term is not appropriate here. >> This is very close to =E2=80=9Cwrack=E2=80=9D which is a common enough E= nglish verb, as >> in =E2=80=9Cwracked nerves=E2=80=9D or =E2=80=9Cto wrack one=E2=80=99s b= rain=E2=80=9D, which derives from the >> medieval torture process of stretching someone over a rack. This >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> > > =E1=90=A7 --000000000000830dea05a7307a68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Justin

Your objection to extensibility is:=C2=A0

"Extens= ibility is not a differentiating feature of this work."

I don't see "differentiating feature"= =C2=A0 in our selection criteria[1],=C2=A0

We do h= ave the following selection criteria:

"4. Descriptive of= protocol"

And given how we are = explicit in the extensibility, I would consider it descriptive of the proto= col.=C2=A0

As to the original OAuth 1.0 charter (w= hich talks about=C2=A0extending OAuth 1.0 to create OAuth 1.1), extensibili= ty was not a focus area, and definitely=C2=A0was not a major consideration = in creating OAuth 2.0. I think careful considerations of extension points w= ill allow this work to be a protocol rather than a framework, not the other= way around. As an example, in the current XAuth document, both the authori= zation and claims objects contain name spaced schemas so that the protocol = can be extended with other schemas than the original schemas. For example, = there are other schemas for identity claims than what is in OpenID Connect.=




<= div dir=3D"ltr">

On Wed, Jun 3, 2020 at 5:19 AM Justin Richer <jricher@mit.edu> wrot= e:
Hi Dick,=

Yes, I am pretty familiar with the charter text, but th= ank you for posting it to the group as a reminder.

The original charter text for the OAuth WG[1] does in fact call out extens= ibility explicitly in several places, including:

T=
he Working Group will produce one or more documents
suitable for consideration as Proposed Standard that will:
= 
 ...
* Provide guidelines for extensibility.

The difference here is that we=E2=80=99re being mo= re explicit about what is extensible and how, in the charter. But one of th= e biggest innovations in OAuth 2, as I=E2=80=99m sure you know, is that it = allowed for explicit extensibility in ways that OAuth 1 did not: grant type= s, token types, scopes (and therefore resource types), client auth types (a= nd therefore client types), etc. The very fact that OAuth 2 is a *framework= * fundamentally speaks to its goals of extensibility.=C2=A0

<= /div>
The TxAuth charter text that you quoted carries much of that trad= ition forward, which is why I said that extensibility is not a :defining: f= eature of this work. It=E2=80=99s absolutely a feature and an important one= , but extensibility itself is hardly new or unique as a goal. What=E2=80=99= s unique is :what: we=E2=80=99re targeting for extensibility points, which = is why those are listed below in the proposed charter text.

<= /div>
I also worry that a focus on =E2=80=98extensibility=E2=80=99 abov= e all else will slide us back into the world of incompatible framework piec= es. As the proposed charter also states that we=E2=80=99re building a proto= col, not a framework, this is counter to what we=E2=80=99re coming together= for.

=C2=A0=E2=80=94 Justin

<= div>[1]=C2=A0https://tools.ietf.org/wg/oaut= h/charters?item=3Dcharter-oauth-2009-05-13.txt

On Jun 2, 2020, at 5:58 PM, Dick Hardt <dick.hardt@gmail.com>= wrote:

Hey Justin,

P= er your comment "Extensibility is not a differentiating feature of thi= s work.", extensibility is explicitly called out in the charter (and i= s not in the OAuth WG charter):

The group will def= ine extension points for this protocol to allow for flexibility in areas in= cluding:

- Cryptographic agility for keys, message= signatures, and proof of possession
- User interaction mechanism= s including web and non-web methods
- Mechanisms for conveying us= er, software, organization, and other pieces of information used in authori= zation decisions
- Mechanisms for presenting tokens to resource s= ervers and binding resource requests to tokens and associated cryptographic= keys
- Optimized inclusion of additional information through the= delegation process (including identifiers and identity assertions)

Milestones to include:
<snip>
-= Guidelines for use of protocol extension points

3D"=




=E1=90=A7

On Thu, May 28, 2020 at 2:47 PM Justin Richer <jricher@mit.edu> = wrote:
Thanks to everyone in the community for suggesting names, and thanks to th= e chairs for putting this list together.

Here=E2= =80=99s my personal take on the candidates.



Wouldn=E2=80=99t Object:

* TxAuth =C2=A0 =C2=A0 =C2=A0Transmission of Authority
This is my personal favorite of the lot becau= se it avoids the =E2=80=9Cauthorization/authentication=E2=80=9D question an= d gets at the heart of what this protocol does: delegation, which is to say= , transmitting the authority to do something from one party to another. Tha= t delegation allows for authorized access to resources, but can also allow = different rights to flow as needed. Additionally, =E2=80=9Ctx=E2=80=9D has = long been used to stand for =E2=80=9Ctransmission=E2=80=9D in computer scie= nce and networking.

* AZARP =C2=A0 =C2=A0AuthoriZed Acce= ss to Resources Protocol
The use of =E2=80=9CAZ=E2=80=9D to stand for =E2=80=9Cauthorized= =E2=80=9D is awkward, but the pronunciation kinda works as something memora= ble. The expansion is a twist of words to make it fit, and I like that less= .
Resource access is= only part of the story, but it=E2=80=99s an important part. This leaves ou= t what we want to do around non-authorization cases (like identity conveyan= ce).

* AZARAP =C2=A0 =C2=A0AuthoriZation And Resource A= ccess Protocol
I lik= e the expansion here more than the one for AZARP but I like the acronym les= s with the additional =E2=80=9CA=E2=80=9D.
Same comment as above for AZ standing for Authorizat= ion.
Same comment as= above for resource access.

* DAZARAP =C2=A0 =C2=A0Deleg= ated AuthoriZation And Resource Access Protocol
I like the expansion here, but the acrony= m is awkward and weak.=C2=A0
Same comment as above for AZ standing for Authorized.
Same comment as above for r= esource access.

* GNAP =C2=A0 =C2=A0Grant Ne= gotiation and Authorization Protocol
This is ok, but it has a couple downsides. The pronunc= iation of a hard =E2=80=9Cg=E2=80=9D or not is going to potentially be conf= using, as is the fact that it looks like it=E2=80=99s part of the GNU proje= ct because of that.
= The term =E2=80=9CGrant=E2=80=9D is one of the more confusing things that w= as introduced in OAuth 2, and while it=E2=80=99s established in the lexicon= today, I=E2=80=99ve yet to meet many engineering teams that actually know = what a =E2=80=9Cgrant=E2=80=9D is. Most think it=E2=80=99s another name for= the authorization code.
Also it means =E2=80=9Cto bite=E2=80=9D, which may or may not be desir= able.

* NIRAD =C2=A0 =C2=A0Negotiation of Intent R= egistration and Authority Delegation
This is a somewhat weak construct, but it mostly works= . It spells out more what the protocol will do (if we go with the currently= proposed solution designs) than what it solves, but that might be ok.
It makes me think of NOR= AD (a positive, they do weather radar and track Santa Claus each year), but= also =E2=80=9Cnimrod=E2=80=9D, a pejorative term. And before anyone chimes= in with =E2=80=9CBut Nimrod was a mighty hunter of ancient times=E2=80=9D,= it doesn=E2=80=99t mean that to any modern listener.

<= div>* GATAR =C2=A0 =C2=A0 =C2=A0Grant Authorization To Access Resources=C2= =A0
This one isn=E2= =80=99t bad, and I can appreciate the =E2=80=9Cguitar=E2=80=9D pronunciatio= n and imagery. As above, resource access isonly part of the story.
Same comment about =E2=80=9C= Grant=E2=80=9D as above in GNAP.


Object:

* AAuthZ =C2=A0 =C2=A0Alter= native Authorization Protocol (AAuthZ)
It=E2=80=99s an alternative to what, exactly? And what h= appens when someone makes an alternative to it?
The focus on =E2=80=9CAuthorization=E2=80=9D as= a core part of the name tells only part of the story.=C2=A0
Assuming the =E2=80=9CZ=E2=80=9D i= s pronounced as its letter name (which is implied by the capitalization),= =C2=A0there=E2=80=99s an issue with pronouncing the final =E2=80=9CZ=E2=80= =9D as either =E2=80=9CZee=E2=80=9D or =E2=80=9CZed=E2=80=9D depending on d= ialect. If it=E2=80=99s not pronounced as a letter, it=E2=80=99s really dif= ficult to say the consonants =E2=80=9Cthz" together in a way that can = be heard and understood.

* BeBAuthZ =C2=A0 =C2=A0Back-end Bas= ed Authorization Protocol
<= /span>The definition of =E2=80=9Cback end=E2=80=9D is going to change depen= ding on your perspective in the stack, but even if it were consistent, the = flexibility around user interaction is a huge motivator for many getting in= volved in this work.
This is close to =E2=80=9CBBAuth=E2=80=9D, which was a commercial predeces= sor to OAuth 1, so much that it=E2=80=99s nearly impossible to disambiguate= when talking.
Same = comment as above focus on Authorization.
Same comment as above about Zed/Zee confusion.

* BYOAuthZ =C2=A0 =C2=A0Build-Your-Own Authorization Protocol
<= div> This is the opposite of wh= at we=E2=80=99re doing here. We don=E2=80=99t want a bunch of disparate pie= ces that people can use to build a protocol, we want a protocol with the ri= ght kind of flexibility to fit different use cases. This name tells develop= ers that they aren=E2=80=99t getting a solution and incompatibility is like= ly.
Same commen= t as above focus on Authorization.
Same comment as above about Zed/Zee confusion.

* CPAAP =C2=A0 =C2=A0Comprehensive Privileged Authenticat= ion Authorization Protocol
= This makes me think of CPAP, a breathing assistance device. Not some= thing I=E2=80=99m keen to call to mind in the middle of a global pandemic o= f a respiratory disease.
The expansion doesn=E2=80=99t really tell me anything.
What does =E2=80=9Cprivileged=E2=80= =9D mean here, and does it apply to the authentication (which seems implied= )?

* DIYAuthZ =C2=A0 =C2=A0Do-It-Yourself Authoriz= ation Protocol
As ab= ove in BYOAuthZ, this is the opposite of what we=E2=80=99re trying to do by= creating a standard.=C2=A0
Same comment as above focus on Authorization.
<= span style=3D"white-space:pre-wrap"> Same comment as above about Zed= /Zee confusion.

* GranPro =C2=A0 =C2=A0GRAnt Nego= tiation Protocol
The= acronym is a really awkward construction.=C2=A0
As above,=C2=A0=E2=80=9Cgrant=E2=80=9D is an o= ften misunderstood term from OAuth 2. Plus, the =E2=80=9Cgrant=E2=80=9D isn= =E2=80=99t really what=E2=80=99s being negotiated here.

* IDP= AuthZ =C2=A0 =C2=A0Intent Driven Protocol for Authorization
=E2=80=9CIDP=E2=80=9D is already we= ll understood in this space to mean =E2=80=9Cidentity provider=E2=80=9D, so= we should not try to overload it.
Same comment as above focus on Authorization.
<= span style=3D"white-space:pre-wrap"> Same comment as above about Zed= /Zee confusion.

* PAuthZ =C2=A0 =C2=A0Protocol fo= r Authorization
It w= as suggested this would be pronounced =E2=80=9Cpaws=E2=80=9D but I can=E2= =80=99t think of a single reason someone looking at the word would try to p= ronounce it that way.=C2=A0
= It=E2=80=99s also completely generic and doesn=E2=80=99t say anythi= ng about the work.
Same comment as above focus on Authorization.
Same comment as above about Zed/Zee confusion.<= /div>

* RefAuthZ =C2=A0 =C2=A0Refactored Authorization = Protocol
Refactored = from what? What if someone refactors this? What are the factors?
Same comment as above focus= on Authorization.
S= ame comment as above about Zed/Zee confusion.

* R= eAuthZ =C2=A0 =C2=A0Reimagined Authorization Protocol
The short form is already a short term for =E2= =80=9Cre-authorization=E2=80=9D, which is not what we are doing.
Reimagined from what,= and by whom?
The ex= pansion=C2=A0sounds like it=E2=80=99s imaginary and not real.
Same comment as above f= ocus on Authorization.
Same comment as above about Zed/Zee confusion.

* TIAAP =C2=A0 =C2=A0Tokenized Identity and Access Protocol
I don=E2=80=99t think =E2=80=9Ctok= enized=E2=80=9D is used in a meaningful way here. It produced =E2=80=9Ctoke= ns=E2=80=9D, but tokenization is the splitting up of an input into pieces, = which is not what=E2=80=99s happening here.

* TIDEAuth =C2=A0= =C2=A0Trust via Intent Driven Extension Auth
The expansion is really awkward.
It sounds like it=E2=80=99s an exten= sion to an existing protocol (something that we are explicitly NOT doing pe= r the charter).

= * TIDYAuth =C2=A0 =C2=A0Trust via Intent Driven Yield Auth
I actually really like the acronym b= ut the expansion is super awkward. What is being yielded here?
* TIEAuth =C2=A0 =C2=A0Trust via Intent Extension Auth
What is =E2=80=9Cintent extension=E2= =80=9D?=C2=A0
As abo= ve, it sounds like an extension not a protocol.

* TINOA =C2= =A0 This Is Not OAuth
This says nothing about what this work is, only what it isn=E2=80=99t. An= d on that regard,=C2=A0it doesn=E2=80=99t matter that this isn=E2=80=99t OA= uth. OAuth 2 isn=E2=80=99t OAuth 1, either.=C2=A0
And given that ease of transition from OAuth = 2 is part of the charter, this isn=E2=80=99t a helpful distinction.

* TXAuth =C2=A0 =C2=A0Testable eXtensible Authorization
I don=E2=80=99t get the focus on= =E2=80=9Ctestable=E2=80=9D in the name. Testable in what way? Can other pr= otocols not be tested?
= Extensibility is not a differentiating feature of this work.
<= div>
* TXAuth =C2=A0 =C2=A0 =C2=A0Truly eXtensible Authorization
Extensibility is not a = differentiating feature of this work.
What makes something =E2=80=9Ctruly extensible=E2=80=9D a= s opposed to =E2=80=9Cnot truly extensible=E2=80=9D?

* = XAuthZ =C2=A0 =C2=A0eXtensible authoriZation protocol
Extensibility is not a differentiating= feature of this work.
The acronym is just pulling random letters from the middle of words in t= he expansion to try to work.
Same comment as above focus on Authorization.
Same comment as above about Zed/Zee conf= usion.

* WRAC =C2=A0 =C2=A0 Web Resource Access C= ollaboration
This is= not a collaboration protocol or system. Collaboration, within computer sci= ence, is established to refer to when two or more :people: work and communi= cate together. This protocol does not facilitate human communication, and s= o the use of this term is not appropriate here.=C2=A0
This is very close to=C2=A0=E2=80=9Cwrack= =E2=80=9D which is a common enough English verb, as in =E2=80=9Cwracked ner= ves=E2=80=9D or =E2=80=9Cto wrack one=E2=80=99s brain=E2=80=9D, which deriv= es from the medieval torture process of stretching someone over a rack. Thi= s=C2=A0

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

3D""=E1=90=A7
--000000000000830dea05a7307a68-- --000000000000830ded05a7307a69 Content-Type: image/gif; name="image.gif" Content-Disposition: inline; filename="image.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_kazjwj3b5 R0lGODlhAQABAPAAAAAAAAAAACH5BAUAAAAALAAAAAABAAEAAAICRAEAOw== --000000000000830ded05a7307a69-- From nobody Wed Jun 3 12:09:04 2020 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 139123A0EC1 for ; Wed, 3 Jun 2020 12:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, 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 Qd1gGsI4YFYd for ; Wed, 3 Jun 2020 12:09:02 -0700 (PDT) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 CE7EB3A0EC7 for ; Wed, 3 Jun 2020 12:09:01 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id r16so1689588qvm.6 for ; Wed, 03 Jun 2020 12:09:01 -0700 (PDT) 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=Zx1lxwC3BAgO8zC5amJ/QdjS7vDnifTvd+gTGnB1tLQ=; b=iC6MoyqX3AMBHc7ByXnvZhFzI8TsSOdoyBfhMUJm6BbaEv5dhS8KoTBPVNUupOOx02 xOjRzNCLBi3UJwI9ie/acModjXPIlGpXm4vQM8E4CkXhCBKGISQx+8lIZFqC/zOHQLgF 2VHexQ89xYJebTZ39TasTDUMdgK6vw7VmqbDB5ePPnkLJ4zQicCADMxFi+VKlv722FG3 7vng3zmauQ6oZxkne9zojnoGKJ/HFKWZ9XpeTw8cEr4KhZpeZWkAyFLr2W6xdsvHLiBK FnwFWPRNWI0kB6+Iry+aNvgYdR7VujQrotVl+DA6rTnIkUuJIDXUKIxblV36Kf8wF7Xz ZK7A== 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=Zx1lxwC3BAgO8zC5amJ/QdjS7vDnifTvd+gTGnB1tLQ=; b=dQEOGcVvyna0QViKI72GfCGh04onsX33j5O4VLxhMycRBfAA+bf4WcZZ8Q4Upun5oL SCkr+d6BUTvU+QEhO/MC5cMAB5vWBwAxfOMIo9WQzVavjyf5gZkkwGbkLrWLopKeL+8T n9gqnvocxLtrs5rak/jVjGutzwEtB1+3/rgKACCObYQUSG94fVPddL+ZFAfLa02/l6TX VDosy4LoXXlWH+qEe5uIOTmU/mcGK1Lj7Nzic7rNYDF3ER1i981JxLAP3OKnyPIgmMPr H3+sWXWOvfys/no7ZMVa8AW64EGT+kpKfw82zNOLtdhmsN1E8FZREFt+NUhC+CkjTuLS Islg== X-Gm-Message-State: AOAM530FJQrGwGeZKseQyk2mIp7bBTc5BHnwD4N2BPwa0paT/zUZsc6f qsaQLwzyHB8Qd5f413IsHj3SiB4wE+4eQ1t8jXNpyABW8Qk= X-Google-Smtp-Source: ABdhPJzW766K3ShpIfUvaT7YcHocPpWbtyaZQcHpdOd0GJNbr3gjtttFSx6yOGb9rb3cHp/RwAaV9O5gwTcAjeIrpCg= X-Received: by 2002:a05:6214:178e:: with SMTP id ct14mr1330196qvb.73.1591211340474; Wed, 03 Jun 2020 12:09:00 -0700 (PDT) MIME-Version: 1.0 From: Dmitry Barinov Date: Wed, 3 Jun 2020 15:08:49 -0400 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000b62d3905a732c214" Archived-At: Subject: [Txauth] WG name preference 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, 03 Jun 2020 19:09:03 -0000 --000000000000b62d3905a732c214 Content-Type: text/plain; charset="UTF-8" Would not object 1. TxAuth - Transmission of Authority Describes the scope of work well. 2. GNAP - Grant Negotiation and Authorization Protocol Like the idea that "Grant" will be actually properly described to avoid ambiguity in the future --000000000000b62d3905a732c214 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would not object
1.=C2=A0TxAuth - Transmission of = Authority
Describes the scope= of work well.=C2=A0
2.=C2=A0 GNAP - Grant Negotiation and Authorization Protocol=
Like the idea that "Grant"= ; will be actually properly described to avoid ambiguity in the future

<= div>




--000000000000b62d3905a732c214-- From nobody Wed Jun 3 12:36:53 2020 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 CA83F3A0EA7 for ; Wed, 3 Jun 2020 12:36:51 -0700 (PDT) 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 OedAubdfmMZU for ; Wed, 3 Jun 2020 12:36:48 -0700 (PDT) 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 BE7AA3A0EAF for ; Wed, 3 Jun 2020 12:36:47 -0700 (PDT) Received: from [192.168.1.12] (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 053Jai2u001336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 3 Jun 2020 15:36:45 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E811CE76-1F88-43BF-BD41-35812196004A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 3 Jun 2020 15:36:44 -0400 In-Reply-To: Cc: "txauth@ietf.org" To: Dick Hardt References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> <3E18041D-DDF1-4DFD-ACA2-8C37E46495D7@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 03 Jun 2020 19:36:52 -0000 --Apple-Mail=_E811CE76-1F88-43BF-BD41-35812196004A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My objection is that it is not a sufficient description of the work. = Please understand that I agree that extensibility is important, as = it=E2=80=99s been built into XYZ across all of the various dimensions in = our proposed charter from the project=E2=80=99s inception. However, = there=E2=80=99s a lot more going on here and I don=E2=80=99t thing = simply saying it=E2=80=99s =E2=80=9Cextensible=E2=80=9D is any more = helpful than saying it=E2=80=99s =E2=80=9Cnew=E2=80=9D. OAuth 2 is = already pretty extensible, and people are extending it today to do a lot = of important things. I don=E2=80=99t agree with you that extensibility = was not a design factor in OAuth 2, either. =E2=80=94 Justin > On Jun 3, 2020, at 12:25 PM, Dick Hardt wrote: >=20 > Justin >=20 > Your objection to extensibility is:=20 >=20 > "Extensibility is not a differentiating feature of this work." >=20 > I don't see "differentiating feature" in our selection criteria[1],=20= >=20 > We do have the following selection criteria: >=20 > "4. Descriptive of protocol" >=20 > And given how we are explicit in the extensibility, I would consider = it descriptive of the protocol.=20 >=20 > As to the original OAuth 1.0 charter (which talks about extending = OAuth 1.0 to create OAuth 1.1), extensibility was not a focus area, and = definitely was not a major consideration in creating OAuth 2.0. I think = careful considerations of extension points will allow this work to be a = protocol rather than a framework, not the other way around. As an = example, in the current XAuth document, both the authorization and = claims objects contain name spaced schemas so that the protocol can be = extended with other schemas than the original schemas. For example, = there are other schemas for identity claims than what is in OpenID = Connect. >=20 >=20 >=20 > [1] = https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/ = >=20 >=20 >=20 > On Wed, Jun 3, 2020 at 5:19 AM Justin Richer > wrote: > Hi Dick, >=20 > Yes, I am pretty familiar with the charter text, but thank you for = posting it to the group as a reminder. >=20 > The original charter text for the OAuth WG[1] does in fact call out = extensibility explicitly in several places, including: >=20 > The Working Group will produce one or more documents > suitable for consideration as Proposed Standard that will: > ... > * Provide guidelines for extensibility. >=20 > The difference here is that we=E2=80=99re being more explicit about = what is extensible and how, in the charter. But one of the biggest = innovations in OAuth 2, as I=E2=80=99m sure you know, is that it allowed = for explicit extensibility in ways that OAuth 1 did not: grant types, = token types, scopes (and therefore resource types), client auth types = (and therefore client types), etc. The very fact that OAuth 2 is a = *framework* fundamentally speaks to its goals of extensibility.=20 >=20 > The TxAuth charter text that you quoted carries much of that tradition = forward, which is why I said that extensibility is not a :defining: = feature of this work. It=E2=80=99s absolutely a feature and an important = one, but extensibility itself is hardly new or unique as a goal. = What=E2=80=99s unique is :what: we=E2=80=99re targeting for = extensibility points, which is why those are listed below in the = proposed charter text. >=20 > I also worry that a focus on =E2=80=98extensibility=E2=80=99 above all = else will slide us back into the world of incompatible framework pieces. = As the proposed charter also states that we=E2=80=99re building a = protocol, not a framework, this is counter to what we=E2=80=99re coming = together for. >=20 > =E2=80=94 Justin >=20 > [1] = https://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2009-05-13.t= xt = >=20 >> On Jun 2, 2020, at 5:58 PM, Dick Hardt > wrote: >>=20 >> Hey Justin, >>=20 >> Per your comment "Extensibility is not a differentiating feature of = this work.", extensibility is explicitly called out in the charter (and = is not in the OAuth WG charter): >>=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 >> - User interaction mechanisms including web and non-web methods >> - Mechanisms for conveying user, software, organization, and other = pieces of information used in authorization decisions >> - Mechanisms for presenting tokens to resource servers and binding = resource requests to tokens and associated cryptographic keys >> - Optimized inclusion of additional information through the = delegation process (including identifiers and identity assertions) >>=20 >> Milestones to include: >> >> - Guidelines for use of protocol extension points >>=20 >> [1] https://datatracker.ietf.org/wg/txauth/about/ = >=20 >=20 >=20 >=20 >> =E1=90=A7 >>=20 >> On Thu, May 28, 2020 at 2:47 PM Justin Richer > wrote: >> Thanks to everyone in the community for suggesting names, and thanks = to the chairs for putting this list together. >>=20 >> Here=E2=80=99s my personal take on the candidates. >>=20 >>=20 >>=20 >> Wouldn=E2=80=99t Object: >>=20 >> * TxAuth Transmission of Authority >> This is my personal favorite of the lot because it avoids the = =E2=80=9Cauthorization/authentication=E2=80=9D question and gets at the = heart of what this protocol does: delegation, which is to say, = transmitting the authority to do something from one party to another. = That delegation allows for authorized access to resources, but can also = allow different rights to flow as needed. Additionally, =E2=80=9Ctx=E2=80=9D= has long been used to stand for =E2=80=9Ctransmission=E2=80=9D in = computer science and networking. >>=20 >> * AZARP AuthoriZed Access to Resources Protocol >> The use of =E2=80=9CAZ=E2=80=9D to stand for =E2=80=9Cauthorized=E2= =80=9D is awkward, but the pronunciation kinda works as something = memorable. The expansion is a twist of words to make it fit, and I like = that less. >> Resource access is only part of the story, but it=E2=80=99s an = important part. This leaves out what we want to do around = non-authorization cases (like identity conveyance). >>=20 >> * AZARAP AuthoriZation And Resource Access Protocol >> I like the expansion here more than the one for AZARP but I like = the acronym less with the additional =E2=80=9CA=E2=80=9D. >> Same comment as above for AZ standing for Authorization. >> Same comment as above for resource access. >>=20 >> * DAZARAP Delegated AuthoriZation And Resource Access Protocol >> I like the expansion here, but the acronym is awkward and weak.=20= >> Same comment as above for AZ standing for Authorized. >> Same comment as above for resource access. >>=20 >> * GNAP Grant Negotiation and Authorization Protocol >> This is ok, but it has a couple downsides. The pronunciation of = a hard =E2=80=9Cg=E2=80=9D or not is going to potentially be confusing, = as is the fact that it looks like it=E2=80=99s part of the GNU project = because of that. >> The term =E2=80=9CGrant=E2=80=9D is one of the more confusing = things that was introduced in OAuth 2, and while it=E2=80=99s = established in the lexicon today, I=E2=80=99ve yet to meet many = engineering teams that actually know what a =E2=80=9Cgrant=E2=80=9D is. = Most think it=E2=80=99s another name for the authorization code. >> Also it means =E2=80=9Cto bite=E2=80=9D, which may or may not be = desirable. >>=20 >> * NIRAD Negotiation of Intent Registration and Authority = Delegation >> This is a somewhat weak construct, but it mostly works. It = spells out more what the protocol will do (if we go with the currently = proposed solution designs) than what it solves, but that might be ok. >> It makes me think of NORAD (a positive, they do weather radar = and track Santa Claus each year), but also =E2=80=9Cnimrod=E2=80=9D, a = pejorative term. And before anyone chimes in with =E2=80=9CBut Nimrod = was a mighty hunter of ancient times=E2=80=9D, it doesn=E2=80=99t mean = that to any modern listener. >>=20 >> * GATAR Grant Authorization To Access Resources=20 >> This one isn=E2=80=99t bad, and I can appreciate the = =E2=80=9Cguitar=E2=80=9D pronunciation and imagery. As above, resource = access isonly part of the story. >> Same comment about =E2=80=9CGrant=E2=80=9D as above in GNAP. >>=20 >>=20 >>=20 >> Object: >>=20 >> * AAuthZ Alternative Authorization Protocol (AAuthZ) >> It=E2=80=99s an alternative to what, exactly? And what happens = when someone makes an alternative to it? >> The focus on =E2=80=9CAuthorization=E2=80=9D as a core part of = the name tells only part of the story.=20 >> Assuming the =E2=80=9CZ=E2=80=9D is pronounced as its letter = name (which is implied by the capitalization), there=E2=80=99s an issue = with pronouncing the final =E2=80=9CZ=E2=80=9D as either =E2=80=9CZee=E2=80= =9D or =E2=80=9CZed=E2=80=9D depending on dialect. If it=E2=80=99s not = pronounced as a letter, it=E2=80=99s really difficult to say the = consonants =E2=80=9Cthz" together in a way that can be heard and = understood. >>=20 >> * BeBAuthZ Back-end Based Authorization Protocol >> The definition of =E2=80=9Cback end=E2=80=9D is going to change = depending on your perspective in the stack, but even if it were = consistent, the flexibility around user interaction is a huge motivator = for many getting involved in this work. >> This is close to =E2=80=9CBBAuth=E2=80=9D, which was a = commercial predecessor to OAuth 1, so much that it=E2=80=99s nearly = impossible to disambiguate when talking. >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >>=20 >> * BYOAuthZ Build-Your-Own Authorization Protocol >> This is the opposite of what we=E2=80=99re doing here. We = don=E2=80=99t want a bunch of disparate pieces that people can use to = build a protocol, we want a protocol with the right kind of flexibility = to fit different use cases. This name tells developers that they = aren=E2=80=99t getting a solution and incompatibility is likely. >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >>=20 >> * CPAAP Comprehensive Privileged Authentication Authorization = Protocol >> This makes me think of CPAP, a breathing assistance device. Not = something I=E2=80=99m keen to call to mind in the middle of a global = pandemic of a respiratory disease. >> The expansion doesn=E2=80=99t really tell me anything. >> What does =E2=80=9Cprivileged=E2=80=9D mean here, and does it = apply to the authentication (which seems implied)? >>=20 >> * DIYAuthZ Do-It-Yourself Authorization Protocol >> As above in BYOAuthZ, this is the opposite of what we=E2=80=99re = trying to do by creating a standard.=20 >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >>=20 >> * GranPro GRAnt Negotiation Protocol >> The acronym is a really awkward construction.=20 >> As above, =E2=80=9Cgrant=E2=80=9D is an often misunderstood term = from OAuth 2. Plus, the =E2=80=9Cgrant=E2=80=9D isn=E2=80=99t really = what=E2=80=99s being negotiated here. >>=20 >> * IDPAuthZ Intent Driven Protocol for Authorization >> =E2=80=9CIDP=E2=80=9D is already well understood in this space = to mean =E2=80=9Cidentity provider=E2=80=9D, so we should not try to = overload it. >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >>=20 >> * PAuthZ Protocol for Authorization >> It was suggested this would be pronounced =E2=80=9Cpaws=E2=80=9D = but I can=E2=80=99t think of a single reason someone looking at the word = would try to pronounce it that way.=20 >> It=E2=80=99s also completely generic and doesn=E2=80=99t say = anything about the work. >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >>=20 >> * RefAuthZ Refactored Authorization Protocol >> Refactored from what? What if someone refactors this? What are = the factors? >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >>=20 >> * ReAuthZ Reimagined Authorization Protocol >> The short form is already a short term for = =E2=80=9Cre-authorization=E2=80=9D, which is not what we are doing. >> Reimagined from what, and by whom? >> The expansion sounds like it=E2=80=99s imaginary and not real. >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >>=20 >> * TIAAP Tokenized Identity and Access Protocol >> I don=E2=80=99t think =E2=80=9Ctokenized=E2=80=9D is used in a = meaningful way here. It produced =E2=80=9Ctokens=E2=80=9D, but = tokenization is the splitting up of an input into pieces, which is not = what=E2=80=99s happening here. >>=20 >> * TIDEAuth Trust via Intent Driven Extension Auth >> The expansion is really awkward. >> It sounds like it=E2=80=99s an extension to an existing protocol = (something that we are explicitly NOT doing per the charter). >> =09 >> * TIDYAuth Trust via Intent Driven Yield Auth >> I actually really like the acronym but the expansion is super = awkward. What is being yielded here? >>=20 >> * TIEAuth Trust via Intent Extension Auth >> What is =E2=80=9Cintent extension=E2=80=9D?=20 >> As above, it sounds like an extension not a protocol. >>=20 >> * TINOA This Is Not OAuth >> This says nothing about what this work is, only what it isn=E2=80=99= t. And on that regard, it doesn=E2=80=99t matter that this isn=E2=80=99t = OAuth. OAuth 2 isn=E2=80=99t OAuth 1, either.=20 >> And given that ease of transition from OAuth 2 is part of the = charter, this isn=E2=80=99t a helpful distinction. >>=20 >> * TXAuth Testable eXtensible Authorization >> I don=E2=80=99t get the focus on =E2=80=9Ctestable=E2=80=9D in = the name. Testable in what way? Can other protocols not be tested? >> Extensibility is not a differentiating feature of this work. >>=20 >> * TXAuth Truly eXtensible Authorization >> Extensibility is not a differentiating feature of this work. >> What makes something =E2=80=9Ctruly extensible=E2=80=9D as = opposed to =E2=80=9Cnot truly extensible=E2=80=9D? >>=20 >> * XAuthZ eXtensible authoriZation protocol >> Extensibility is not a differentiating feature of this work. >> The acronym is just pulling random letters from the middle of = words in the expansion to try to work. >> Same comment as above focus on Authorization. >> Same comment as above about Zed/Zee confusion. >>=20 >> * WRAC Web Resource Access Collaboration >> This is not a collaboration protocol or system. Collaboration, = within computer science, is established to refer to when two or more = :people: work and communicate together. This protocol does not = facilitate human communication, and so the use of this term is not = appropriate here.=20 >> This is very close to =E2=80=9Cwrack=E2=80=9D which is a common = enough English verb, as in =E2=80=9Cwracked nerves=E2=80=9D or =E2=80=9Cto= wrack one=E2=80=99s brain=E2=80=9D, which derives from the medieval = torture process of stretching someone over a rack. This=20 >>=20 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 > =E1=90=A7 --Apple-Mail=_E811CE76-1F88-43BF-BD41-35812196004A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = objection is that it is not a sufficient description = of the work. Please understand that I agree that extensibility is = important, as it=E2=80=99s been built into XYZ across all of the various = dimensions in our proposed charter from the project=E2=80=99s inception. = However, there=E2=80=99s a lot more going on here and I don=E2=80=99t = thing simply saying it=E2=80=99s =E2=80=9Cextensible=E2=80=9D is any = more helpful than saying it=E2=80=99s =E2=80=9Cnew=E2=80=9D. OAuth 2 is = already pretty extensible, and people are extending it today to do a lot = of important things. I don=E2=80=99t agree with you that extensibility = was not a design factor in OAuth 2, either.

 =E2=80=94 Justin

On Jun 3, 2020, at 12:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin

Your objection to extensibility = is: 

"Extensibility is not a differentiating feature of this = work."

I don't see "differentiating feature"  in our selection = criteria[1], 

We do have the following selection criteria:

"4. Descriptive = of protocol"

And given how we are explicit in the extensibility, I would = consider it descriptive of the protocol. 

As to the original OAuth 1.0 charter = (which talks about extending OAuth 1.0 to create OAuth 1.1), = extensibility was not a focus area, and definitely was not a major = consideration in creating OAuth 2.0. I think careful considerations of = extension points will allow this work to be a protocol rather than a = framework, not the other way around. As an example, in the current XAuth = document, both the authorization and claims objects contain name spaced = schemas so that the protocol can be extended with other schemas than the = original schemas. For example, there are other schemas for identity = claims than what is in OpenID Connect.



[1] https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWV= Dcq8rnUa8/



On Wed, Jun 3, 2020 at 5:19 AM Justin Richer <jricher@mit.edu> wrote:
Hi Dick,

Yes, I am pretty = familiar with the charter text, but thank you for posting it to the = group as a reminder.

The original charter text for the OAuth WG[1] does in fact = call out extensibility explicitly in several places, = including:

The Working Group will produce one or more =
documents
suitable for consideration as Proposed Standard that =
will:
 ...
* Provide guidelines for extensibility.

The difference here is that we=E2=80=99re being more explicit = about what is extensible and how, in the charter. But one of the biggest = innovations in OAuth 2, as I=E2=80=99m sure you know, is that it allowed = for explicit extensibility in ways that OAuth 1 did not: grant types, = token types, scopes (and therefore resource types), client auth types = (and therefore client types), etc. The very fact that OAuth 2 is a = *framework* fundamentally speaks to its goals of = extensibility. 

The TxAuth charter text that you quoted carries much of that = tradition forward, which is why I said that extensibility is not a = :defining: feature of this work. It=E2=80=99s absolutely a feature and = an important one, but extensibility itself is hardly new or unique as a = goal. What=E2=80=99s unique is :what: we=E2=80=99re targeting for = extensibility points, which is why those are listed below in the = proposed charter text.

I also worry that a focus on =E2=80=98extensibility=E2=80=99 = above all else will slide us back into the world of incompatible = framework pieces. As the proposed charter also states that we=E2=80=99re = building a protocol, not a framework, this is counter to what we=E2=80=99r= e coming together for.

 =E2=80=94 Justin

[1] https://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2= 009-05-13.txt

On Jun 2, 2020, at 5:58 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

Hey Justin,

Per your comment = "Extensibility is not a differentiating feature of this work.", = extensibility is explicitly called out in the charter (and is not in the = OAuth WG charter):

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
- Mechanisms for conveying user, software, = organization, and other pieces of information used in authorization = decisions
- Mechanisms for presenting tokens to = resource servers and binding resource requests to tokens and associated = cryptographic keys
- Optimized inclusion of = additional information through the delegation process (including = identifiers and identity assertions)

Milestones to include:
<snip>
- Guidelines for use of = protocol extension points

[1] https://datatracker.ietf.org/wg/txauth/about/
<image.gif>




=E1=90=A7

On Thu, May 28, 2020 at 2:47 PM Justin Richer = <jricher@mit.edu> wrote:
Thanks to everyone in the community for suggesting names, and = thanks to the chairs for putting this list together.

Here=E2=80=99s my = personal take on the candidates.



Wouldn=E2=80=99t = Object:

* TxAuth   =    Transmission of Authority
This is my = personal favorite of the lot because it avoids the = =E2=80=9Cauthorization/authentication=E2=80=9D question and gets at the = heart of what this protocol does: delegation, which is to say, = transmitting the authority to do something from one party to another. = That delegation allows for authorized access to resources, but can also = allow different rights to flow as needed. Additionally, =E2=80=9Ctx=E2=80=9D= has long been used to stand for =E2=80=9Ctransmission=E2=80=9D in = computer science and networking.

* AZARP    AuthoriZed Access to Resources = Protocol
The use of = =E2=80=9CAZ=E2=80=9D to stand for =E2=80=9Cauthorized=E2=80=9D is = awkward, but the pronunciation kinda works as something memorable. The = expansion is a twist of words to make it fit, and I like that = less.
Resource access is only part of the story, but = it=E2=80=99s an important part. This leaves out what we want to do = around non-authorization cases (like identity conveyance).

* AZARAP    AuthoriZation And = Resource Access Protocol
I like the = expansion here more than the one for AZARP but I like the acronym less = with the additional =E2=80=9CA=E2=80=9D.
Same comment as = above for AZ standing for Authorization.
Same comment as = above for resource access.

* DAZARAP    Delegated AuthoriZation And Resource = Access Protocol
I like the = expansion here, but the acronym is awkward and weak. 
= Same comment as above for AZ standing for Authorized.
Same comment as above for resource = access.

* = GNAP    Grant Negotiation and Authorization Protocol
This is ok, but it has a couple downsides. The = pronunciation of a hard =E2=80=9Cg=E2=80=9D or not is going to = potentially be confusing, as is the fact that it looks like it=E2=80=99s = part of the GNU project because of that.
The term = =E2=80=9CGrant=E2=80=9D is one of the more confusing things that was = introduced in OAuth 2, and while it=E2=80=99s established in the lexicon = today, I=E2=80=99ve yet to meet many engineering teams that actually = know what a =E2=80=9Cgrant=E2=80=9D is. Most think it=E2=80=99s another = name for the authorization code.
Also it means = =E2=80=9Cto bite=E2=80=9D, which may or may not be desirable.

* NIRAD   =  Negotiation of Intent Registration and Authority Delegation
This is a somewhat weak construct, but it mostly = works. It spells out more what the protocol will do (if we go with the = currently proposed solution designs) than what it solves, but that might = be ok.
It makes me think of NORAD (a positive, they do = weather radar and track Santa Claus each year), but also =E2=80=9Cnimrod=E2= =80=9D, a pejorative term. And before anyone chimes in with =E2=80=9CBut = Nimrod was a mighty hunter of ancient times=E2=80=9D, it doesn=E2=80=99t = mean that to any modern listener.

* GATAR      Grant = Authorization To Access Resources 
This one isn=E2=80=99= t bad, and I can appreciate the =E2=80=9Cguitar=E2=80=9D pronunciation = and imagery. As above, resource access isonly part of the = story.
Same comment about =E2=80=9CGrant=E2=80=9D as = above in GNAP.



Object:

* AAuthZ    Alternative Authorization = Protocol (AAuthZ)
It=E2=80=99s an = alternative to what, exactly? And what happens when someone makes an = alternative to it?
The focus on = =E2=80=9CAuthorization=E2=80=9D as a core part of the name tells only = part of the story. 
Assuming the = =E2=80=9CZ=E2=80=9D is pronounced as its letter name (which is implied = by the capitalization), there=E2=80=99s an issue with pronouncing = the final =E2=80=9CZ=E2=80=9D as either =E2=80=9CZee=E2=80=9D or = =E2=80=9CZed=E2=80=9D depending on dialect. If it=E2=80=99s not = pronounced as a letter, it=E2=80=99s really difficult to say the = consonants =E2=80=9Cthz" together in a way that can be heard and = understood.

* BeBAuthZ   =  Back-end Based Authorization Protocol
The definition of = =E2=80=9Cback end=E2=80=9D is going to change depending on your = perspective in the stack, but even if it were consistent, the = flexibility around user interaction is a huge motivator for many getting = involved in this work.
This is close to = =E2=80=9CBBAuth=E2=80=9D, which was a commercial predecessor to OAuth 1, = so much that it=E2=80=99s nearly impossible to disambiguate when = talking.
Same comment as above focus on = Authorization.
Same comment as above about Zed/Zee = confusion.

* BYOAuthZ   =  Build-Your-Own Authorization Protocol
This is the = opposite of what we=E2=80=99re doing here. We don=E2=80=99t want a bunch = of disparate pieces that people can use to build a protocol, we want a = protocol with the right kind of flexibility to fit different use cases. = This name tells developers that they aren=E2=80=99t getting a solution = and incompatibility is likely.
Same comment as = above focus on Authorization.
Same comment as = above about Zed/Zee confusion.

* CPAAP    Comprehensive = Privileged Authentication Authorization Protocol
= This makes me think of CPAP, a breathing assistance device. Not = something I=E2=80=99m keen to call to mind in the middle of a global = pandemic of a respiratory disease.
The expansion = doesn=E2=80=99t really tell me anything.
What does = =E2=80=9Cprivileged=E2=80=9D mean here, and does it apply to the = authentication (which seems implied)?

* DIYAuthZ    Do-It-Yourself = Authorization Protocol
As above in = BYOAuthZ, this is the opposite of what we=E2=80=99re trying to do by = creating a standard. 
= Same comment as above focus on Authorization.
= Same comment as above about Zed/Zee confusion.

* GranPro    GRAnt Negotiation = Protocol
The acronym is a really awkward = construction. 
As = above, =E2=80=9Cgrant=E2=80=9D is an often misunderstood term from = OAuth 2. Plus, the =E2=80=9Cgrant=E2=80=9D isn=E2=80=99t really what=E2=80= =99s being negotiated here.

* = IDPAuthZ    Intent Driven Protocol for Authorization
= =E2=80=9CIDP=E2=80=9D is already well understood in this space to = mean =E2=80=9Cidentity provider=E2=80=9D, so we should not try to = overload it.
Same comment as = above focus on Authorization.
Same comment as = above about Zed/Zee confusion.

* PAuthZ    Protocol for = Authorization
It was suggested this would be pronounced = =E2=80=9Cpaws=E2=80=9D but I can=E2=80=99t think of a single reason = someone looking at the word would try to pronounce it that = way. 
It=E2=80=99s also completely generic and = doesn=E2=80=99t say anything about the work.
Same comment as above focus on = Authorization.
Same comment as above about Zed/Zee = confusion.

* RefAuthZ =    Refactored Authorization Protocol
Refactored from = what? What if someone refactors this? What are the factors?
Same comment as = above focus on Authorization.
Same comment as = above about Zed/Zee confusion.

* ReAuthZ    Reimagined Authorization = Protocol
= The short form is already a short term for = =E2=80=9Cre-authorization=E2=80=9D, which is not what we are doing.
Reimagined from = what, and by whom?
The = expansion sounds like it=E2=80=99s imaginary and not = real.
Same comment as = above focus on Authorization.
Same comment as = above about Zed/Zee confusion.

* TIAAP    Tokenized Identity and Access = Protocol
I don=E2=80=99t think =E2=80=9Ctokenized=E2=80=9D = is used in a meaningful way here. It produced =E2=80=9Ctokens=E2=80=9D, = but tokenization is the splitting up of an input into pieces, which is = not what=E2=80=99s happening here.

* = TIDEAuth    Trust via Intent Driven Extension Auth
= The expansion is really awkward.
It sounds like = it=E2=80=99s an extension to an existing protocol (something that we are = explicitly NOT doing per the charter).

* = TIDYAuth    Trust via Intent Driven Yield Auth
I = actually really like the acronym but the expansion is super awkward. = What is being yielded here?

* = TIEAuth    Trust via Intent Extension Auth
= What is =E2=80=9Cintent extension=E2=80=9D? 
= As above, it sounds like an extension not a protocol.

* TINOA   This Is Not OAuth
= This says nothing about what this work is, only what it isn=E2=80=99= t. And on that regard, it doesn=E2=80=99t matter that this isn=E2=80=99= t OAuth. OAuth 2 isn=E2=80=99t OAuth 1, either. 
= And given that ease of transition from OAuth 2 is part of the = charter, this isn=E2=80=99t a helpful distinction.

* TXAuth    Testable eXtensible = Authorization
I don=E2=80=99t get the focus on =E2=80=9Ctestable=E2= =80=9D in the name. Testable in what way? Can other protocols not be = tested?
Extensibility is = not a differentiating feature of this work.

* TXAuth      Truly eXtensible = Authorization
Extensibility is = not a differentiating feature of this work.
What makes = something =E2=80=9Ctruly extensible=E2=80=9D as opposed to =E2=80=9Cnot = truly extensible=E2=80=9D?

* = XAuthZ    eXtensible authoriZation protocol
Extensibility is not a differentiating feature of = this work.
The acronym is just pulling random letters from = the middle of words in the expansion to try to work.
= Same comment as above focus on Authorization.
= Same comment as above about Zed/Zee confusion.

* WRAC     Web Resource Access = Collaboration
This is not a collaboration protocol or system. = Collaboration, within computer science, is established to refer to when = two or more :people: work and communicate together. This protocol does = not facilitate human communication, and so the use of this term is not = appropriate here. 
This is very = close to =E2=80=9Cwrack=E2=80=9D which is a common enough English = verb, as in =E2=80=9Cwracked nerves=E2=80=9D or =E2=80=9Cto wrack = one=E2=80=99s brain=E2=80=9D, which derives from the medieval torture = process of stretching someone over a rack. This 

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

3D""=E1=90=A7

= --Apple-Mail=_E811CE76-1F88-43BF-BD41-35812196004A-- From nobody Wed Jun 3 15:41:28 2020 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 2342A3A084F for ; Wed, 3 Jun 2020 15:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 hDrqUrO5uqkp for ; Wed, 3 Jun 2020 15:41:24 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450: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 6D79C3A0852 for ; Wed, 3 Jun 2020 15:41:23 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id w15so2333021lfe.11 for ; Wed, 03 Jun 2020 15:41:23 -0700 (PDT) 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=aF8Q3hvmOwLkP214cNzuwz3hA9UC7UYpTBM8/jF+KKc=; b=bLzRuLBCPuGs3pRMBJLKuTQhCdUaOJjfxYD8qtazGXB1HB1ELDrIQVTET/U1MMndLM 1qJUzF+y2uV+LSMnlkUUly7rut6yrJdpc0PE53G0vBxSNLstMGzfhqJn31pxe/B7+aio /K/49FrG5dOGvOSmA3aA376M4OuoNWdn2ccNlGe7UgTkgLqKGFRGGhhbiRC1OxEJoo6W cdGBqKzjkH3PLKQ5khAUKvKDiie8vmSRrFWSdQqyrjUUyFtDh+xzvY5FxTvyVfaoxj9I 077EOLVRpdd8t3RlKeIqeuTK1O/TEUVb92CbKP8jzvIcNfejM6xyWg6LmFsEmhPi1vh/ /vYQ== 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=aF8Q3hvmOwLkP214cNzuwz3hA9UC7UYpTBM8/jF+KKc=; b=hFqgcQQRLir8sU9RGfftykYqWQgzaFXiFpB1TMCwK++Z39DJs5ajxYRtvfam5ytC8Z ONgs0Nr7bAk0FkxoCVxeiuF0H2YDEO+mtp2mreKDjSnw6OK4uK3Nm1BvNix/Onl5VpBv m8jr4dTVdrBl4eCtUNcBxI1+RBJbEu3/eaQaRLtm/iHEQDwKGFOqXefMaOwL3ogh34C6 RrRMUo2fRD0HDzRYHDzGG2f0ICLAPw6xcpPwHUDcwb7xvY2aIjimlOZHZZu94vMZ7aUg p5o2YWbN9eCNv0HCJ1yAl3q+tOEKaXjTgJT3E1r1QWXOgnAX+HTUCZV/a82ov6e2maRO TXYQ== X-Gm-Message-State: AOAM533710M5MTbiZXhmzNjqd6wwH+o2I28XAFSUd/lnvtP1YQpNs8Dd xVGntUrfH0s2xFRj1s7H2dZUiep3GeeYoLbdVfcdQFzR/UI= X-Google-Smtp-Source: ABdhPJyAgObOXsx6JFHl9ZFbZlEUJevbc2RRpJO3q1xSTDN8fO2u1EM/rYWIIaXf9zhafgRu3OYofQLXdP7iXJyrJoY= X-Received: by 2002:a19:f11c:: with SMTP id p28mr899019lfh.0.1591224081198; Wed, 03 Jun 2020 15:41:21 -0700 (PDT) MIME-Version: 1.0 References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> <3E18041D-DDF1-4DFD-ACA2-8C37E46495D7@mit.edu> In-Reply-To: From: Dick Hardt Date: Wed, 3 Jun 2020 15:40:54 -0700 Message-ID: To: Justin Richer Cc: "txauth@ietf.org" Content-Type: multipart/related; boundary="0000000000001e4da205a735ba3e" Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 03 Jun 2020 22:41:27 -0000 --0000000000001e4da205a735ba3e Content-Type: multipart/alternative; boundary="0000000000001e4da105a735ba3d" --0000000000001e4da105a735ba3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The criteria is not "sufficiently descriptive of the work", it is "descriptive of the work". wrt. your comment: "I don=E2=80=99t agree with you that extensibility was n= ot a design factor in OAuth 2, either." I did not say that, I said: "was not a *major* consideration in creating OAuth 2.0" [image: image.gif] Of course it was a consideration, but extensibility did not have the prominence it has in the proposed charter. Having said all of that, I don't think "extensible" is the best adjective for the work, but I don't think it is objectionable per the criteria.[image= : image.gif] [image: image.gif] On Wed, Jun 3, 2020 at 12:36 PM Justin Richer wrote: > My objection is that it is not a *sufficient* description of the work. > Please understand that I agree that extensibility is important, as it=E2= =80=99s > been built into XYZ across all of the various dimensions in our proposed > charter from the project=E2=80=99s inception. However, there=E2=80=99s a = lot more going on > here and I don=E2=80=99t thing simply saying it=E2=80=99s =E2=80=9Cextens= ible=E2=80=9D is any more helpful > than saying it=E2=80=99s =E2=80=9Cnew=E2=80=9D. OAuth 2 is already pretty= extensible, and people > are extending it today to do a lot of important things. I don=E2=80=99t a= gree with > you that extensibility was not a design factor in OAuth 2, either. > > =E2=80=94 Justin > > On Jun 3, 2020, at 12:25 PM, Dick Hardt wrote: > > Justin > > Your objection to extensibility is: > > "Extensibility is not a differentiating feature of this work." > > > I don't see "differentiating feature" in our selection criteria[1], > > We do have the following selection criteria: > > "4. Descriptive of protocol" > > And given how we are explicit in the extensibility, I would consider it > descriptive of the protocol. > > As to the original OAuth 1.0 charter (which talks about extending OAuth > 1.0 to create OAuth 1.1), extensibility was not a focus area, and > definitely was not a major consideration in creating OAuth 2.0. I think > careful considerations of extension points will allow this work to be a > protocol rather than a framework, not the other way around. As an example= , > in the current XAuth document, both the authorization and claims objects > contain name spaced schemas so that the protocol can be extended with oth= er > schemas than the original schemas. For example, there are other schemas f= or > identity claims than what is in OpenID Connect. > > > > [1] > https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa8/ > > > > On Wed, Jun 3, 2020 at 5:19 AM Justin Richer wrote: > >> Hi Dick, >> >> Yes, I am pretty familiar with the charter text, but thank you for >> posting it to the group as a reminder. >> >> The original charter text for the OAuth WG[1] does in fact call out >> extensibility explicitly in several places, including: >> >> The Working Group will produce one or more documents >> suitable for consideration as Proposed Standard that will: >> >> ... >> * Provide guidelines for extensibility. >> >> >> The difference here is that we=E2=80=99re being more explicit about what= is >> extensible and how, in the charter. But one of the biggest innovations i= n >> OAuth 2, as I=E2=80=99m sure you know, is that it allowed for explicit >> extensibility in ways that OAuth 1 did not: grant types, token types, >> scopes (and therefore resource types), client auth types (and therefore >> client types), etc. The very fact that OAuth 2 is a *framework* >> fundamentally speaks to its goals of extensibility. >> >> The TxAuth charter text that you quoted carries much of that tradition >> forward, which is why I said that extensibility is not a :defining: feat= ure >> of this work. It=E2=80=99s absolutely a feature and an important one, bu= t >> extensibility itself is hardly new or unique as a goal. What=E2=80=99s u= nique is >> :what: we=E2=80=99re targeting for extensibility points, which is why th= ose are >> listed below in the proposed charter text. >> >> I also worry that a focus on =E2=80=98extensibility=E2=80=99 above all e= lse will slide us >> back into the world of incompatible framework pieces. As the proposed >> charter also states that we=E2=80=99re building a protocol, not a framew= ork, this >> is counter to what we=E2=80=99re coming together for. >> >> =E2=80=94 Justin >> >> [1] >> https://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2009-05-13= .txt >> >> On Jun 2, 2020, at 5:58 PM, Dick Hardt wrote: >> >> Hey Justin, >> >> Per your comment "Extensibility is not a differentiating feature of this >> work.", extensibility is explicitly called out in the charter (and is no= t >> in the OAuth WG charter): >> >> >> 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 >> - Mechanisms for conveying user, software, organization, and other piece= s >> of information used in authorization decisions >> - Mechanisms for presenting tokens to resource servers and binding >> resource requests to tokens and associated cryptographic keys >> - Optimized inclusion of additional information through the delegation >> process (including identifiers and identity assertions) >> >> Milestones to include: >> >> - Guidelines for use of protocol extension points >> >> >> [1] https://datatracker.ietf.org/wg/txauth/about/ >> >> >> >> >> >> >> =E1=90=A7 >> >> On Thu, May 28, 2020 at 2:47 PM Justin Richer wrote: >> >>> Thanks to everyone in the community for suggesting names, and thanks to >>> the chairs for putting this list together. >>> >>> Here=E2=80=99s my personal take on the candidates. >>> >>> >>> >>> *Wouldn=E2=80=99t Object:* >>> >>> * TxAuth Transmission of Authority >>> This is my personal favorite of the lot because it avoids the >>> =E2=80=9Cauthorization/authentication=E2=80=9D question and gets at the= heart of what this >>> protocol does: delegation, which is to say, transmitting the authority = to >>> do something from one party to another. That delegation allows for >>> authorized access to resources, but can also allow different rights to = flow >>> as needed. Additionally, =E2=80=9Ctx=E2=80=9D has long been used to sta= nd for >>> =E2=80=9Ctransmission=E2=80=9D in computer science and networking. >>> >>> * AZARP AuthoriZed Access to Resources Protocol >>> The use of =E2=80=9CAZ=E2=80=9D to stand for =E2=80=9Cauthorized=E2=80= =9D is awkward, but the >>> pronunciation kinda works as something memorable. The expansion is a tw= ist >>> of words to make it fit, and I like that less. >>> Resource access is only part of the story, but it=E2=80=99s an importan= t part. >>> This leaves out what we want to do around non-authorization cases (like >>> identity conveyance). >>> >>> * AZARAP AuthoriZation And Resource Access Protocol >>> I like the expansion here more than the one for AZARP but I like the >>> acronym less with the additional =E2=80=9CA=E2=80=9D. >>> Same comment as above for AZ standing for Authorization. >>> Same comment as above for resource access. >>> >>> * DAZARAP Delegated AuthoriZation And Resource Access Protocol >>> I like the expansion here, but the acronym is awkward and weak. >>> Same comment as above for AZ standing for Authorized. >>> Same comment as above for resource access. >>> >>> * GNAP Grant Negotiation and Authorization Protocol >>> This is ok, but it has a couple downsides. The pronunciation of a hard >>> =E2=80=9Cg=E2=80=9D or not is going to potentially be confusing, as is = the fact that it >>> looks like it=E2=80=99s part of the GNU project because of that. >>> The term =E2=80=9CGrant=E2=80=9D is one of the more confusing things th= at was introduced >>> in OAuth 2, and while it=E2=80=99s established in the lexicon today, I= =E2=80=99ve yet to >>> meet many engineering teams that actually know what a =E2=80=9Cgrant=E2= =80=9D is. Most >>> think it=E2=80=99s another name for the authorization code. >>> Also it means =E2=80=9Cto bite=E2=80=9D, which may or may not be desira= ble. >>> >>> * NIRAD Negotiation of Intent Registration and Authority Delegation >>> This is a somewhat weak construct, but it mostly works. It spells out >>> more what the protocol will do (if we go with the currently proposed >>> solution designs) than what it solves, but that might be ok. >>> It makes me think of NORAD (a positive, they do weather radar and track >>> Santa Claus each year), but also =E2=80=9Cnimrod=E2=80=9D, a pejorative= term. And before >>> anyone chimes in with =E2=80=9CBut Nimrod was a mighty hunter of ancien= t times=E2=80=9D, it >>> doesn=E2=80=99t mean that to any modern listener. >>> >>> * GATAR Grant Authorization To Access Resources >>> This one isn=E2=80=99t bad, and I can appreciate the =E2=80=9Cguitar=E2= =80=9D pronunciation and >>> imagery. As above, resource access isonly part of the story. >>> Same comment about =E2=80=9CGrant=E2=80=9D as above in GNAP. >>> >>> >>> >>> *Object:* >>> >>> * AAuthZ Alternative Authorization Protocol (AAuthZ) >>> It=E2=80=99s an alternative to what, exactly? And what happens when som= eone >>> makes an alternative to it? >>> The focus on =E2=80=9CAuthorization=E2=80=9D as a core part of the name= tells only part >>> of the story. >>> Assuming the =E2=80=9CZ=E2=80=9D is pronounced as its letter name (whic= h is implied by >>> the capitalization), there=E2=80=99s an issue with pronouncing the fina= l =E2=80=9CZ=E2=80=9D as >>> either =E2=80=9CZee=E2=80=9D or =E2=80=9CZed=E2=80=9D depending on dial= ect. If it=E2=80=99s not pronounced as a >>> letter, it=E2=80=99s really difficult to say the consonants =E2=80=9Cth= z" together in a way >>> that can be heard and understood. >>> >>> * BeBAuthZ Back-end Based Authorization Protocol >>> The definition of =E2=80=9Cback end=E2=80=9D is going to change dependi= ng on your >>> perspective in the stack, but even if it were consistent, the flexibili= ty >>> around user interaction is a huge motivator for many getting involved i= n >>> this work. >>> This is close to =E2=80=9CBBAuth=E2=80=9D, which was a commercial prede= cessor to OAuth >>> 1, so much that it=E2=80=99s nearly impossible to disambiguate when tal= king. >>> Same comment as above focus on Authorization. >>> Same comment as above about Zed/Zee confusion. >>> >>> * BYOAuthZ Build-Your-Own Authorization Protocol >>> This is the opposite of what we=E2=80=99re doing here. We don=E2=80=99t= want a bunch of >>> disparate pieces that people can use to build a protocol, we want a >>> protocol with the right kind of flexibility to fit different use cases. >>> This name tells developers that they aren=E2=80=99t getting a solution = and >>> incompatibility is likely. >>> Same comment as above focus on Authorization. >>> Same comment as above about Zed/Zee confusion. >>> >>> * CPAAP Comprehensive Privileged Authentication Authorization Protoc= ol >>> This makes me think of CPAP, a breathing assistance device. Not >>> something I=E2=80=99m keen to call to mind in the middle of a global pa= ndemic of a >>> respiratory disease. >>> The expansion doesn=E2=80=99t really tell me anything. >>> What does =E2=80=9Cprivileged=E2=80=9D mean here, and does it apply to = the >>> authentication (which seems implied)? >>> >>> * DIYAuthZ Do-It-Yourself Authorization Protocol >>> As above in BYOAuthZ, this is the opposite of what we=E2=80=99re trying= to do by >>> creating a standard. >>> Same comment as above focus on Authorization. >>> Same comment as above about Zed/Zee confusion. >>> >>> * GranPro GRAnt Negotiation Protocol >>> The acronym is a really awkward construction. >>> As above, =E2=80=9Cgrant=E2=80=9D is an often misunderstood term from O= Auth 2. Plus, the >>> =E2=80=9Cgrant=E2=80=9D isn=E2=80=99t really what=E2=80=99s being negot= iated here. >>> >>> * IDPAuthZ Intent Driven Protocol for Authorization >>> =E2=80=9CIDP=E2=80=9D is already well understood in this space to mean = =E2=80=9Cidentity >>> provider=E2=80=9D, so we should not try to overload it. >>> Same comment as above focus on Authorization. >>> Same comment as above about Zed/Zee confusion. >>> >>> * PAuthZ Protocol for Authorization >>> It was suggested this would be pronounced =E2=80=9Cpaws=E2=80=9D but I = can=E2=80=99t think of a >>> single reason someone looking at the word would try to pronounce it tha= t >>> way. >>> It=E2=80=99s also completely generic and doesn=E2=80=99t say anything a= bout the work. >>> Same comment as above focus on Authorization. >>> Same comment as above about Zed/Zee confusion. >>> >>> * RefAuthZ Refactored Authorization Protocol >>> Refactored from what? What if someone refactors this? What are the >>> factors? >>> Same comment as above focus on Authorization. >>> Same comment as above about Zed/Zee confusion. >>> >>> * ReAuthZ Reimagined Authorization Protocol >>> The short form is already a short term for =E2=80=9Cre-authorization=E2= =80=9D, which is >>> not what we are doing. >>> Reimagined from what, and by whom? >>> The expansion sounds like it=E2=80=99s imaginary and not real. >>> Same comment as above focus on Authorization. >>> Same comment as above about Zed/Zee confusion. >>> >>> * TIAAP Tokenized Identity and Access Protocol >>> I don=E2=80=99t think =E2=80=9Ctokenized=E2=80=9D is used in a meaningf= ul way here. It produced >>> =E2=80=9Ctokens=E2=80=9D, but tokenization is the splitting up of an in= put into pieces, >>> which is not what=E2=80=99s happening here. >>> >>> * TIDEAuth Trust via Intent Driven Extension Auth >>> The expansion is really awkward. >>> It sounds like it=E2=80=99s an extension to an existing protocol (somet= hing that >>> we are explicitly NOT doing per the charter). >>> >>> * TIDYAuth Trust via Intent Driven Yield Auth >>> I actually really like the acronym but the expansion is super awkward. >>> What is being yielded here? >>> >>> * TIEAuth Trust via Intent Extension Auth >>> What is =E2=80=9Cintent extension=E2=80=9D? >>> As above, it sounds like an extension not a protocol. >>> >>> * TINOA This Is Not OAuth >>> This says nothing about what this work is, only what it isn=E2=80=99t. = And on >>> that regard, it doesn=E2=80=99t matter that this isn=E2=80=99t OAuth. O= Auth 2 isn=E2=80=99t OAuth >>> 1, either. >>> And given that ease of transition from OAuth 2 is part of the charter, >>> this isn=E2=80=99t a helpful distinction. >>> >>> * TXAuth Testable eXtensible Authorization >>> I don=E2=80=99t get the focus on =E2=80=9Ctestable=E2=80=9D in the name= . Testable in what way? >>> Can other protocols not be tested? >>> Extensibility is not a differentiating feature of this work. >>> >>> * TXAuth Truly eXtensible Authorization >>> Extensibility is not a differentiating feature of this work. >>> What makes something =E2=80=9Ctruly extensible=E2=80=9D as opposed to = =E2=80=9Cnot truly >>> extensible=E2=80=9D? >>> >>> * XAuthZ eXtensible authoriZation protocol >>> Extensibility is not a differentiating feature of this work. >>> The acronym is just pulling random letters from the middle of words in >>> the expansion to try to work. >>> Same comment as above focus on Authorization. >>> Same comment as above about Zed/Zee confusion. >>> >>> * WRAC Web Resource Access Collaboration >>> This is not a collaboration protocol or system. Collaboration, within >>> computer science, is established to refer to when two or more :people: = work >>> and communicate together. This protocol does not facilitate human >>> communication, and so the use of this term is not appropriate here. >>> This is very close to =E2=80=9Cwrack=E2=80=9D which is a common enough = English verb, as >>> in =E2=80=9Cwracked nerves=E2=80=9D or =E2=80=9Cto wrack one=E2=80=99s = brain=E2=80=9D, which derives from the >>> medieval torture process of stretching someone over a rack. This >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >> >> =E1=90=A7 > > > --0000000000001e4da105a735ba3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The cri= teria is not "sufficiently descriptive of the work", it is "= descriptive of the work".

wrt. yo= ur comment: "I don=E2=80=99t agree with you that extensibility was not= a design factor in OAuth 2, either."

I did n= ot say that, I said:

"was not a major = consideration in creating OAuth 2.0"
3D"image.gif"
Of course = it was a consideration, but extensibility did not have the prominence it ha= s in the proposed charter.

Having said all of that= , I don't think "extensible" is the best adjective for the wo= rk, but I don't think it is objectionable per the criteria.3D"image.gif"
3D"image.gif"<= br>

On Wed, Jun 3, 2020 at 12:36 PM Justin Richer <jricher@mit.edu> wrote:
My ob= jection is that it is not a sufficient description of the work. Plea= se understand that I agree that extensibility is important, as it=E2=80=99s= been built into XYZ across all of the various dimensions in our proposed c= harter from the project=E2=80=99s inception. However, there=E2=80=99s a lot= more going on here and I don=E2=80=99t thing simply saying it=E2=80=99s = =E2=80=9Cextensible=E2=80=9D is any more helpful than saying it=E2=80=99s = =E2=80=9Cnew=E2=80=9D. OAuth 2 is already pretty extensible, and people are= extending it today to do a lot of important things. I don=E2=80=99t agree = with you that extensibility was not a design factor in OAuth 2, either.
=C2=A0=E2=80=94 Justin

On Jun 3, 2020, at 12:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
=
Justin

Your objection to extensibility is:=C2=A0

"Extensibility is not a differentiating feature of this work."=

I don't see "differentiatin= g feature"=C2=A0 in our selection criteria[1],=C2=A0

We do have the following selection criteria:

&q= uot;4. Descriptive of protocol"

= And given how we are explicit in the extensibility, I would consider it des= criptive of the protocol.=C2=A0

As to the original= OAuth 1.0 charter (which talks about=C2=A0extending OAuth 1.0 to create OA= uth 1.1), extensibility was not a focus area, and definitely=C2=A0was not a= major consideration in creating OAuth 2.0. I think careful considerations = of extension points will allow this work to be a protocol rather than a fra= mework, not the other way around. As an example, in the current XAuth docum= ent, both the authorization and claims objects contain name spaced schemas = so that the protocol can be extended with other schemas than the original s= chemas. For example, there are other schemas for identity claims than what = is in OpenID Connect.






On Wed, Jun 3, 2020 at 5:19 AM Jus= tin Richer <jricher= @mit.edu> wrote:
Hi Dick,

Yes, I am pretty familiar with the= charter text, but thank you for posting it to the group as a reminder.

The original charter text for the OAuth WG[1] does in= fact call out extensibility explicitly in several places, including:
= 

The Working Group will produce one or more documents
suitable for consideration as Proposed Standard that will:
= 
 ...
* Provide guidelines for extensibility.

The difference here is that we=E2=80=99re being mo= re explicit about what is extensible and how, in the charter. But one of th= e biggest innovations in OAuth 2, as I=E2=80=99m sure you know, is that it = allowed for explicit extensibility in ways that OAuth 1 did not: grant type= s, token types, scopes (and therefore resource types), client auth types (a= nd therefore client types), etc. The very fact that OAuth 2 is a *framework= * fundamentally speaks to its goals of extensibility.=C2=A0

<= /div>
The TxAuth charter text that you quoted carries much of that trad= ition forward, which is why I said that extensibility is not a :defining: f= eature of this work. It=E2=80=99s absolutely a feature and an important one= , but extensibility itself is hardly new or unique as a goal. What=E2=80=99= s unique is :what: we=E2=80=99re targeting for extensibility points, which = is why those are listed below in the proposed charter text.

<= /div>
I also worry that a focus on =E2=80=98extensibility=E2=80=99 abov= e all else will slide us back into the world of incompatible framework piec= es. As the proposed charter also states that we=E2=80=99re building a proto= col, not a framework, this is counter to what we=E2=80=99re coming together= for.

=C2=A0=E2=80=94 Justin

<= div>[1]=C2=A0https://tools.ietf.org/wg/oaut= h/charters?item=3Dcharter-oauth-2009-05-13.txt

On Jun 2, 2020, at 5:58 PM, Dick Hardt <dick.hardt@gmail.com>= wrote:

Hey Justin,

P= er your comment "Extensibility is not a differentiating feature of thi= s work.", extensibility is explicitly called out in the charter (and i= s not in the OAuth WG charter):

The group will def= ine extension points for this protocol to allow for flexibility in areas in= cluding:

- Cryptographic agility for keys, message= signatures, and proof of possession
- User interaction mechanism= s including web and non-web methods
- Mechanisms for conveying us= er, software, organization, and other pieces of information used in authori= zation decisions
- Mechanisms for presenting tokens to resource s= ervers and binding resource requests to tokens and associated cryptographic= keys
- Optimized inclusion of additional information through the= delegation process (including identifiers and identity assertions)

Milestones to include:
<snip>
-= Guidelines for use of protocol extension points





On Thu, May 28, 2020 at 2:47 PM Justin Richer= <jricher@mit.edu> wrote:
Thanks to everyone in the community for suggesting names, and thank= s to the chairs for putting this list together.

He= re=E2=80=99s my personal take on the candidates.

<= br>

Wouldn=E2=80=99t Object:

=
* TxAuth =C2=A0 =C2=A0 =C2=A0Transmission of Authority
This is my personal favorite of the lot = because it avoids the =E2=80=9Cauthorization/authentication=E2=80=9D questi= on and gets at the heart of what this protocol does: delegation, which is t= o say, transmitting the authority to do something from one party to another= . That delegation allows for authorized access to resources, but can also a= llow different rights to flow as needed. Additionally, =E2=80=9Ctx=E2=80=9D= has long been used to stand for =E2=80=9Ctransmission=E2=80=9D in computer= science and networking.

* AZARP =C2=A0 =C2=A0AuthoriZed= Access to Resources Protocol
The use of =E2=80=9CAZ=E2=80=9D to stand for =E2=80=9Cauthori= zed=E2=80=9D is awkward, but the pronunciation kinda works as something mem= orable. The expansion is a twist of words to make it fit, and I like that l= ess.
Resource access= is only part of the story, but it=E2=80=99s an important part. This leaves= out what we want to do around non-authorization cases (like identity conve= yance).

* AZARAP =C2=A0 =C2=A0AuthoriZation And Resourc= e Access Protocol
I = like the expansion here more than the one for AZARP but I like the acronym = less with the additional =E2=80=9CA=E2=80=9D.
Same comment as above for AZ standing for Authori= zation.
Same comment= as above for resource access.

* DAZARAP =C2=A0 =C2=A0De= legated AuthoriZation And Resource Access Protocol
I like the expansion here, but the acron= ym is awkward and weak.=C2=A0
Same comment as above for AZ standing for Authorized.
<= div> Same comment as above for = resource access.

* GNAP =C2=A0 =C2=A0Grant N= egotiation and Authorization Protocol
This is ok, but it has a couple downsides. The pronun= ciation of a hard =E2=80=9Cg=E2=80=9D or not is going to potentially be con= fusing, as is the fact that it looks like it=E2=80=99s part of the GNU proj= ect because of that.
The term =E2=80=9CGrant=E2=80=9D is one of the more confusing things that = was introduced in OAuth 2, and while it=E2=80=99s established in the lexico= n today, I=E2=80=99ve yet to meet many engineering teams that actually know= what a =E2=80=9Cgrant=E2=80=9D is. Most think it=E2=80=99s another name fo= r the authorization code.
<= /span>Also it means =E2=80=9Cto bite=E2=80=9D, which may or may not be desi= rable.

* NIRAD =C2=A0 =C2=A0Negotiation of Intent = Registration and Authority Delegation
This is a somewhat weak construct, but it mostly work= s. It spells out more what the protocol will do (if we go with the currentl= y proposed solution designs) than what it solves, but that might be ok.
It makes me think of NO= RAD (a positive, they do weather radar and track Santa Claus each year), bu= t also =E2=80=9Cnimrod=E2=80=9D, a pejorative term. And before anyone chime= s in with =E2=80=9CBut Nimrod was a mighty hunter of ancient times=E2=80=9D= , it doesn=E2=80=99t mean that to any modern listener.

=
* GATAR =C2=A0 =C2=A0 =C2=A0Grant Authorization To Access Resources=C2= =A0
This one isn=E2= =80=99t bad, and I can appreciate the =E2=80=9Cguitar=E2=80=9D pronunciatio= n and imagery. As above, resource access isonly part of the story.
Same comment about =E2=80=9C= Grant=E2=80=9D as above in GNAP.


Object:

* AAuthZ =C2=A0 =C2=A0Alter= native Authorization Protocol (AAuthZ)

* BYOAuthZ =C2=A0 =C2=A0Build-Your-Own Authorization Protocol
<= div> This is the opposite of wh= at we=E2=80=99re doing here. We don=E2=80=99t want a bunch of disparate pie= ces that people can use to build a protocol, we want a protocol with the ri= ght kind of flexibility to fit different use cases. This name tells develop= ers that they aren=E2=80=99t getting a solution and incompatibility is like= ly.
Same commen= t as above focus on Authorization.
Same comment as above about Zed/Zee confusion.

* CPAAP =C2=A0 =C2=A0Comprehensive Privileged Authenticat= ion Authorization Protocol
= This makes me think of CPAP, a breathing assistance device. Not some= thing I=E2=80=99m keen to call to mind in the middle of a global pandemic o= f a respiratory disease.
The expansion doesn=E2=80=99t really tell me anything.
What does =E2=80=9Cprivileged=E2=80= =9D mean here, and does it apply to the authentication (which seems implied= )?

* DIYAuthZ =C2=A0 =C2=A0Do-It-Yourself Authoriz= ation Protocol
As ab= ove in BYOAuthZ, this is the opposite of what we=E2=80=99re trying to do by= creating a standard.=C2=A0
Same comment as above focus on Authorization.
<= span style=3D"white-space:pre-wrap"> Same comment as above about Zed= /Zee confusion.

* GranPro =C2=A0 =C2=A0GRAnt Nego= tiation Protocol
The= acronym is a really awkward construction.=C2=A0
As above,=C2=A0=E2=80=9Cgrant=E2=80=9D is an o= ften misunderstood term from OAuth 2. Plus, the =E2=80=9Cgrant=E2=80=9D isn= =E2=80=99t really what=E2=80=99s being negotiated here.

* IDP= AuthZ =C2=A0 =C2=A0Intent Driven Protocol for Authorization
=E2=80=9CIDP=E2=80=9D is already we= ll understood in this space to mean =E2=80=9Cidentity provider=E2=80=9D, so= we should not try to overload it.
Same comment as above focus on Authorization.
<= span style=3D"white-space:pre-wrap"> Same comment as above about Zed= /Zee confusion.

* PAuthZ =C2=A0 =C2=A0Protocol fo= r Authorization
It w= as suggested this would be pronounced =E2=80=9Cpaws=E2=80=9D but I can=E2= =80=99t think of a single reason someone looking at the word would try to p= ronounce it that way.=C2=A0
= It=E2=80=99s also completely generic and doesn=E2=80=99t say anythi= ng about the work.
Same comment as above focus on Authorization.
Same comment as above about Zed/Zee confusion.<= /div>

* RefAuthZ =C2=A0 =C2=A0Refactored Authorization = Protocol
Refactored = from what? What if someone refactors this? What are the factors?
Same comment as above focus= on Authorization.
S= ame comment as above about Zed/Zee confusion.

* R= eAuthZ =C2=A0 =C2=A0Reimagined Authorization Protocol
The short form is already a short term for =E2= =80=9Cre-authorization=E2=80=9D, which is not what we are doing.
Reimagined from what,= and by whom?
The ex= pansion=C2=A0sounds like it=E2=80=99s imaginary and not real.
Same comment as above f= ocus on Authorization.
Same comment as above about Zed/Zee confusion.

* TIAAP =C2=A0 =C2=A0Tokenized Identity and Access Protocol
I don=E2=80=99t think =E2=80=9Ctok= enized=E2=80=9D is used in a meaningful way here. It produced =E2=80=9Ctoke= ns=E2=80=9D, but tokenization is the splitting up of an input into pieces, = which is not what=E2=80=99s happening here.

* TIDEAuth =C2=A0= =C2=A0Trust via Intent Driven Extension Auth
The expansion is really awkward.
It sounds like it=E2=80=99s an exten= sion to an existing protocol (something that we are explicitly NOT doing pe= r the charter).

= * TIDYAuth =C2=A0 =C2=A0Trust via Intent Driven Yield Auth
I actually really like the acronym b= ut the expansion is super awkward. What is being yielded here?
* TIEAuth =C2=A0 =C2=A0Trust via Intent Extension Auth
What is =E2=80=9Cintent extension=E2= =80=9D?=C2=A0
As abo= ve, it sounds like an extension not a protocol.

* TINOA =C2= =A0 This Is Not OAuth
This says nothing about what this work is, only what it isn=E2=80=99t. An= d on that regard,=C2=A0it doesn=E2=80=99t matter that this isn=E2=80=99t OA= uth. OAuth 2 isn=E2=80=99t OAuth 1, either.=C2=A0
And given that ease of transition from OAuth = 2 is part of the charter, this isn=E2=80=99t a helpful distinction.

* TXAuth =C2=A0 =C2=A0Testable eXtensible Authorization
I don=E2=80=99t get the focus on= =E2=80=9Ctestable=E2=80=9D in the name. Testable in what way? Can other pr= otocols not be tested?
= Extensibility is not a differentiating feature of this work.
<= div>
* TXAuth =C2=A0 =C2=A0 =C2=A0Truly eXtensible Authorization
Extensibility is not a = differentiating feature of this work.
What makes something =E2=80=9Ctruly extensible=E2=80=9D a= s opposed to =E2=80=9Cnot truly extensible=E2=80=9D?

* = XAuthZ =C2=A0 =C2=A0eXtensible authoriZation protocol
Extensibility is not a differentiating= feature of this work.
The acronym is just pulling random letters from the middle of words in t= he expansion to try to work.
Same comment as above focus on Authorization.
Same comment as above about Zed/Zee conf= usion.

* WRAC =C2=A0 =C2=A0 Web Resource Access C= ollaboration
This is= not a collaboration protocol or system. Collaboration, within computer sci= ence, is established to refer to when two or more :people: work and communi= cate together. This protocol does not facilitate human communication, and s= o the use of this term is not appropriate here.=C2=A0
This is very close to=C2=A0=E2=80=9Cwrack= =E2=80=9D which is a common enough English verb, as in =E2=80=9Cwracked ner= ves=E2=80=9D or =E2=80=9Cto wrack one=E2=80=99s brain=E2=80=9D, which deriv= es from the medieval torture process of stretching someone over a rack. Thi= s=C2=A0

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

3D""=E1=90=A7

 --0000000000001e4da105a735ba3d-- --0000000000001e4da205a735ba3e Content-Type: image/gif; name="image.gif" Content-Disposition: inline; filename="image.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_kazxhw1r0 R0lGODlhAQABAPAAAAAAAAAAACH5BAUAAAAALAAAAAABAAEAAAICRAEAOw== --0000000000001e4da205a735ba3e Content-Type: image/gif; name="image.gif" Content-Disposition: inline; filename="image.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_kazxj8bj2 R0lGODlhAQABAPAAAAAAAAAAACH5BAUAAAAALAAAAAABAAEAAAICRAEAOw== --0000000000001e4da205a735ba3e Content-Type: image/gif; name="image.gif" Content-Disposition: inline; filename="image.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_kazxj8a61 R0lGODlhAQABAPAAAAAAAAAAACH5BAUAAAAALAAAAAABAAEAAAICRAEAOw== --0000000000001e4da205a735ba3e-- From nobody Wed Jun 3 17:53:16 2020 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 DDE683A0821 for ; Wed, 3 Jun 2020 17:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 8UWeggcuv_MT for ; Wed, 3 Jun 2020 17:53:11 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 DF71C3A0809 for ; Wed, 3 Jun 2020 17:53:10 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id c15so1491329uar.9 for ; Wed, 03 Jun 2020 17:53:10 -0700 (PDT) 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; bh=X5NCa54vLVLa015UIOlE+Xv70ZOcTvU0hP05rxU5CiA=; b=rYvyH3+FNrt0Aiz1qHndtHhJDySpfm996k/lexo3vYm4xrS83l1+BMSDbrWuLiM7Fj QyM4c0a2Cbsv3BTitO1z3gTEOHRLCRsqFOcqU/XF4DWOqi18mNjCzS9ZqZYpJIAxo4KF 3vPCLHVIEVMlvTAx9j1y0GpJjNeDUpuWGJYOT3kWORTV2p2VJf/jXJfxpoYJO3gSfwHW osxkQ4r1Z7MQEveJt+gJ1Y/DPZrKl1WbfZQ7oTZo6JXfWfWnBu02BtYb3EEAJeVIq/Al voPkVxPUEBZzPi/I4WkTxjdtx+ZOVKZnXis408/dmS8Mr+ozS/kV8g2pqBBNRnMmV8IT Uz3g== 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; bh=X5NCa54vLVLa015UIOlE+Xv70ZOcTvU0hP05rxU5CiA=; b=Dd0LreY7cygRg8RRUBrMsPOoKPsYSKugCLK11268YaRT5Njnp1TIWOs+LiXH8eJLVo FmsH72b0dWBN9OHI9PKYkG6stiJaiXXvHbCp/LhDH/7DS6RYXAuimuKxnYfxh+xh7FOl rzb6lfAXzpyEBvDvT2J0WKEq6R0TYtfHDw/uPTxGonL8RpQmNyPsQccyI/9qpLu3vnCR 44o/9o0wt4OtgzfJyXkE8/oENx/v+IGHJo2L7gGvY2uMh1vbkSUUb08P12htGtP+3G6a QYx2O+W9OLYknx6qGl2ILtNCzee32SBV7jey7VWdL9j8/MkSHt1TYJDoXdvYga48xKRR 4HAg== X-Gm-Message-State: AOAM532O1WZVIemBQRuMn8w4LsB0oCQ94dRKh1TNHxDrsYw4ufz5tewk 40NY3TcMlIG7DJFFid/76b6JJ7hh7dxYeFZJWD8OcGNcg9E= X-Google-Smtp-Source: ABdhPJydtBBEVEDrYxrSKd3nPkrAbVBpBQ/Vi6DOHuUZer4Mjpfr+idmXZSKY3FOCNoe1rBn6ZJBoZThLHs1kvd9D2c= X-Received: by 2002:a9f:3150:: with SMTP id n16mr1991671uab.9.1591231988370; Wed, 03 Jun 2020 17:53:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Hankins Parichabutr Date: Wed, 3 Jun 2020 20:52:31 -0400 Message-ID: To: txauth@ietf.org Content-Type: multipart/related; boundary="0000000000006c8f5e05a73791fc" Archived-At: Subject: [Txauth] WG name preferences (Hankins Parichabutr) 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, 04 Jun 2020 00:53:14 -0000 --0000000000006c8f5e05a73791fc Content-Type: multipart/alternative; boundary="0000000000006c8f5d05a73791fb" --0000000000006c8f5d05a73791fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here are my name preferences for the WG... *Wouldn't Object:* * TxAuth Transmission of Authority * AZARP AuthoriZed Access to Resources Protocol * GNAP Grant Negotiation and Authorization Protocol * NIRAD Negotiation of Intent Registration and Authority Delegation * PAuthZ Protocol for Authorization * TIAAP Tokenized Identity and Access Protocol I feel these all have the right mix of identifiable/unique short names, along with expansions that both describe and define the overall subject area we're addressing - without imposing any hard-edges if you know what I mean. *Object:* All the other candidates, for reasons including: + not describing or defining anything (eg. "Alternative", "BYO", "DIY", "Reimagined") + being too hard-edged (eg. "Testable", "This is not...", "Truly", "Refactored") + prone to pre-conceived notions (eg. anything with "Extension") + being an acronym looking for a name (eg. "CPAAP", "AZARAP", "GranPro", "TIDYAuth" Thanks for your consideration, Hankins Parichabutr . . . . . . . . . . . . . . . . . . . . . On Wed, Jun 3, 2020 at 6:41 PM wrote: > Send Txauth mailing list submissions to > txauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/txauth > or, via email, send a message with subject or body 'help' to > txauth-request@ietf.org > > You can reach the person managing the list at > txauth-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Txauth digest..." > Today's Topics: > > 1. Re: Call for WG name preferences - process clarification > (Dick Hardt) > > > > ---------- Forwarded message ---------- > From: Dick Hardt > To: Justin Richer > Cc: "txauth@ietf.org" > Bcc: > Date: Wed, 3 Jun 2020 15:40:54 -0700 > Subject: Re: [Txauth] Call for WG name preferences - process clarificatio= n > The criteria is not "sufficiently descriptive of the work", it is > "descriptive of the work". > > wrt. your comment: "I don=E2=80=99t agree with you that extensibility was= not a > design factor in OAuth 2, either." > > I did not say that, I said: > > "was not a *major* consideration in creating OAuth 2.0" > [image: image.gif] > Of course it was a consideration, but extensibility did not have the > prominence it has in the proposed charter. > > Having said all of that, I don't think "extensible" is the best adjective > for the work, but I don't think it is objectionable per the criteria.[ima= ge: > image.gif] > [image: image.gif] > > On Wed, Jun 3, 2020 at 12:36 PM Justin Richer wrote: > >> My objection is that it is not a *sufficient* description of the work. >> Please understand that I agree that extensibility is important, as it=E2= =80=99s >> been built into XYZ across all of the various dimensions in our proposed >> charter from the project=E2=80=99s inception. However, there=E2=80=99s a= lot more going on >> here and I don=E2=80=99t thing simply saying it=E2=80=99s =E2=80=9Cexten= sible=E2=80=9D is any more helpful >> than saying it=E2=80=99s =E2=80=9Cnew=E2=80=9D. OAuth 2 is already prett= y extensible, and people >> are extending it today to do a lot of important things. I don=E2=80=99t = agree with >> you that extensibility was not a design factor in OAuth 2, either. >> >> =E2=80=94 Justin >> >> On Jun 3, 2020, at 12:25 PM, Dick Hardt wrote: >> >> Justin >> >> Your objection to extensibility is: >> >> "Extensibility is not a differentiating feature of this work." >> >> >> I don't see "differentiating feature" in our selection criteria[1], >> >> We do have the following selection criteria: >> >> "4. Descriptive of protocol" >> >> And given how we are explicit in the extensibility, I would consider it >> descriptive of the protocol. >> >> As to the original OAuth 1.0 charter (which talks about extending OAuth >> 1.0 to create OAuth 1.1), extensibility was not a focus area, and >> definitely was not a major consideration in creating OAuth 2.0. I think >> careful considerations of extension points will allow this work to be a >> protocol rather than a framework, not the other way around. As an exampl= e, >> in the current XAuth document, both the authorization and claims objects >> contain name spaced schemas so that the protocol can be extended with ot= her >> schemas than the original schemas. For example, there are other schemas = for >> identity claims than what is in OpenID Connect. >> >> >> >> [1] >> https://mailarchive..ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDcq8rnUa= 8/ >> >> >> >> >> On Wed, Jun 3, 2020 at 5:19 AM Justin Richer wrote: >> >>> Hi Dick, >>> >>> Yes, I am pretty familiar with the charter text, but thank you for >>> posting it to the group as a reminder. >>> >>> The original charter text for the OAuth WG[1] does in fact call out >>> extensibility explicitly in several places, including: >>> >>> The Working Group will produce one or more documents >>> suitable for consideration as Proposed Standard that will: >>> >>> ... >>> * Provide guidelines for extensibility. >>> >>> >>> The difference here is that we=E2=80=99re being more explicit about wha= t is >>> extensible and how, in the charter. But one of the biggest innovations = in >>> OAuth 2, as I=E2=80=99m sure you know, is that it allowed for explicit >>> extensibility in ways that OAuth 1 did not: grant types, token types, >>> scopes (and therefore resource types), client auth types (and therefore >>> client types), etc. The very fact that OAuth 2 is a *framework* >>> fundamentally speaks to its goals of extensibility. >>> >>> The TxAuth charter text that you quoted carries much of that tradition >>> forward, which is why I said that extensibility is not a :defining: fea= ture >>> of this work. It=E2=80=99s absolutely a feature and an important one, b= ut >>> extensibility itself is hardly new or unique as a goal. What=E2=80=99s = unique is >>> :what: we=E2=80=99re targeting for extensibility points, which is why t= hose are >>> listed below in the proposed charter text. >>> >>> I also worry that a focus on =E2=80=98extensibility=E2=80=99 above all = else will slide >>> us back into the world of incompatible framework pieces. As the propose= d >>> charter also states that we=E2=80=99re building a protocol, not a frame= work, this >>> is counter to what we=E2=80=99re coming together for. >>> >>> =E2=80=94 Justin >>> >>> [1] >>> https://tools.ietf.org/wg/oauth/charters?item=3Dcharter-oauth-2009-05-1= 3.txt >>> >>> On Jun 2, 2020, at 5:58 PM, Dick Hardt wrote: >>> >>> Hey Justin, >>> >>> Per your comment "Extensibility is not a differentiating feature of thi= s >>> work.", extensibility is explicitly called out in the charter (and is n= ot >>> in the OAuth WG charter): >>> >>> >>> 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 >>> - Mechanisms for conveying user, software, organization, and other >>> pieces of information used in authorization decisions >>> - Mechanisms for presenting tokens to resource servers and binding >>> resource requests to tokens and associated cryptographic keys >>> - Optimized inclusion of additional information through the delegation >>> process (including identifiers and identity assertions) >>> >>> Milestones to include: >>> >>> - Guidelines for use of protocol extension points >>> >>> >>> [1] https://datatracker.ietf.org/wg/txauth/about/ >>> >>> >>> >>> >>> >>> >>> =E1=90=A7 >>> >>> On Thu, May 28, 2020 at 2:47 PM Justin Richer wrote: >>> >>>> Thanks to everyone in the community for suggesting names, and thanks t= o >>>> the chairs for putting this list together. >>>> >>>> Here=E2=80=99s my personal take on the candidates. >>>> >>>> >>>> >>>> *Wouldn=E2=80=99t Object:* >>>> >>>> * TxAuth Transmission of Authority >>>> This is my personal favorite of the lot because it avoids the >>>> =E2=80=9Cauthorization/authentication=E2=80=9D question and gets at th= e heart of what this >>>> protocol does: delegation, which is to say, transmitting the authority= to >>>> do something from one party to another.. That delegation allows for >>>> authorized access to resources, but can also allow different rights to= flow >>>> as needed. Additionally, =E2=80=9Ctx=E2=80=9D has long been used to st= and for >>>> =E2=80=9Ctransmission=E2=80=9D in computer science and networking. >>>> >>>> * AZARP AuthoriZed Access to Resources Protocol >>>> The use of =E2=80=9CAZ=E2=80=9D to stand for =E2=80=9Cauthorized=E2=80= =9D is awkward, but the >>>> pronunciation kinda works as something memorable. The expansion is a t= wist >>>> of words to make it fit, and I like that less. >>>> Resource access is only part of the story, but it=E2=80=99s an importa= nt part. >>>> This leaves out what we want to do around non-authorization cases (lik= e >>>> identity conveyance). >>>> >>>> * AZARAP AuthoriZation And Resource Access Protocol >>>> I like the expansion here more than the one for AZARP but I like the >>>> acronym less with the additional =E2=80=9CA=E2=80=9D. >>>> Same comment as above for AZ standing for Authorization. >>>> Same comment as above for resource access. >>>> >>>> * DAZARAP Delegated AuthoriZation And Resource Access Protocol >>>> I like the expansion here, but the acronym is awkward and weak. >>>> Same comment as above for AZ standing for Authorized. >>>> Same comment as above for resource access. >>>> >>>> * GNAP Grant Negotiation and Authorization Protocol >>>> This is ok, but it has a couple downsides. The pronunciation of a hard >>>> =E2=80=9Cg=E2=80=9D or not is going to potentially be confusing, as is= the fact that it >>>> looks like it=E2=80=99s part of the GNU project because of that. >>>> The term =E2=80=9CGrant=E2=80=9D is one of the more confusing things t= hat was >>>> introduced in OAuth 2, and while it=E2=80=99s established in the lexic= on today, >>>> I=E2=80=99ve yet to meet many engineering teams that actually know wha= t a =E2=80=9Cgrant=E2=80=9D >>>> is. Most think it=E2=80=99s another name for the authorization code. >>>> Also it means =E2=80=9Cto bite=E2=80=9D, which may or may not be desir= able. >>>> >>>> * NIRAD Negotiation of Intent Registration and Authority Delegation >>>> This is a somewhat weak construct, but it mostly works. It spells out >>>> more what the protocol will do (if we go with the currently proposed >>>> solution designs) than what it solves, but that might be ok. >>>> It makes me think of NORAD (a positive, they do weather radar and trac= k >>>> Santa Claus each year), but also =E2=80=9Cnimrod=E2=80=9D, a pejorativ= e term. And before >>>> anyone chimes in with =E2=80=9CBut Nimrod was a mighty hunter of ancie= nt times=E2=80=9D, it >>>> doesn=E2=80=99t mean that to any modern listener. >>>> >>>> * GATAR Grant Authorization To Access Resources >>>> This one isn=E2=80=99t bad, and I can appreciate the =E2=80=9Cguitar= =E2=80=9D pronunciation and >>>> imagery. As above, resource access isonly part of the story. >>>> Same comment about =E2=80=9CGrant=E2=80=9D as above in GNAP. >>>> >>>> >>>> >>>> *Object:* >>>> >>>> * AAuthZ Alternative Authorization Protocol (AAuthZ) >>>> It=E2=80=99s an alternative to what, exactly? And what happens when so= meone >>>> makes an alternative to it? >>>> The focus on =E2=80=9CAuthorization=E2=80=9D as a core part of the nam= e tells only part >>>> of the story. >>>> Assuming the =E2=80=9CZ=E2=80=9D is pronounced as its letter name (whi= ch is implied by >>>> the capitalization), there=E2=80=99s an issue with pronouncing the fin= al =E2=80=9CZ=E2=80=9D as >>>> either =E2=80=9CZee=E2=80=9D or =E2=80=9CZed=E2=80=9D depending on dia= lect. If it=E2=80=99s not pronounced as a >>>> letter, it=E2=80=99s really difficult to say the consonants =E2=80=9Ct= hz" together in a way >>>> that can be heard and understood. >>>> >>>> * BeBAuthZ Back-end Based Authorization Protocol >>>> The definition of =E2=80=9Cback end=E2=80=9D is going to change depend= ing on your >>>> perspective in the stack, but even if it were consistent, the flexibil= ity >>>> around user interaction is a huge motivator for many getting involved = in >>>> this work. >>>> This is close to =E2=80=9CBBAuth=E2=80=9D, which was a commercial pred= ecessor to OAuth >>>> 1, so much that it=E2=80=99s nearly impossible to disambiguate when ta= lking. >>>> Same comment as above focus on Authorization. >>>> Same comment as above about Zed/Zee confusion. >>>> >>>> * BYOAuthZ Build-Your-Own Authorization Protocol >>>> This is the opposite of what we=E2=80=99re doing here. We don=E2=80=99= t want a bunch of >>>> disparate pieces that people can use to build a protocol, we want a >>>> protocol with the right kind of flexibility to fit different use cases= . >>>> This name tells developers that they aren=E2=80=99t getting a solution= and >>>> incompatibility is likely. >>>> Same comment as above focus on Authorization. >>>> Same comment as above about Zed/Zee confusion. >>>> >>>> * CPAAP Comprehensive Privileged Authentication Authorization >>>> Protocol >>>> This makes me think of CPAP, a breathing assistance device. Not >>>> something I=E2=80=99m keen to call to mind in the middle of a global p= andemic of a >>>> respiratory disease. >>>> The expansion doesn=E2=80=99t really tell me anything. >>>> What does =E2=80=9Cprivileged=E2=80=9D mean here, and does it apply to= the >>>> authentication (which seems implied)? >>>> >>>> * DIYAuthZ Do-It-Yourself Authorization Protocol >>>> As above in BYOAuthZ, this is the opposite of what we=E2=80=99re tryin= g to do >>>> by creating a standard. >>>> Same comment as above focus on Authorization. >>>> Same comment as above about Zed/Zee confusion. >>>> >>>> * GranPro GRAnt Negotiation Protocol >>>> The acronym is a really awkward construction. >>>> As above, =E2=80=9Cgrant=E2=80=9D is an often misunderstood term from = OAuth 2. Plus, >>>> the =E2=80=9Cgrant=E2=80=9D isn=E2=80=99t really what=E2=80=99s being = negotiated here. >>>> >>>> * IDPAuthZ Intent Driven Protocol for Authorization >>>> =E2=80=9CIDP=E2=80=9D is already well understood in this space to mean= =E2=80=9Cidentity >>>> provider=E2=80=9D, so we should not try to overload it. >>>> Same comment as above focus on Authorization. >>>> Same comment as above about Zed/Zee confusion. >>>> >>>> * PAuthZ Protocol for Authorization >>>> It was suggested this would be pronounced =E2=80=9Cpaws=E2=80=9D but I= can=E2=80=99t think of a >>>> single reason someone looking at the word would try to pronounce it th= at >>>> way. >>>> It=E2=80=99s also completely generic and doesn=E2=80=99t say anything = about the work. >>>> Same comment as above focus on Authorization. >>>> Same comment as above about Zed/Zee confusion. >>>> >>>> * RefAuthZ Refactored Authorization Protocol >>>> Refactored from what? What if someone refactors this? What are the >>>> factors? >>>> Same comment as above focus on Authorization. >>>> Same comment as above about Zed/Zee confusion. >>>> >>>> * ReAuthZ Reimagined Authorization Protocol >>>> The short form is already a short term for =E2=80=9Cre-authorization= =E2=80=9D, which is >>>> not what we are doing. >>>> Reimagined from what, and by whom? >>>> The expansion sounds like it=E2=80=99s imaginary and not real. >>>> Same comment as above focus on Authorization. >>>> Same comment as above about Zed/Zee confusion. >>>> >>>> * TIAAP Tokenized Identity and Access Protocol >>>> I don=E2=80=99t think =E2=80=9Ctokenized=E2=80=9D is used in a meaning= ful way here. It produced >>>> =E2=80=9Ctokens=E2=80=9D, but tokenization is the splitting up of an i= nput into pieces, >>>> which is not what=E2=80=99s happening here. >>>> >>>> * TIDEAuth Trust via Intent Driven Extension Auth >>>> The expansion is really awkward. >>>> It sounds like it=E2=80=99s an extension to an existing protocol (some= thing >>>> that we are explicitly NOT doing per the charter). >>>> >>>> * TIDYAuth Trust via Intent Driven Yield Auth >>>> I actually really like the acronym but the expansion is super awkward. >>>> What is being yielded here? >>>> >>>> * TIEAuth Trust via Intent Extension Auth >>>> What is =E2=80=9Cintent extension=E2=80=9D? >>>> As above, it sounds like an extension not a protocol. >>>> >>>> * TINOA This Is Not OAuth >>>> This says nothing about what this work is, only what it isn=E2=80=99t.= And on >>>> that regard, it doesn=E2=80=99t matter that this isn=E2=80=99t OAuth. = OAuth 2 isn=E2=80=99t OAuth >>>> 1, either. >>>> And given that ease of transition from OAuth 2 is part of the charter, >>>> this isn=E2=80=99t a helpful distinction. >>>> >>>> * TXAuth Testable eXtensible Authorization >>>> I don=E2=80=99t get the focus on =E2=80=9Ctestable=E2=80=9D in the nam= e. Testable in what way? >>>> Can other protocols not be tested? >>>> Extensibility is not a differentiating feature of this work. >>>> >>>> * TXAuth Truly eXtensible Authorization >>>> Extensibility is not a differentiating feature of this work. >>>> What makes something =E2=80=9Ctruly extensible=E2=80=9D as opposed to = =E2=80=9Cnot truly >>>> extensible=E2=80=9D? >>>> >>>> * XAuthZ eXtensible authoriZation protocol >>>> Extensibility is not a differentiating feature of this work. >>>> The acronym is just pulling random letters from the middle of words in >>>> the expansion to try to work. >>>> Same comment as above focus on Authorization. >>>> Same comment as above about Zed/Zee confusion. >>>> >>>> * WRAC Web Resource Access Collaboration >>>> This is not a collaboration protocol or system. Collaboration, within >>>> computer science, is established to refer to when two or more :people:= work >>>> and communicate together. This protocol does not facilitate human >>>> communication, and so the use of this term is not appropriate here. >>>> This is very close to =E2=80=9Cwrack=E2=80=9D which is a common enough= English verb, as >>>> in =E2=80=9Cwracked nerves=E2=80=9D or =E2=80=9Cto wrack one=E2=80=99s= brain=E2=80=9D, which derives from the >>>> medieval torture process of stretching someone over a rack. This >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>> >>> =E1=90=A7 >> >> >> Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000006c8f5d05a73791fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here are my name preferences for the WG..= .

Wouldn't Object:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TxAuth =C2=A0 =C2=A0 =C2=A0Transm= ission of Authority
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * AZARP =C2=A0 =C2=A0AuthoriZed Access= to Resources Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * GNAP =C2=A0 =C2=A0G= rant Negotiation and Authorization Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = * NIRAD =C2=A0 =C2=A0Negotiation of Intent Registration and Authority Deleg= ation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * PAuthZ =C2=A0 =C2=A0Protocol for Aut= horization
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * TIAAP =C2=A0 =C2=A0Tokenized Id= entity and Access Protocol
I feel these all have the right mix of identifiable/unique shor= t names, along with expansions that both describe and define the overall su= bject area we're addressing - without imposing any hard-edges if you kn= ow what I mean.

Object:

All the other candidates, for reas= ons including:
+=C2=A0not describing or defining anything (eg. &q= uot;Alternative", "BYO", "DIY", "Reimagined&q= uot;)
+ being too hard-edged (eg. "Testable", "Thi= s is not...", "Truly", "Refactored")
+ prone to pre-conceived notions (eg. anything with "Extension")=
+ being an acronym looking for a name (eg. "CPAAP"= , "AZARAP", "GranPro", "TIDYAuth"

Thanks for your consideration,
Hankins Parichab= utr
. . . . . . . . . . . . . . . . . . . . = .


On Wed, Jun 3, 2020 at 6:41 PM <<= a href=3D"mailto:txauth-request@ietf.org">txauth-request@ietf.org> w= rote:
Send Txaut= h mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 txauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman= /listinfo/txauth
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 txauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 txauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Txauth digest..."
Today's Topics:

=C2=A0 =C2=A01. Re: Call for WG name preferences - process clarification =C2=A0 =C2=A0 =C2=A0 (Dick Hardt)



---------- Forwarded message ----------
From:=C2=A0Dick Hard= t <dick.hardt@= gmail.com>
To:=C2=A0Justin Richer <jricher@mit.edu>
Cc:=C2=A0"txauth@ietf.org" <= ;txauth@ietf.org&g= t;
Bcc:=C2=A0
Date:=C2=A0Wed, 3 Jun 2020 15:40:54 -0700
Subject:= =C2=A0Re: [Txauth] Call for WG name preferences - process clarification
=
The cri= teria is not "sufficiently descriptive of the work", it is "= descriptive of the work".

wrt. yo= ur comment: "I don=E2=80=99t agree with you that extensibility was not= a design factor in OAuth 2, either."

I did n= ot say that, I said:

"was not a major = consideration in creating OAuth 2.0"
3D"image.gif"
Of course = it was a consideration, but extensibility did not have the prominence it ha= s in the proposed charter.

Having said all of that= , I don't think "extensible" is the best adjective for the wo= rk, but I don't think it is objectionable per the criteria.3D"image.gif"
3D"image.gif"<= br>

On Wed, Jun 3, 2020 at 12:36 PM Justin Richer <jricher@mit.edu> wrote:
My objection is that it = is not a sufficient description of the work. Please understand that = I agree that extensibility is important, as it=E2=80=99s been built into XY= Z across all of the various dimensions in our proposed charter from the pro= ject=E2=80=99s inception. However, there=E2=80=99s a lot more going on here= and I don=E2=80=99t thing simply saying it=E2=80=99s =E2=80=9Cextensible= =E2=80=9D is any more helpful than saying it=E2=80=99s =E2=80=9Cnew=E2=80= =9D. OAuth 2 is already pretty extensible, and people are extending it toda= y to do a lot of important things. I don=E2=80=99t agree with you that exte= nsibility was not a design factor in OAuth 2, either.

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

On Jun 3,= 2020, at 12:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Justin

= Your objection to extensibility is:=C2=A0

"Extensi= bility is not a differentiating feature of this work."

I don't see "differentiating feature"= =C2=A0 in our selection criteria[1],=C2=A0

We do h= ave the following selection criteria:

"4. Descript= ive of protocol"

And given how w= e are explicit in the extensibility, I would consider it descriptive of the= protocol.=C2=A0

As to the original OAuth 1.0 char= ter (which talks about=C2=A0extending OAuth 1.0 to create OAuth 1.1), exten= sibility was not a focus area, and definitely=C2=A0was not a major consider= ation in creating OAuth 2.0. I think careful considerations of extension po= ints will allow this work to be a protocol rather than a framework, not the= other way around. As an example, in the current XAuth document, both the a= uthorization and claims objects contain name spaced schemas so that the pro= tocol can be extended with other schemas than the original schemas. For exa= mple, there are other schemas for identity claims than what is in OpenID Co= nnect.




=


On Wed, Jun 3, 2020 at 5:19 AM Justin Richer <= ;jricher@mit.edu&g= t; wrote:
H= i Dick,

Yes, I am pretty familiar with the charter text,= but thank you for posting it to the group as a reminder.

The original charter text for the OAuth WG[1] does in fact call out= extensibility explicitly in several places, including:

The Working Group will produce one or more documents
suitable for consideration as Proposed Standard that will:
= 
 ...
* Provide guidelines for extensibility.

The difference here is that we=E2=80=99re being mo= re explicit about what is extensible and how, in the charter. But one of th= e biggest innovations in OAuth 2, as I=E2=80=99m sure you know, is that it = allowed for explicit extensibility in ways that OAuth 1 did not: grant type= s, token types, scopes (and therefore resource types), client auth types (a= nd therefore client types), etc. The very fact that OAuth 2 is a *framework= * fundamentally speaks to its goals of extensibility.=C2=A0

<= /div>
The TxAuth charter text that you quoted carries much of that trad= ition forward, which is why I said that extensibility is not a :defining: f= eature of this work. It=E2=80=99s absolutely a feature and an important one= , but extensibility itself is hardly new or unique as a goal. What=E2=80=99= s unique is :what: we=E2=80=99re targeting for extensibility points, which = is why those are listed below in the proposed charter text.

<= /div>
I also worry that a focus on =E2=80=98extensibility=E2=80=99 abov= e all else will slide us back into the world of incompatible framework piec= es. As the proposed charter also states that we=E2=80=99re building a proto= col, not a framework, this is counter to what we=E2=80=99re coming together= for.

=C2=A0=E2=80=94 Justin

<= div>[1]=C2=A0https://tools.ietf.org/wg/oaut= h/charters?item=3Dcharter-oauth-2009-05-13.txt

On Jun 2, 2020, at 5:58 PM, Dick Hardt <dick.hardt@gmail.com>= wrote:

Hey Justin,

P= er your comment "Extensibility is not a differentiating feature of thi= s work.", extensibility is explicitly called out in the charter (and i= s not in the OAuth WG charter):

The group will def= ine extension points for this protocol to allow for flexibility in areas in= cluding:

- Cryptographic agility for keys, message= signatures, and proof of possession
- User interaction mechanism= s including web and non-web methods
- Mechanisms for conveying us= er, software, organization, and other pieces of information used in authori= zation decisions
- Mechanisms for presenting tokens to resource s= ervers and binding resource requests to tokens and associated cryptographic= keys
- Optimized inclusion of additional information through the= delegation process (including identifiers and identity assertions)

Milestones to include:
<snip>
-= Guidelines for use of protocol extension points





=E1=90=A7

On Thu, May 28, 2020= at 2:47 PM Justin Richer <jricher@mit.edu> wrote:
Thanks to everyone in the community for su= ggesting names, and thanks to the chairs for putting this list together.

Here=E2=80=99s my personal take on the candidates.



Wouldn=E2=80=99t O= bject:

* TxAuth =C2=A0 =C2=A0 =C2=A0Transmission of= Authority
This is my pers= onal favorite of the lot because it avoids the =E2=80=9Cauthorization/authe= ntication=E2=80=9D question and gets at the heart of what this protocol doe= s: delegation, which is to say, transmitting the authority to do something = from one party to another.. That delegation allows for authorized access to= resources, but can also allow different rights to flow as needed. Addition= ally, =E2=80=9Ctx=E2=80=9D has long been used to stand for =E2=80=9Ctransmi= ssion=E2=80=9D in computer science and networking.

* AZA= RP =C2=A0 =C2=A0AuthoriZed Access to Resources Protocol
The use of =E2=80=9CAZ=E2=80=9D to = stand for =E2=80=9Cauthorized=E2=80=9D is awkward, but the pronunciation ki= nda works as something memorable. The expansion is a twist of words to make= it fit, and I like that less.
Resource access is only part of the story, but it=E2=80=99s an i= mportant part. This leaves out what we want to do around non-authorization = cases (like identity conveyance).

* AZARAP =C2=A0 =C2= =A0AuthoriZation And Resource Access Protocol
I like the expansion here more than the one for A= ZARP but I like the acronym less with the additional =E2=80=9CA=E2=80=9D.
Same comment as above= for AZ standing for Authorization.
Same comment as above for resource access.

* DAZARAP =C2=A0 =C2=A0Delegated AuthoriZation And Resource Access Proto= col
I like the e= xpansion here, but the acronym is awkward and weak.=C2=A0
Same comment as above for AZ standing= for Authorized.
Same comment as above for resource access.

* GNAP =C2=A0 =C2=A0Grant Negotiation and Authorization Protocol
=
This is ok, but it has a = couple downsides. The pronunciation of a hard =E2=80=9Cg=E2=80=9D or not is= going to potentially be confusing, as is the fact that it looks like it=E2= =80=99s part of the GNU project because of that.
The term =E2=80=9CGrant=E2=80=9D is one of the= more confusing things that was introduced in OAuth 2, and while it=E2=80= =99s established in the lexicon today, I=E2=80=99ve yet to meet many engine= ering teams that actually know what a =E2=80=9Cgrant=E2=80=9D is. Most thin= k it=E2=80=99s another name for the authorization code.
Also it means =E2=80=9Cto bite=E2=80=9D= , which may or may not be desirable.

* NIRAD =C2= =A0 =C2=A0Negotiation of Intent Registration and Authority Delegation
This is a somewhat we= ak construct, but it mostly works. It spells out more what the protocol wil= l do (if we go with the currently proposed solution designs) than what it s= olves, but that might be ok.
It makes me think of NORAD (a positive, they do weather radar and = track Santa Claus each year), but also =E2=80=9Cnimrod=E2=80=9D, a pejorati= ve term. And before anyone chimes in with =E2=80=9CBut Nimrod was a mighty = hunter of ancient times=E2=80=9D, it doesn=E2=80=99t mean that to any moder= n listener.

* GATAR =C2=A0 =C2=A0 =C2=A0Grant Auth= orization To Access Resources=C2=A0
This one isn=E2=80=99t bad, and I can appreciate the =E2=80= =9Cguitar=E2=80=9D pronunciation and imagery. As above, resource access iso= nly part of the story.
Same comment about =E2=80=9CGrant=E2=80=9D as above in GNAP.
<= br>


Object:

* AAuthZ =C2=A0 =C2=A0Alternative Authorization Protocol (AAuthZ)
=
It=E2=80=99s an alternati= ve to what, exactly? And what happens when someone makes an alternative to = it?
The focus on =E2= =80=9CAuthorization=E2=80=9D as a core part of the name tells only part of = the story.=C2=A0
Ass= uming the =E2=80=9CZ=E2=80=9D is pronounced as its letter name (which is im= plied by the capitalization),=C2=A0there=E2=80=99s an issue with pronouncin= g the final =E2=80=9CZ=E2=80=9D as either =E2=80=9CZee=E2=80=9D or =E2=80= =9CZed=E2=80=9D depending on dialect. If it=E2=80=99s not pronounced as a l= etter, it=E2=80=99s really difficult to say the consonants =E2=80=9Cthz&quo= t; together in a way that can be heard and understood.

* BeBA= uthZ =C2=A0 =C2=A0Back-end Based Authorization Protocol
The definition of =E2=80=9Cback end=E2= =80=9D is going to change depending on your perspective in the stack, but e= ven if it were consistent, the flexibility around user interaction is a hug= e motivator for many getting involved in this work.
This is close to =E2=80=9CBBAuth=E2=80=9D= , which was a commercial predecessor to OAuth 1, so much that it=E2=80=99s = nearly impossible to disambiguate when talking.
Same comment as above focus on Authorization.
Same comment as above= about Zed/Zee confusion.

* BYOAuthZ =C2=A0 =C2=A0Build-Your-= Own Authorization Protocol
= This is the opposite of what we=E2=80=99re doing here. We don=E2=80= =99t want a bunch of disparate pieces that people can use to build a protoc= ol, we want a protocol with the right kind of flexibility to fit different = use cases. This name tells developers that they aren=E2=80=99t getting a so= lution and incompatibility is likely.
Same comment as above focus on Authorization.
<= div> Same comment as above abou= t Zed/Zee confusion.

* CPAAP =C2=A0 =C2=A0Co= mprehensive Privileged Authentication Authorization Protocol
This makes me think of CPAP, a bre= athing assistance device. Not something I=E2=80=99m keen to call to mind in= the middle of a global pandemic of a respiratory disease.
The expansion doesn=E2=80=99t really= tell me anything.
W= hat does =E2=80=9Cprivileged=E2=80=9D mean here, and does it apply to the a= uthentication (which seems implied)?

* DIYAuthZ = =C2=A0 =C2=A0Do-It-Yourself Authorization Protocol
As above in BYOAuthZ, this is the opposite o= f what we=E2=80=99re trying to do by creating a standard.=C2=A0
<= div>
Same comment as above= focus on Authorization.
Same comment as above about Zed/Zee confusion.

* GranPro =C2=A0 =C2=A0GRAnt Negotiation Protocol
The acronym is a really awkward construct= ion.=C2=A0
As above,= =C2=A0=E2=80=9Cgrant=E2=80=9D is an often misunderstood term from OAuth 2. = Plus, the =E2=80=9Cgrant=E2=80=9D isn=E2=80=99t really what=E2=80=99s being= negotiated here.

* IDPAuthZ =C2=A0 =C2=A0Intent Driven Proto= col for Authorization
=E2=80=9CIDP=E2=80=9D is already well understood in this space to mean = =E2=80=9Cidentity provider=E2=80=9D, so we should not try to overload it.
Same comment as ab= ove focus on Authorization.
= Same comment as above about Zed/Zee confusion.

=
* PAuthZ =C2=A0 =C2=A0Protocol for Authorization
It was suggested this would be pronounce= d =E2=80=9Cpaws=E2=80=9D but I can=E2=80=99t think of a single reason someo= ne looking at the word would try to pronounce it that way.=C2=A0
= It=E2=80=99s also completely g= eneric and doesn=E2=80=99t say anything about the work.
Same comment as above focus on Autho= rization.
Same comme= nt as above about Zed/Zee confusion.

* RefAuthZ = =C2=A0 =C2=A0Refactored Authorization Protocol
Refactored from what? What if someone refactors = this? What are the factors?
Same comment as above focus on Authorization.
Same comment as above about Zed/Zee co= nfusion.

* ReAuthZ =C2=A0 =C2=A0Reimagined Author= ization Protocol
The shor= t form is already a short term for =E2=80=9Cre-authorization=E2=80=9D, whic= h is not what we are doing.
Reimagined from what, and by whom?
The expansion=C2=A0sounds like it=E2=80= =99s imaginary and not real.
Same comment as above focus on Authorization.
= Same comment as above about Ze= d/Zee confusion.

* TIAAP =C2=A0 =C2=A0Tokenized I= dentity and Access Protocol
= I don=E2=80=99t think =E2=80=9Ctokenized=E2=80=9D is used in a mean= ingful way here. It produced =E2=80=9Ctokens=E2=80=9D, but tokenization is = the splitting up of an input into pieces, which is not what=E2=80=99s happe= ning here.

* TIDEAuth =C2=A0 =C2=A0Trust via Intent Driven Ex= tension Auth
The exp= ansion is really awkward.
<= /span>It sounds like it=E2=80=99s an extension to an existing protocol (som= ething that we are explicitly NOT doing per the charter).

* TIDYAuth =C2=A0 =C2=A0Trust via= Intent Driven Yield Auth
<= /span>I actually really like the acronym but the expansion is super awkward= . What is being yielded here?

* TIEAuth =C2=A0 =C2=A0Trust vi= a Intent Extension Auth
What is =E2=80=9Cintent extension=E2=80=9D?=C2=A0
As above, it sounds like an extension not= a protocol.

* TINOA =C2=A0 This Is Not OAuth
This says nothing about what this w= ork is, only what it isn=E2=80=99t. And on that regard,=C2=A0it doesn=E2=80= =99t matter that this isn=E2=80=99t OAuth. OAuth 2 isn=E2=80=99t OAuth 1, e= ither.=C2=A0
And giv= en that ease of transition from OAuth 2 is part of the charter, this isn=E2= =80=99t a helpful distinction.

* TXAuth =C2=A0 =C2=A0Testable= eXtensible Authorization
<= /span>I don=E2=80=99t get the focus on =E2=80=9Ctestable=E2=80=9D in the na= me. Testable in what way? Can other protocols not be tested?
Extensibility is not a differ= entiating feature of this work.

* TXAuth =C2=A0 =C2=A0 = =C2=A0Truly eXtensible Authorization
Extensibility is not a differentiating feature of this work.=
What makes somethin= g =E2=80=9Ctruly extensible=E2=80=9D as opposed to =E2=80=9Cnot truly exten= sible=E2=80=9D?

* XAuthZ =C2=A0 =C2=A0eXtensible author= iZation protocol
= Extensibility is not a differentiating feature of this work.
The acronym is just pulling random= letters from the middle of words in the expansion to try to work.
Same comment as above focus = on Authorization.
Sa= me comment as above about Zed/Zee confusion.

* WR= AC =C2=A0 =C2=A0 Web Resource Access Collaboration
This is not a collaboration protocol or syst= em. Collaboration, within computer science, is established to refer to when= two or more :people: work and communicate together. This protocol does not= facilitate human communication, and so the use of this term is not appropr= iate here.=C2=A0
Thi= s is very close to=C2=A0=E2=80=9Cwrack=E2=80=9D which is a common enough En= glish verb, as in =E2=80=9Cwracked nerves=E2=80=9D or =E2=80=9Cto wrack one= =E2=80=99s brain=E2=80=9D, which derives from the medieval torture process = of stretching someone over a rack. This=C2=A0

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

3D""=E1=90=A7

Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000006c8f5d05a73791fb-- --0000000000006c8f5e05a73791fc Content-Type: image/gif; name="image.gif" Content-Disposition: inline; filename="image.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_kazxhw1r0 R0lGODlhAQABAPAAAAAAAAAAACH5BAUAAAAALAAAAAABAAEAAAICRAEAOw== --0000000000006c8f5e05a73791fc Content-Type: image/gif; name="image.gif" Content-Disposition: inline; filename="image.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_kazxj8bj2 R0lGODlhAQABAPAAAAAAAAAAACH5BAUAAAAALAAAAAABAAEAAAICRAEAOw== --0000000000006c8f5e05a73791fc Content-Type: image/gif; name="image.gif" Content-Disposition: inline; filename="image.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_kazxj8a61 R0lGODlhAQABAPAAAAAAAAAAACH5BAUAAAAALAAAAAABAAEAAAICRAEAOw== --0000000000006c8f5e05a73791fc-- From nobody Wed Jun 3 18:09:16 2020 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 D60BB3A0C0A for ; Wed, 3 Jun 2020 18:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=ZylopLZS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CXymA8zp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-ind4DF25X8 for ; Wed, 3 Jun 2020 18:09:11 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9573A0C0C for ; Wed, 3 Jun 2020 18:09:11 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 63CA57B8 for ; Wed, 3 Jun 2020 21:09:10 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 03 Jun 2020 21:09:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=EpLCNsq abHWbZFq3+t+BR3XUQnlsqHf3TPZrjY8dPnQ=; b=ZylopLZS9oo9KOA+WLWihFb ZKIjiUtb9jJVsZcfZJGWzzwk3q+ZU4yrnHfW6zSShemKiNU+FwNo5LF8Z9whcbLQ rO+jHJbKipncLjVeiJDYhz9If5EhlKTw3mCcsY2o8pfR37+7AL2HWU5wwr+3H43S ENPByoffh2jqD5RqcuJUQj5yJs1D4vGI0MH0zYUvzb9J89GsNB37INnZuCj9Gfhh oHpHgMnEtVKhMnfiALWy6HohxKUqrA1GnvaWKGysy9rYIs39p/LwUBp4qYZFPLAn x88OuUBAkVd7ZlNFdY7nrJNkpfNUn/1TO1xKQ+hzGp9hX0wxRXkbp6otFwbcHCQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=EpLCNs qabHWbZFq3+t+BR3XUQnlsqHf3TPZrjY8dPnQ=; b=CXymA8zpcyer90PJd9Wh6k NMrZVvn+OGAt6qfl6ScuhxKp/WlM7sdnQdV0krFY2tl8c34dv9+TdZrYJjTe/ZZc 1R/JWI2H9HfAN/osb7rNjDT4ng+SibenktXIhyjmf07q3JR3fF0W/5lD46tx2WPi udR4uovQcdV4dw5jC82pmlyTEVbmoCNBwbUaR1G2Gfyv2y41Vc/zU9EMjbGEey2C rHImquoHjImShX3hx/3Hwca8yiS0BwYRG8RK088N9/qe63fiDDsEZOiwfyEskuL1 HMu4M1C6hvn/W4oHw00FUf9WMPrfy96DMDXFHUNQ2EepVXE3lqZ/VAzlgHHK1r4g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegtddggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffvdekfeegle eiueettddtffehveevffefkeduvddttdekiefgjeduvdfhvdduleenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 96DD3180091; Wed, 3 Jun 2020 21:09:09 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: In-Reply-To: <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> Date: Thu, 04 Jun 2020 11:08:48 +1000 From: "Bron Gondwana" To: txauth@ietf.org Content-Type: multipart/alternative; boundary=fe64532dd300469a9259aa7befe73803 Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 04 Jun 2020 01:09:14 -0000 --fe64532dd300469a9259aa7befe73803 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable I'm just gonna do objections. I object to: *BYOAuthZ* Build-Your-Own Authorization Protocol *DIYAuthZ * Do-It-Yourself Authorization Protocol F&$^ no. If I wanted an abstract toolkit factory protocol interface, I'd= go get OAuth2. Can we please pretty please focus on building an interop= erable thing rather than a framework. Starting with a name that doesn't = scream "framework". *RefAuthZ* Refactored Authorization Protocol *ReAuthZ* Reimagined Authorization Protocol Re* sucks for a long term name. *TINOA* This Is Not OAuth "This is not" sucks for a long term name. * * *WRAC* Web Resource Authorization Collaboration I'd prefer not to explicitly be "web" because that's an environment cons= traint which suggests this won't be useful to non-web protocols. *XAuthZ* eXtensible authoriZation protocol Feels like it needs "Y" in there somewhere to collect the set of late-al= phabet letters. Mostly I'm only posting this because I know it sucks to not get feedback= , and there have only been a few responses. To be honest though, which c= hoice we make matters a lot less than making a choice. There's a meta th= ing about standards in general here and trying to please everybody by ma= king everything optional and configurable to the point where nothing int= eroperates. Ho hum. Bron. On Fri, May 22, 2020, at 20:32, Yaron Sheffer wrote: > Thank you David for pointing out the loophole in my previous mail. As = a result, we have decided to limit the time when new names may be propos= ed. If you have new name ideas, please make sure to share them until 080= 0 UTC, Tuesday, May 26. >=20 > All others, if you want to make sure you are commenting on the full na= me list, please hold off until after Monday. >=20 > Apologies for the process confusion, we are building it as we go. >=20 > Thanks, > Yaron >=20 > On 5/21/20, 11:53, "Yaron Sheffer" wrote: >=20 > Thank you to those who contributed early replies! >=20 > As a refinement/clarification to the process below: we are now focusi= ng on discussion and making sure there are no strong objections, rather = than voting on people's favorite name. >=20 > With that in mind, we strongly encourage people to attach an explanat= ion to each name they object to. Therefore for names that are on neither= of your lists ("wouldn't object to" and "object to"), our default assum= ption is that you would NOT object to them. >=20 > With the process now finalized, please take a few minutes and provide= us with your name lists. As a reminder, the deadline is 0800 UTC June 4= , 2020. >=20 > Thanks, > Yaron >=20 >=20 > On 5/19/20, 23:34, "Yaron Sheffer" wrote: >=20 > Hi! >=20 > After reviewing the community feedback and discussions with the AD, w= e=E2=80=99d like to again launch a process to elicit feedback on naming.= Our proposal is below. We=E2=80=99d appreciate any clarifying questions= , proposed improvements or objections by 0800 UTC, Thursday, May 21st . >=20 > Thanks, > Yaron and Dick=20 >=20 > PS, I=E2=80=99m sharing the load with Dick and taking point on this c= onsensus call -- Yaron >=20 > ---- >=20 > Before we submit the draft charter [1] to the IESG, we wanted to expl= ore the name of the group. During the chartering discussions, some peopl= e objected to the BoF name being the WG name. We=E2=80=99d like to get c= onsensus on what the WG name should be. Our first attempt to elicit inpu= t [2] wasn=E2=80=99t successful, and this is a second attempt to get con= sensus from the community. >=20 > To get to consensus, we want to gather preferences on the currently k= nown WG name candidates. Our goal is not to select the most popular name= -- it is to select a name everyone can live with and ensure that we und= erstand and weigh any objections there might be with that choice. To tha= t end, we=E2=80=99d like to elicit your name preferences in the followin= g way: >=20 > (1) In previous discussions, the following candidate names have been = voiced (we have listed only these names that received at least one vote = previously): >=20 > * AAuthZ Alternative Authorization Protocol (AAuthZ) > * AZARP AuthoriZed Access to Resources Protocol > * AZARAP AuthoriZation And Resource Access Protocol > * BeBAuthZ Back-end Based Authorization Protocol > * BYOAuthZ Build-Your-Own Authorization Protocol > * CPAAP Comprehensive Privileged Authentication Authorization Protoco= l > * DAZARAP Delegated AuthoriZation And Resource Access Protocol > * DIYAuthZ Do-It-Yourself Authorization Protocol > * GNAP Grant Negotiation and Authorization Protocol > * GranPro GRAnt Negotiation Protocol > * IDPAuthZ Intent Driven Protocol for Authorization > * NIRAD Negotiation of Intent Registration and Authority Delegation > * PAuthZ Protocol for Authorization > * RefAuthZ Refactored Authorization Protocol > * ReAuthZ Reimagined Authorization Protocol > * TIAAP Tokenized Identity and Access Protocol > * TIDEAuth Trust via Intent Driven Extension Auth > * TIDYAuth Trust via Intent Driven Yield Auth > * TIEAuth Trust via Intent Extension Auth > * TINOA This Is Not OAuth > * TXAuth Testable eXtensible Authorization > * TxAuth Transmission of Authority > * TXAuth Truly eXtensible Authorization > * XAuthZ eXtensible authoriZation protocol >=20 > We would ask that you consider these names, and respond to the list w= ith your selection of the following two categories: >=20 > * =E2=80=9CWouldn=E2=80=99t Object=E2=80=9D -- this is not necessaril= y your preferred name, but you would be comfortable with it being the na= me of the WG (choose as many names as you want) > * =E2=80=9CObject=E2=80=9D -- you would be uncomfortable with the WG = being named in this way (choose as many names as you want; please provid= e an explanation) >=20 > (2) If your preferred name isn=E2=80=99t in the list per (1), you can= send a note to the mailing list stating that you=E2=80=99d like the WG = to consider a new name. Please ensure the name adheres to the previously= discussed naming criteria at [3]. We still request that you provide you= r other preferences and objections. >=20 > (3) If you previously sent in your preferences, but a new name sugges= tion or someone=E2=80=99s objection changed your mind, then send another= message to the mailing list with your revised preferences. For the purp= oses of consensus, we=E2=80=99ll assume that everyone who hasn=E2=80=99t= commented on a new name introduced per (2) =E2=80=9Cobjects=E2=80=9D to= it (i.e., we want to hear positive confirmation of preference on new na= mes). >=20 > (4) Please provide your input by 0800 UTC June 4, 2020. >=20 > With that input, our plan is to assess rough consensus in the followi= ng way: >=20 > (a) See if there is consensus for a name identified given the =E2=80=9C= wouldn=E2=80=99t object to being the WG name=E2=80=9D preference and the= level of =E2=80=9Cwould object=E2=80=9D feedback >=20 > (b) If there isn=E2=80=99t clear consensus with (a), but a significan= tly reduced set of candidates around which there is enthusiasm, the chai= rs will share the results and request feedback >=20 > (c) If rough consensus appears to be reached through steps (a) =E2=80= =93 (b), revisit the objections to this candidate name, elicit additiona= l objections and see if they change the consensus. >=20 > Regards, > Yaron and Dick >=20 > [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/ > [2] https://mailarchive.ietf.org/arch/msg/txauth/GnTUvD191MGMF63Oe3VT= qkYi0Wg/ > [3] https://mailarchive.ietf.org/arch/msg/txauth/lAe06IW4nihUzyTkWVDc= q8rnUa8/ >=20 >=20 >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --fe64532dd300469a9259aa7befe73803 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'm just gonna do objections.  I object to:
<= /div>

BYOAuthZ    Build-Your-Own Authorizatio= n Protocol
DIYAuthZ    Do-It-Yourself Authori= zation Protocol

F&$^ no.  If I = wanted an abstract toolkit factory protocol interface, I'd go get OAuth2= .  Can we please pretty please focus on building an interoperable t= hing rather than a framework.  Starting with a name that doesn't sc= ream "framework".

<= div style=3D"font-family:Arial;">RefAuthZ    Refac= tored Authorization Protocol
= ReAuthZ    Reimagined Authorization Protocol

Re* sucks for a long term name.

TINOA&nb= sp;  This Is Not OAuth
<= br>
"This is not" sucks for a lon= g term name.

WRAC    Web Res= ource Authorization Collaboration

I'd prefer not to expli= citly be "web" because that's an environment constraint which suggests t= his won't be useful to non-web protocols.

XAuthZ&n= bsp;   eXtensible authoriZation protocol

Feels l= ike it needs "Y" in there somewhere to collect the set of late-alphabet = letters.


Most= ly I'm only posting this because I know it sucks to not get feedback, an= d there have only been a few responses.  To be honest though, which= choice we make matters a lot less than making a choice.  There's a= meta thing about standards in general here and trying to please everybo= dy by making everything optional and configurable to the point where not= hing interoperates.  Ho hum.

Bron.

On Fri, May 22, 2020, at 20:32,= Yaron Sheffer wrote:
Thank you David for pointing out= the loophole in my previous mail. As a result, we have decided to limit= the time when new names may be proposed. If you have new name ideas, pl= ease make sure to share them until 0800 UTC, Tuesday, May 26.
<= div style=3D"font-family:Arial;">
All others, if you want to make sure you are commenting on the full= name list, please hold off until after Monday.

Apologies= for the process confusion, we are building it as we go.

= Thanks,
Yaron

= =EF=BB=BFOn 5/21/20, 11:53, "Yaron Sheffer" <yaronf.ietf@gmail.com> wrote:

&nb= sp;   Thank you to those who contributed early replies!

    As a refinement/clarification to the process= below: we are now focusing on discussion and making sure there are no s= trong objections, rather than voting on people's favorite name.

    With that in mind, we strongly encourage peopl= e to attach an explanation to each name they object to. Therefore for na= mes that are on neither of your lists ("wouldn't object to" and "object = to"), our default assumption is that you would NOT object to them.

    With the process now finalized, please take= a few minutes and provide us with your name lists. As a reminder, the d= eadline is 0800 UTC June 4, 2020.

    Than= ks,
    Yaron=


  =   =EF=BB=BFOn 5/19/20, 23:34, "Yaron Sheffer" <yaronf.ietf@gmail.com> wrote:

        Hi!

 &= nbsp;      After reviewing the community feedba= ck and discussions with the AD, we=E2=80=99d like to again launch a proc= ess to elicit feedback on naming.  Our proposal is below.  We=E2= =80=99d appreciate any clarifying questions, proposed improvements or ob= jections by 0800 UTC, Thursday, May 21st .

  &n= bsp;     Thanks,
        Yaron and Dick =  

        PS, I=E2= =80=99m sharing the load with Dick and taking point on this consensus ca= ll -- Yaron

        --= --

        Before we s= ubmit the draft charter [1] to the IESG, we wanted to explore the name o= f the group. During the chartering discussions, some people objected to = the BoF name being the WG name.  We=E2=80=99d like to get consensus= on what the WG name should be.  Our first attempt to elicit input = [2] wasn=E2=80=99t successful, and this is a second attempt to get conse= nsus from the community.

=
     &n= bsp;  To get to consensus, we want to gather preferences on the cur= rently known WG name candidates. Our goal is not to select the most popu= lar name -- it is to select a name everyone can live with and ensure tha= t we understand and weigh any objections there might be with that choice= .  To that end, we=E2=80=99d like to elicit your name preferences i= n the following way:

      =    (1) In previous discussions, the following candidate names = have been voiced (we have listed only these names that received at least= one vote previously):

     &nbs= p;  * AAuthZ    Alternative Authorization Protocol (= AAuthZ)
   &nb= sp;    * AZARP    AuthoriZed Access to Res= ources Protocol
  &= nbsp;     * AZARAP    AuthoriZation A= nd Resource Access Protocol
&= nbsp;       * BeBAuthZ    B= ack-end Based Authorization Protocol
        * BYOAuthZ  = ;  Build-Your-Own Authorization Protocol
        * CPAAP = ;   Comprehensive Privileged Authentication Authorization Prot= ocol
    =     * DAZARAP    Delegated AuthoriZation A= nd Resource Access Protocol
&= nbsp;       * DIYAuthZ    D= o-It-Yourself Authorization Protocol
        * GNAP  &nb= sp; Grant Negotiation and Authorization Protocol
        * GranPro=     GRAnt Negotiation Protocol
        * IDPAuthZ&n= bsp;   Intent Driven Protocol for Authorization
        = * NIRAD    Negotiation of Intent Registration and Authori= ty Delegation
  &nb= sp;     * PAuthZ    Protocol for Auth= orization
   &= nbsp;    * RefAuthZ    Refactored Authoriz= ation Protocol
  &n= bsp;     * ReAuthZ    Reimagined Auth= orization Protocol
 &nbs= p;      * TIAAP    Tokenized Ide= ntity and Access Protocol
&nb= sp;       * TIDEAuth    Tru= st via Intent Driven Extension Auth
        * TIDYAuth  =   Trust via Intent Driven Yield Auth
        * TIEAuth &= nbsp;  Trust via Intent Extension Auth
        * TINOA &= nbsp; This Is Not OAuth
 = ;       * TXAuth    Testabl= e eXtensible Authorization
&n= bsp;       * TxAuth    = ;  Transmission of Authority
        * TXAuth  &nbs= p;   Truly eXtensible Authorization
        * XAuthZ&nbs= p;   eXtensible authoriZation protocol

 &n= bsp;      We would ask that you consider these = names, and respond to the list with your selection of the following two = categories:

        * = =E2=80=9CWouldn=E2=80=99t Object=E2=80=9D -- this is not necessarily you= r preferred name, but you would be comfortable with it being the name of= the WG (choose as many names as you want)
        * =E2=80=9CObje= ct=E2=80=9D -- you would be uncomfortable with the WG being named in thi= s way (choose as many names as you want; please provide an explanation)<= br>

        (2) If your pr= eferred name isn=E2=80=99t in the list per (1), you can send a note to t= he mailing list stating that you=E2=80=99d like the WG to consider a new= name.  Please ensure the name adheres to the previously discussed = naming criteria at [3]. We still request that you provide your other pre= ferences and objections.

=
     &n= bsp;  (3) If you previously sent in your preferences, but a new nam= e suggestion or someone=E2=80=99s objection changed your mind, then send= another message to the mailing list with your revised preferences. = ; For the purposes of consensus, we=E2=80=99ll assume that everyone who = hasn=E2=80=99t commented on a new name introduced per (2) =E2=80=9Cobjec= ts=E2=80=9D to it (i.e., we want to hear positive confirmation of prefer= ence on new names).

      &= nbsp; (4) Please provide your input by 0800 UTC June 4, 2020.
<= div style=3D"font-family:Arial;">
        With that input, our pla= n is to assess rough consensus in the following way:

&nbs= p;       (a) See if there is consensus for= a name identified given the =E2=80=9Cwouldn=E2=80=99t object to being t= he WG name=E2=80=9D preference and the level of =E2=80=9Cwould object=E2= =80=9D feedback

       = ; (b) If there isn=E2=80=99t clear consensus with (a), but a significant= ly reduced set of candidates around which there is enthusiasm, the chair= s will share the results and request feedback

  = ;      (c) If rough consensus appears to be rea= ched through steps (a) =E2=80=93 (b), revisit the objections to this can= didate name, elicit additional objections and see if they change the con= sensus.

        Regards,=
    &nbs= p;   Yaron and Dick





-- 
Txauth mailing list


--
  Bro= n Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailtea= m.com

--fe64532dd300469a9259aa7befe73803-- From nobody Wed Jun 3 18:49:42 2020 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 8D82D3A0CB0 for ; Wed, 3 Jun 2020 18:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=guCevx0t; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uAQZGekD Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O1eUprNhVbE for ; Wed, 3 Jun 2020 18:49:38 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE4D3A0CB3 for ; Wed, 3 Jun 2020 18:49:38 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 30BC95C0114 for ; Wed, 3 Jun 2020 21:49:36 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 03 Jun 2020 21:49:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=ZHMNIvhSQWB8RBRbAlZ1axTNYg9yc7z 6bzU1/yq9Pjc=; b=guCevx0tF2ol4rwuWvmrkUSys66Ed/f1BSzXJtO6Z6e+/+N /nqKLqyfzjfb2rrO5I5UR9eA49sM7ApeNUFHm96hY7et7ErM6oIz0otxsvrfhHZR tJyA6mIVylMwh9+XfWvDI5ymV8TwtMhJTGQxblXpTYNji2AdUraz3T4g+VwDeXfX PDXiYnIQfOA0i9WuvJy+F0s8NDhXYD++wciY6C5c4LRL6dydbas66MXUmxaQNiD1 rOYExy9JPwy09QQgPCL72P78XXHH+v3klrbx7WEHa0hTcx42Sjfwsm/f+Zu6HDfF tD2VnrQ3Stkmeser2ORUyVh+xEnAg/w8nPNie/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ZHMNIv hSQWB8RBRbAlZ1axTNYg9yc7z6bzU1/yq9Pjc=; b=uAQZGekD/OYLxeoMK7uYKh SDvkIY+u1X1rcN1+v/EQ8hUG7fS7kyFiAdpF5gmitKh9c9wWtWo0KEN5rVTVD5UF Gle3qsJZBfq9OaOQNqdnOvCPjvct5lJmo/cMGcX/Qr88MMQaVaJ9YLSi+U12SRGp E5sPajQ6iDD+cYamy7zfIjQyus4GoZWHBphTnB2oGBLt4vBQmceffL2C7jOGlCSt Q4mtCV7xWgcVJtaCF8dnK5TLGg/YMWNLaNwXeIBHNkzXw7iOLC4V0LejMBFhT+Pg iA34F413wLbDniY1d5O5bGfX3WWfnrk0lrhExcnUTKuF7C0FZcwFBO58H2BlTctA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegtddggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfhggrhihnvgcuvehhrghnghdfuceofiihtgesfhgrshht mhgrihhlrdhfmheqnecuggftrfgrthhtvghrnhepgeejteetkedtueehffefudffvdejue evhedtfefhjeefkeeflefguefgkeevtdevnecuffhomhgrihhnpehivghtfhdrohhrghen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeifhigtse hfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 015BDE00C9; Wed, 3 Jun 2020 21:49:35 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <3a56f2c4-3011-41c8-ba3b-fd37728f2d71@www.fastmail.com> In-Reply-To: <4469e170-f313-42c0-a288-41bd8a1fa5d8@www.fastmail.com> References: <4469e170-f313-42c0-a288-41bd8a1fa5d8@www.fastmail.com> Date: Wed, 03 Jun 2020 21:49:31 -0400 From: "Wayne Chang" To: txauth@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Txauth] unsolicited feedback on naming 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, 04 Jun 2020 01:49:41 -0000 hi, refactoring a few items as NO OBJECT for your readability, ordered by my personal preference: TxAuth Transmission of Authority TXAuth Truly eXtensible Authorization TXAuth Testable eXtensible Authorization TIEAuth Trust via Intent Extension Auth the remainder can be considered OBJECT. reminder that i don't currently have significant stake in the outcome of this naming. On Thu, May 28, 2020, at 12:16 PM, Wayne Chang wrote: > hi all, good to meet you. adding $0.02 on naming as an outsider, using > good, bad, ugly descriptors: > > * AAuthZ Alternative Authorization Protocol (AAuthZ) > ugly, tough to pronounce and looks like a typo of AuthZ > > * AZARP AuthoriZed Access to Resources Protocol > ugly, initialism doesn't imply function > > * AZARAP AuthoriZation And Resource Access Protocol > ugly, initialism doesn't imply function > > * BeBAuthZ Back-end Based Authorization Protocol > bad, "back-end" is way too broad > > * BYOAuthZ Build-Your-Own Authorization Protocol > bad, "BYO" means "bring your own" to me > > * CPAAP Comprehensive Privileged Authentication > Authorization Protocol > ugly, unclear how to pronounce, looks close to "CRAAP" > > * DAZARAP Delegated AuthoriZation And Resource Access Protocol > ugly, initialism doesn't imply function > > * DIYAuthZ Do-It-Yourself Authorization Protocol > bad, DIY implies amateurish and backyard > > * GNAP Grant Negotiation and Authorization Protocol > bad, initialism doesn't imply function > > * GranPro GRAnt Negotiation Protocol > ugly, .+pro or has hints of proprietary > > * IDPAuthZ Intent Driven Protocol for Authorization > ugly, IdP already means identity provider to lots of folks > > * NIRAD Negotiation of Intent Registration and Authority > Delegation > bad, expansion is too wordy and intent registration is unclear to > external stakeholders > > * PAuthZ Protocol for Authorization > bad, initialism does not imply function > > * RefAuthZ Refactored Authorization Protocol > bad, "Ref" means reference to lots of folks as in you're trying to > define the gold standard > > * ReAuthZ Reimagined Authorization Protocol > ugly, implies that you might authorize _again_ > > * TIAAP Tokenized Identity and Access Protocol > ugly, "tokenized" anything has charged meanings to technologists and > non-technologists alike > > * TIDEAuth Trust via Intent Driven Extension Auth > bad, i like "TIDEAuth" but Trust via Intent Driven Extension is just > semantic soup > > * TIDYAuth Trust via Intent Driven Yield Auth > bad, tidy implies small, driven yield means nothing to me > > * TIEAuth Trust via Intent Extension Auth > good > > * TINOA This Is Not OAuth > ugly > > * TXAuth Testable eXtensible Authorization > good, except "Testable" doesn't sound like the main priority here? > > * TxAuth Transmission of Authority > good > > * TXAuth Truly eXtensible Authorization > good, not sure about "Truly" because we will no doubt encounter limits ourselves > > * XAuthZ eXtensible authoriZation protocol > bad, best expanded form here, but XAuthZ is not aesthetic to me > > is there a reason we didn't call it TXAuth/TxAuth and have it stand for > Transaction Authorization? either of those would be my first choice. i > understand that the name picking period is over. > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > From nobody Wed Jun 3 19:15:35 2020 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 BC46B3A0D3C for ; Wed, 3 Jun 2020 19:15:33 -0700 (PDT) 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, 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 CuWMyth92a5f for ; Wed, 3 Jun 2020 19:15:31 -0700 (PDT) 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 83EF73A0D3B for ; Wed, 3 Jun 2020 19:15:31 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id q8so4606533iow.7 for ; Wed, 03 Jun 2020 19:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=9sNR0oPyogpzjDiX+UJDXaAmUXl2vCJAF4fyHPfpZUI=; b=Ik6fAbNojceMAhNgfZdQ5mWy61H0DxMqKKe55lt+h27v1ah5dH5fmBZHt7jLj54lm/ mhsFd24C8UEs7i8EygXiaZSiG1QMDh1hB117EIntzrxUsRPbnd/pEjL4BgARPEi4JPho Zyv32GHQb+KElXtCUHOWJ0RtJIbZt5g/OIar+2zEy7ca4gouIimX63+JM7wheDDkkphF bJLSd/TG+UFnVZKNx2+AHKEZAMVb0qCUKaobyhpugTKb5KcCqqkXpHpEzKi2rOczAXQ7 fZnjVLLf2uurKfTUvxHPJaJh9MTGpkRlWkdNufe/Urh9XAVBNrO+V7sW3paFTvTQnBXa p7PQ== 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=9sNR0oPyogpzjDiX+UJDXaAmUXl2vCJAF4fyHPfpZUI=; b=OzQ4uYlNWPGYC3WIQqzT+E6vcRHsLZk/bfbtdKxSQpp74r/CVR32GnzWDO24tJVCvo TBeswVfNhNphzZH8BdaKgXNiHcD7Kw7UVKPOPWi4JSCEwXMmQNsyg1YNpGZCxUmaCW1b K3wN4pVOyqx4iDjAKXwfEuffpdfobsMU5ptTsQp4dI5dCaNOl2QperqqbBMlCgDmMft6 JsfnzA7AUlhfy9RIZesrg1PiStuw5PQFiUkcWqkOIcbr8JW2C9vAfwP0Mca7zQreeeqX MsC4is/mL1WkGvZl88o4KLtp80ecLht5cvSAZWgVfyQvl4pmiyOMEfAoBAqYGf1+RElC YNiQ== X-Gm-Message-State: AOAM530wor0magZ9pd8B4bcij30589bAuf/Hiazq8TSh5MSE5uynjrh7 eHGgFOJAkVm+XgFjXtqYgW6KovRmnRs= X-Google-Smtp-Source: ABdhPJxSt/34h93PjK6KNFSbU5bOVlI3vhZ6NNT+icR0+/U+G8yle0kg0lUG5rLkUblCL/3KKiE8Jw== X-Received: by 2002:a02:3402:: with SMTP id x2mr2389614jae.11.1591236930096; Wed, 03 Jun 2020 19:15:30 -0700 (PDT) Received: from mail-il1-f173.google.com (mail-il1-f173.google.com. [209.85.166.173]) by smtp.gmail.com with ESMTPSA id p69sm741293ili.75.2020.06.03.19.15.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2020 19:15:29 -0700 (PDT) Received: by mail-il1-f173.google.com with SMTP id d1so4556977ila.8 for ; Wed, 03 Jun 2020 19:15:29 -0700 (PDT) X-Received: by 2002:a05:6e02:5a9:: with SMTP id k9mr2195970ils.291.1591236928735; Wed, 03 Jun 2020 19:15:28 -0700 (PDT) MIME-Version: 1.0 From: Aaron Parecki Date: Wed, 3 Jun 2020 19:15:17 -0700 X-Gmail-Original-Message-ID: Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000e426d505a738b757" Archived-At: Subject: [Txauth] WG name preferences 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, 04 Jun 2020 02:15:34 -0000 --000000000000e426d505a738b757 Content-Type: text/plain; charset="UTF-8" Alright here's mine: Would not object: * TxAuth - Transmission of Authority - This is my favorite, there's a lot of precedent for "tx" to mean "transmit", and using "authority" is a nice way to sidestep the authn vs authz nonsense. It also does describe what the protocol is doing, which is delegation. (If there was a nice shorthand for Delegation of Authority that would have been better, but "DegAuth" and "DAuth" are just terrible. * GNAP - Grant Negotiation and Authorization Protocol - I don't hate it, but I agree with Justin on the downsides: ambiguous pronunciation, potential confusion with GNU, and the use of "grant" which so far hasn't been a core concept in the new proposals. Also, any acronym that ends with "P" will have people saying "GNAP Protocol" which is redundant like "ATM Machine". * GATAR - Grant Authorization to Access Resources - Not my favorite, but at least the pronunciation isn't super ambiguous, and like Justin said, resource access is not the entire story. * TIDYAuth - Trust via Intent Driven Yield Auth - I like the acronym, but the expansion makes little sense. I'm putting it in my "wouldn't object" list because if we go with this, in reality nobody will use the expanded form anyway and it will just be the short name. Here are my objections along with the reasoning: * AAuthZ Alternative Authorization Protocol * ReAuthZ Reimagined Authorization Protocol * RefAuthZ Refactored Authorization Protocol * TINOA This Is Not OAuth These define it in relation to something else, which is never a good idea. * BYOAuthZ Build-Your-Own Authorization Protocol * DIYAuthZ Do-It-Yourself Authorization Protocol Sounds unprofessional. * TXAuth Testable eXtensible Authorization * TXAuth Truly eXtensible Authorization * XAuthZ eXtensible authoriZation protocol While extensibility is definitely important, I don't think it is a core value of the protocol. If anything we're trying to specify more details than OAuth 2.0 did at the start, which was one of the major criticisms it got. * BeBAuthZ Back-end Based Authorization Protocol * TIAAP Tokenized Identity and Access Protocol * PAuthZ Protocol for Authorization These are awkward to pronounce. * TIEAuth Trust via Intent Extension Auth * TIDEAuth Trust via Intent Driven Extension Auth These aren't great to pronounce, and also have a very awkward expansion that is clearly a backronym. * IDPAuthZ Intent Driven Protocol for Authorization "IDP" is already a commonly used term in this space and it would cause significant confusion to redefine it this way. * AZARP AuthoriZed Access to Resources Protocol * AZARAP AuthoriZation And Resource Access Protocol * DAZARAP Delegated AuthoriZation And Resource Access Protocol * GranPro GRAnt Negotiation Protocol A few of these sound silly and I'm not sure I could say them with a straight face, also not a fan of the "AZ -> Authorized" expansion. * CPAAP Comprehensive Privileged Authentication Authorization Protocol Looks too much like CPAP, and "craap", would not be googleable if I said this out loud to someone. * NIRAD Negotiation of Intent Registration and Authority Delegation Not a fan of how similar this is to NORAD. * WRAC (Web Resource Authorization Collaboration) - Pronounced like RACK A reasonable acronym with easy enough pronunciation, but I'm not a fan of "collaboration" in the expansion at all. This is not a collaboration system, that term is already heavily used in other types of software. --- Aaron Parecki https://aaronparecki.com --000000000000e426d505a738b757 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alright here's mine:

Wou= ld not object:

=C2=A0 =C2=A0 * TxAuth - Transmissi= on of Authority - This is my favorite, there's a lot of precedent for &= quot;tx" to mean "transmit", and using "authority"= is a nice way to sidestep the authn vs authz nonsense. It also does descri= be what the protocol is doing, which is delegation. (If there was a nice sh= orthand for Delegation of Authority that would have been better, but "= DegAuth" and "DAuth" are just terrible.

=C2=A0 =C2=A0 * GNAP - Grant Negotiation and Authorization Protoco= l - I don't hate it, but I agree with Justin on the downsides: ambiguou= s pronunciation, potential confusion with GNU, and the use of "grant&q= uot; which so far hasn't been a core concept in the new proposals. Also= , any acronym that ends with "P" will have people saying "GN= AP Protocol" which is redundant like "ATM Machine".

=C2=A0 =C2=A0 * GATAR - Grant Authorization to Access Reso= urces - Not my favorite, but at least the pronunciation isn't super amb= iguous, and like Justin said, resource access is not the entire story.

=C2=A0 =C2=A0 * TIDYAuth - Trust via Intent Driven Yie= ld Auth - I like the acronym, but the expansion makes little sense. I'm= putting it in my "wouldn't object" list because if we go wit= h this, in reality nobody will use the expanded form anyway and it will jus= t be the short name.

Here are my objections al= ong with the reasoning:

=C2=A0 =C2=A0 * AAuthZ =C2= =A0 =C2=A0Alternative Authorization Protocol
=C2=A0 =C2=A0 * = ReAuthZ =C2=A0 =C2=A0Reimagined Authorization Protocol
=C2=A0 =C2= =A0 * RefAuthZ =C2=A0 =C2=A0Refactored Authorization Protocol
=C2= =A0 =C2=A0 * TINOA =C2=A0 This Is Not OAuth

These define it in relation to something else, which is never a good ide= a.

=C2=A0 =C2=A0 * BYOAuthZ =C2=A0 =C2=A0Bui= ld-Your-Own Authorization Protocol
=C2=A0 =C2=A0 * DIYAuthZ = =C2=A0 =C2=A0Do-It-Yourself Authorization Protocol

=
Sounds unprofessional.=C2=A0

=C2=A0 =C2=A0 * TXAuth =C2=A0 =C2=A0Testable eXtensible Authorization=
=C2=A0 =C2=A0 * TXAuth =C2=A0 =C2=A0 =C2=A0Truly eXtensible Authorizati= on
=C2=A0 =C2=A0 * XAuthZ =C2=A0 =C2=A0eXtensible authoriZati= on protocol

While extensibility is defini= tely important, I don't think it is a core value of the protocol. If an= ything we're trying to specify more details than OAuth 2.0 did at the s= tart, which was one of the major criticisms it got.

=C2=A0 =C2=A0 * BeBAuthZ =C2=A0 =C2=A0Back-end Based Authorization = Protocol
=C2=A0 =C2=A0 * TIAAP =C2=A0 =C2=A0Tokenized Identit= y and Access Protocol
=C2=A0 =C2=A0 * PAuthZ =C2=A0 =C2=A0Protocol= for Authorization

These are awkward to pronounce.<= /div>

=C2=A0 =C2=A0 * TIEAuth =C2=A0 =C2=A0Tr= ust via Intent Extension Auth
=C2=A0 =C2=A0 * TIDEAuth =C2=A0= =C2=A0Trust via Intent Driven Extension Auth

=
These aren't great to pronounce, and also have a very awkward expa= nsion that is clearly a backronym.

=C2=A0 = =C2=A0 * IDPAuthZ =C2=A0 =C2=A0Intent Driven Protocol for Authorization
=

"IDP" is already a commonly used t= erm in this space and it would cause significant confusion to redefine it t= his way.

=C2=A0 =C2=A0 * AZARP = =C2=A0 =C2=A0AuthoriZed Access to Resources Protocol
=C2=A0 = =C2=A0 * AZARAP =C2=A0 =C2=A0AuthoriZation And Resource Access Protocol
=
=C2=A0 =C2=A0 * DAZARAP =C2=A0 =C2=A0Delegated AuthoriZation And= Resource Access Protocol
=C2=A0 =C2=A0 * GranPro =C2=A0 =C2= =A0GRAnt Negotiation Protocol

A few of th= ese sound silly and I'm not sure I could say them with a straight face,= also not a fan of the "AZ -> Authorized" expansion.

=C2=A0 =C2=A0 * CPAAP =C2=A0 =C2=A0Comprehensive Priv= ileged Authentication Authorization Protocol

<= div>Looks too much like CPAP, and "craap", would not be googleabl= e if I said this out loud to someone.

=
=C2=A0 =C2=A0 * NIRAD =C2=A0 =C2=A0Negotiation of Intent Registra= tion and Authority Delegation

Not a fan of how= similar this is to NORAD.

=C2=A0 =C2=A0 * W= RAC (Web Resource Authorization Collaboration) - Pronounced like RACK

A reasonable acronym with easy enough pronunciation= , but I'm not a fan of "collaboration" in the expansion at al= l. This is not a collaboration system, that term is already heavily used in= other types of software.

---
Aaron Parecki

--000000000000e426d505a738b757-- From nobody Thu Jun 4 01:39:50 2020 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 756423A0418 for ; Thu, 4 Jun 2020 01:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=sunet.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7J2jRqujC8D for ; Thu, 4 Jun 2020 01:39:46 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030A53A0400 for ; Thu, 4 Jun 2020 01:39:45 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id a9so2660897ljn.6 for ; Thu, 04 Jun 2020 01:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=to:from:autocrypt:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=O4k1vMnTNB3+6Ichnk5cHCQFbtDjjFG1nphiw9QlS0Y=; b=T3BpP8Fa7Yso0X4CepfiL2Fzrly8YnHMG/NeKp2euWVPREKyUSsKm8GC3DfJtx2Dbo TcD8S++dN5RG1R2RziInadXtbqzBWv+4fQU025Sv4hc0Hm2xmMnIlTdo6irR3Pa/bGKd kONASXiaXUzfkRSo1k+KR24ZOpBGfKjjaXLSXRdaRS+3DviqYAKDkElmm/bY7OSfBc3g SPLh1TWvSsr4nd1JLfd4j5nwLsZP2phVwsP2ppcL//Fjg0cy1mgEsitaR5vV4dLxZU3I jLVYyiww6fMj1DP7qxQ6c2zitxUiNtkK82rbORz+KPK+qpbvhGQ8OJs3KjSHL6l9Son6 ojig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:autocrypt:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=O4k1vMnTNB3+6Ichnk5cHCQFbtDjjFG1nphiw9QlS0Y=; b=LoiNIO/F6T99EV70iW1tRttI1qnDfhwHhxhFEcSS8cU8vWPU4pG6c4puKewX8nexfQ N1mfXRM49wCG1AAHQBefTTm8h0gYsva1cjpodwWwsbgA/NIBxDefZbUAJy6CbOYAzK+e cNF+1KeH7qTYxu6BkTjxI8Ogf/ZiTMUT7r6se94/zq1dDSh4xSNjrG55AKOOhlrZSGw0 Z0KVnt2WlvKL6wkOF5JOOe7ZA5QKquuTJ0Rf3AfMQft2Z3SVZoc99KCUGh6+CrB3W00B /L6MN/CjuaTx8X5vBUHsYCEyrjYvZNOFwxRYnRZeJlZr/BH31pN7lV284Taj5siB5o4I 4rcw== X-Gm-Message-State: AOAM532Y6D9p0rkNcEC20Xgb2N2Q/mPKWhE4zGO//Fu9NYdHYNMVK7qe LjYUOdXNHGdrf5/LEF4Z2AbzQqpouS4i4A== X-Google-Smtp-Source: ABdhPJwHmmPRikEesOZBoUxNzuFvbWIuJdkeQRQhxMSEnatPP1LzNq0pu26LuIpVTCJEIbKA4FsW8w== X-Received: by 2002:a2e:b6d1:: with SMTP id m17mr1622722ljo.328.1591259981917; Thu, 04 Jun 2020 01:39:41 -0700 (PDT) Received: from [10.0.0.129] (h-98-128-229-119.NA.cust.bahnhof.se. [98.128.229.119]) by smtp.gmail.com with ESMTPSA id f9sm1264041ljf.99.2020.06.04.01.39.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jun 2020 01:39:41 -0700 (PDT) To: txauth@ietf.org From: Leif Johansson Autocrypt: addr=leifj@sunet.se; prefer-encrypt=mutual; keydata= xsBNBFJK9qIBCACypED81H1N4YmhMJrb4uOtTDzo+lFZDVVOcK11+NhTFl+AZZFnWH/7UPn+ q5ZZBd/IhONfb5QGw5FzTyBWHsbAteXgCvHAIyumwhQzhZnow6myyC6/MwDhomT5rb3MkCKC yQMNfj/yMgL6ZRsXVhlGOLMmOekRfKe2wiC5BhRaQQwPZPwgFS5D0Tro8Xfxjk98u8rNpQXi 9walRAffRY+byhkPiBj0sVA2RXK9Dx2DL3EY0xx07r6Qhs2XkbXNDDCHRuChhHSHwWC16VS9 x7Nhfg2EwKqmMGRNREikjwzDl/aHKz+FXTLONdmc83sRyklqgH90f3na6s/RT5XTb08xABEB AAHNHUxlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U+wsB+BBMBCAAoAhsDBgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCW7Yg8gUJDw7ExQAKCRDXOtZDCtR41io7CACOVmQcjoS7cfuF 43NhvpfFjSn91qShubrWx/p0+v/1MRyGajeMKcBd9HPDsN/lhMuY6k2zI1Qsrsycv51QQ+d0 +lPFxO3LKcrzaKqfKV3UZP3eVsMQgyP21iFIFAw424aAeBjWRhhnzlvsiP3RzF4NNb7goMWR PLWlld4M+MGqlM+T8M2Jbxl2OejedK5HCGm00IzXS7NojDGdIiXHbx0S0RloNb7ssQdFdHAH M6hO30lCwTM5jnNbejXhFUlMqYdRjWPUAbFwX3Pw9Wpkr5xz5xYbx8xPZBIG6ROp8ExxP31V NTm+DTnwJS5LLMbV1aDLYIzYlEossP2NFhLtwVDEzsBNBFJK9qIBCAC+k1tFOeDS4gMxEgRk fiVLHFemwJWQiGZHYhtDgjh6w6mB8G3WZ+/gD2CMp5DgHFRC1sW2iMj3gOzrfyxzd9AmWbhX YceR6EFkTc6OVsaIb+eHH/Zo3DKyB1Dq9CA5fjjnEQzti+KKSZYWzB0Fkt7qrfOS6YM1zMjE UxUUwsl1qirx5DuByWLDX7ULU7H/xmPVhHUVZO8XEaFV2m+ICx8Y6B98KMeJ0Qz8b8wp2g7v WEkwS2R6IjF0kMrRxnxUvwA6EUiZuFphhuY/lWCJusLl1olgOE+BKMEUStJWEi0s+pd8FL1v OLeNKbIUFro0+oZr9byABpkPNjMxKV36uj1dABEBAAHCwGUEGAEIAA8CGwwFAlu2H5wFCQ8O w3cACgkQ1zrWQwrUeNbSVAgAmRS6XxztiU9pczUwElOnolmnAIUocSXdfllZABxLX1MkZ4Yn 0jEbJKMpPOAMu7cQs4gni/AprnMae23taqJprwWCE6lTcOEhdPNKSFhdL4eE+UCd9Z9S/8PC M0GkjDF9FAWcrIBmySiHmZfAwKbHk3+AhDmY2PzN+mOzgU7t855+OtcoI02PDEXJGTCU9Mcl YtMNAlrmMmbMUApLSIoFluY35nlBVDFD3bDuCb59Nbs9aBJ9bu956G04XUcYt9sTsnkPppzX 82jyCc6Oeg9He8F1ep7AEoscflUKuwn9YF/sblqq27GO4d/BQPtaNw0iGz1H1C1QWKES4tk4 bZRWFA== Message-ID: <82ae0d13-af42-5554-4e0b-12c0cc6e4cad@sunet.se> Date: Thu, 4 Jun 2020 10:39:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Txauth] the 3 hardest problems in computer science... 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, 04 Jun 2020 08:39:48 -0000 ... is as everyone knows naming, and off-by-one errors. I am worried that we are sacrificing the actual work in the WG in the process of naming it. How about this: we pause the naming discussion. We keep the name of the mailing list and come back to naming at some later time. Alternatively, if the IETF can live with only remote meetings then maybe we can break new ground by beeing the only WG with an abbreviation that doesn't resolve at all. We'd be the "Working Group Formerly know as XYZ" and we'd refuse to answer questions about how its pronounced. I am being 100% serious. I am sick and tired of the current flame- fest around naming. Its totally out of control and we ether stop now or I don't think we will ever get anything done. Cheers Leif From nobody Thu Jun 4 06:07:14 2020 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 498FC3A0C61 for ; Thu, 4 Jun 2020 06:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=securekeytechnologies.onmicrosoft.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 s6s5qtcL6ykQ for ; Thu, 4 Jun 2020 06:07:10 -0700 (PDT) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660096.outbound.protection.outlook.com [40.107.66.96]) (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 A23543A0C5C for ; Thu, 4 Jun 2020 06:07:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KZ7uwpJK6G6ttJiCtjsJd5h34tCrqL8RjhAkvASQwEFIX/XyN+POIDNpbMrRKcj4EUrxETjusFIkGt01+pdLHTuH2YG+EWtieotP+ykxVbxBMLniX6TujzBiOZObUhxmd5ZPhXkjveP5+zbS9wcfwdSXxMOStFpz8Z2B7lDube/3WXe8HoojHtZC7o4fXPHbPGjcEHbkrGEb2TouLreJKLxv0Xx4uXm9YQjQfoVUWJpOVz5OIbzwGZlrvIeqKRkDbo/sOqDIsQFD8x/O7FlrdcSA0N0m+Zn8CukxMU+8t1vXFrHA9l8ykv0MKYxPYMfTGOHoXG/eq4EQ3PE4XX2OaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OBm1TYcPEdBRpP9odtk17oFXxx2cZafa3VF4eelZrac=; b=fRK90+bC9DM1D9lgVUyJgbI40GFHjoFDCFepU3DfMBLLCpgs+raQDaj29YfHUOcNPJVXXZVh57+ke3XAsCTqBCLOJWcUCfj00nbLT4Ce7IP9AWLi1VORpwPGQArnLeWl8tjEmN9Mlr5wDWQgTKZfa9lhjq3ZjFZ8s0JPwkdfQH/ku3w2JP/wWM0KjFvSnI2H8Wv567ygPZEJ+HCHrngFPzo4GGW5pJuEndjdEUKMW2iU3X/LBrmScR2ZrLliXa3ZpIdP7FGlZA7nwjx1CPbBknWMezuM+hinaIZvElqrPjugZNQqSq0iI7K6ClUzcg0nYVCxAT3b1s5ChbtG/J3nlg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=securekey.com; dmarc=pass action=none header.from=securekey.com; dkim=pass header.d=securekey.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securekeytechnologies.onmicrosoft.com; s=selector1-securekeytechnologies-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OBm1TYcPEdBRpP9odtk17oFXxx2cZafa3VF4eelZrac=; b=U1+nVWeockGFufVaSxsptdGvuv52klhdNkkzwsEP/ovxbz6Mwqam950zdvtM13nx5ENW2c1cbrXyYs4SZx5O4I4V/lm7VPeSwfLcboHDcGQgo/mTwaKE4wCiWBr5RtQ4hgCDto7YmkGHDTsN1ESPUQJhyUahHdgoqfOgAymB0Iw= Received: from YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:20::25) by YTOPR0101MB0745.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:23::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Thu, 4 Jun 2020 13:07:08 +0000 Received: from YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM ([fe80::1146:fc82:c5e4:b710]) by YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM ([fe80::1146:fc82:c5e4:b710%6]) with mapi id 15.20.3045.024; Thu, 4 Jun 2020 13:07:08 +0000 From: Mike Varley To: "txauth@ietf.org" Thread-Topic: [Txauth] Call for WG name preferences - process clarification Thread-Index: AQHWMCROorvZrIf4Q0ed/uohn5gb9qi+EugAgAdNRACAAD1UAIACoSOA Date: Thu, 4 Jun 2020 13:07:08 +0000 Message-ID: <017A609E-DEAF-43C5-BB61-DB433CE2BBD6@securekey.com> References: <785D1C5C-EE90-4A3F-9917-00F94F319863@gmail.com> <1FDCD86E-C52E-4C33-889C-20EC082F009D@gmail.com> <73BEEDEF-70D5-4B7A-BE9D-E01A5831D9EF@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=securekey.com; x-originating-ip: [64.231.232.148] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9fa6f7dd-4a94-4840-df26-08d808882fe9 x-ms-traffictypediagnostic: YTOPR0101MB0745: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 04244E0DC5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kEtYQ8JJ5GAHLA2U66/JtvI6ZInYdKbXS8CTjL+wdnQBBDRy9KtIDVkSxhpd2BKju2xLeGwVqEe6kCsBzx3Z3P2DZq6Lq5qdQ/F0fjNYBEHrCPuRb9RfMnRyEZNCiruRCsq3m42TTBgGhimocbIHc+SeIlkiaO2DjC62qsDNudzwuPbKuxqnFRB4oqP3Et3DBz1z5N4fxpH7HntQkmI/cJSYJh3j+YHbFefQrSnSrx5HD3jYXNdpOg437GygQiS2IFnD/uFMWSaG73bKUimXqfEoaccA1CBDAHHH7wdWF85vQoCSesjF1MiVH5p+wzqsZ5ryf8ruRZ6V0jeeFUuwQA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39840400004)(366004)(136003)(376002)(396003)(346002)(6916009)(66946007)(186003)(478600001)(4744005)(66476007)(8676002)(66556008)(6506007)(66446008)(64756008)(2906002)(33656002)(6486002)(8936002)(5660300002)(26005)(6512007)(83380400001)(86362001)(44832011)(36756003)(316002)(71200400001)(76116006)(2616005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 21hPlAMcI5reAGinTT6bT+mxXj2YfysaqW83Cm0bMXHaPqB5NX19scem/GJkiYH0X32ykh+ohbP4pTmWfVYuNeJOKuwiYy04GRlm7FVmoqrjxQcx/yTbUU6Cg58VXSkxWZnvCZdllhq5SKwl8AqauA74E/5A0L8C92Bf+RlRGOANju+1KCD+MDHE12zBwllxvAiNbPn8xmZDHU/feWs//pZdpgDaI/EJpmSgL7/hwXwWgzSvZFz0H6+hUEQLuwbBRzCpr5XbCyh6t4+5xbD0aGsc1D+PfRzinc6g6zN+Dp5s9SBuI58+2LSSifkmoAoQj7MsPXY86VMIH+fZpTeVwRkgKzR/jlr4D1q2YpSc7cbuAfdiQoG8LY5GokmeX0cTgXqmAe73w0mHMQxU7liJP2uxUFmd4f0vusSvlyWrCuA+MYu8TXrWW7vQIZuMv2L/Jne6AqTADE/w8B4ouXK9//mcnXxJAkxuqYDs/+x5CP4mEkyw+rtdmOv/ZnqxOBR3 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_017A609EDEAF43C5BB61DB433CE2BBD6securekeycom_" MIME-Version: 1.0 X-OriginatorOrg: securekey.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9fa6f7dd-4a94-4840-df26-08d808882fe9 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2020 13:07:08.4656 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e211fbf0-7d88-4a7c-b5b5-09a66b0b7ad0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yqGXcZ/wqhEKIsBUeSR8o0/BC0a2npJuK1GVua6448WE7sG5b1hyERG7INtn9jcOblmRTwGuGupJqiRFCA9/Rlb7z1meG5FJc4FdBe0J4HA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB0745 Archived-At: Subject: Re: [Txauth] Call for WG name preferences - process clarification 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, 04 Jun 2020 13:07:12 -0000 --_000_017A609EDEAF43C5BB61DB433CE2BBD6securekeycom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLCBoZXJlIGlzIG15IGxpc3Q6DQoNCldvbuKAmXQgT2JqZWN0Og0KDQpHTkFQDQpUSURZ QXV0aA0KVHhBdXRoL1RYQXV0aA0KDQoNCk9iamVjdDoNCkJlQmF1dGhaIChwcm9udW5jaWF0aW9u KQ0KQ1BBQVAgKG1lZGljYWwgZGV2aWNlKQ0KQllPQXV0aFogKOKAmGJyaW5nLXlvdXItb3duLXBy b3RvY29sIGlzIG1vcmUgbGlrZSDigJhubyBwcm90b2NvbOKAmSkNCkFaQVJBUC9EQVpBUkFQIChw cm9udW5jaWF0aW9uKQ0KRElZQXV0aFogKGxpa2UgQllPLSBpbXBsaWVzIHRoZXJlIGlzIG5vIHN0 cnVjdHVyZSkNClBBdXRoWiAocHJvbnVuY2lhdGlvbiDigJMgaWYgd2Ugd2FudCBQQVVaIHRoYXQg d291bGQgYmUgb2spDQpSZWZBdXRoWi8gUmVBdXRoWiAod2hhdCB3b3VsZCB3ZSBjYWxsIE9BdXRo IDQ/IDU/IEV2ZXJ5dGhpbmcgaXMgYSByZWZhY3RvcuKApikNClhBdXRoWiAobGlrZSBpdCBvbiBw YXBlciwgYnV0IHByb251bmNpYXRpb24gaXMgc3RydWdnbGUpDQoNCg0KVGhhbmtzLA0KDQpNVg0K DQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGZvciB0aGUgc29sZSB1c2Ugb2Yg dGhlIGludGVuZGVkIHJlY2lwaWVudHMgYW5kIG1heSBiZSBwcml2aWxlZ2VkLCBjb25maWRlbnRp YWwgb3Igb3RoZXJ3aXNlIGV4ZW1wdCBmcm9tIGRpc2Nsb3N1cmUgdW5kZXIgbGF3LiBBbnkgZGlz dHJpYnV0aW9uLCBwcmludGluZyBvciBvdGhlciB1c2UgYnkgYW55b25lIG90aGVyIHRoYW4gdGhl IGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCBhbiBpbnRl bmRlZCByZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGFu ZCBwZXJtYW5lbnRseSBkZWxldGUgdGhpcyBlbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K --_000_017A609EDEAF43C5BB61DB433CE2BBD6securekeycom_ Content-Type: text/html; charset="utf-8" Content-ID: <8BEFD0C27D955149AAF20BA7B990805B@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgYWxsLCBoZXJlIGlzIG15 IGxpc3Q6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvbuKAmXQgT2JqZWN0OjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5HTkFQJm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VElEWUF1dGgmbmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UeEF1dGgvVFhBdXRoIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9iamVjdDo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlQmF1dGhaIChwcm9udW5jaWF0aW9uKTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q1BBQVAgKG1lZGljYWwgZGV2aWNlKTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QllPQXV0aFogKOKAmGJyaW5nLXlv dXItb3duLXByb3RvY29sIGlzIG1vcmUgbGlrZSDigJhubyBwcm90b2NvbOKAmSk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFaQVJBUC9EQVpBUkFQIChwcm9udW5jaWF0aW9u KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RElZQXV0aFogKGxpa2UgQllP LSBpbXBsaWVzIHRoZXJlIGlzIG5vIHN0cnVjdHVyZSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlBBdXRoWiAocHJvbnVuY2lhdGlvbiDigJMgaWYgd2Ugd2FudCBQQVVaIHRo YXQgd291bGQgYmUgb2spPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWZB dXRoWi8gUmVBdXRoWiAod2hhdCB3b3VsZCB3ZSBjYWxsIE9BdXRoIDQ/IDU/IEV2ZXJ5dGhpbmcg aXMgYSByZWZhY3RvcuKApik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlhB dXRoWiAobGlrZSBpdCBvbiBwYXBlciwgYnV0IHByb251bmNpYXRpb24gaXMgc3RydWdnbGUpPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3Ms PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1WPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgaWQ9ImJvZHkiIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7IGNv bG9yOmRhcmtncmF5OyBsaW5lLWhlaWdodDoxMHB0OyBmb250LWZhbWlseTogJ0FyaWFsJywndGlt ZXMgcm9tYW4nLHNlcmlmOyI+DQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGZv ciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudHMgYW5kIG1heSBiZSBwcml2 aWxlZ2VkLCBjb25maWRlbnRpYWwgb3Igb3RoZXJ3aXNlIGV4ZW1wdCBmcm9tIGRpc2Nsb3N1cmUg dW5kZXIgbGF3LiBBbnkgZGlzdHJpYnV0aW9uLCBwcmludGluZyBvciBvdGhlciB1c2UgYnkgYW55 b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLg0KIElm IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNl bmRlciBpbW1lZGlhdGVseSwgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGlzIGVtYWlsIGFuZCBp dHMgYXR0YWNobWVudHMuPC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_017A609EDEAF43C5BB61DB433CE2BBD6securekeycom_-- From nobody Thu Jun 4 16:25:37 2020 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 EBA653A1057 for ; Thu, 4 Jun 2020 16:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODB0KDHILRwM for ; Thu, 4 Jun 2020 16:25:35 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640091.outbound.protection.outlook.com [40.107.64.91]) (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 5EF683A1056 for ; Thu, 4 Jun 2020 16:25:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GOi7OAFABl1JNqlgVsrEQwT2KJyXnona7cGc9Uyo2fF6A1nuqsdc/EYmsVB+FHx0vR46LRCZgnEP8umbEmmh7AgAR9Qf0KIOVHwoB2fV21KUb8btaBrK7HDDgpQfvdPgdHh6tTpn8ba6sTDi/tlZq1EQKnesdyKnEucQ7KPMWl2c3hW+YpMKCgOhgNe+7186+J2/UG9Z9OtPEHZXrBCPFyOZO06AiSUZHLkuFvB+OrnmJTFcOh2wjKC4Cjajl48BUzNVNhC4uExzF+jslzrGVO4wVDptcITPsqyc3fAI90rQ+fXPt8MJwIgDaR5gE6nVqmrnpdlijVu9KiKJ3SGcmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vFZlg1DM1zur4hHnlIZNdK0Gc8isr4xz9rAAfySm5JE=; b=ZRGeDE+X5keJAVGqyLqsycQiFyqEO/4W/MJrsOPiF8YhLpQf2V9eN/t5xe20PZ8Jmjr10SAjvEc34lmcaOL7nnMkioYNScOHbgau6/kL1NIH7KXcPNrkgz7MKII4U4o2CfYyUcxgGa6HuIm2RWoSnMfcYX50yX97WadJLXUnNBXpsKlvPNvZ7N7gJ4k5W3SfpDjVKoZOE/7jvsNY6BzXHepfqx5lUSHvS7OxbrsmPDoBKDwSY9rHrA5Yd94qn8C1+glOrzYZgpJLLc9WFocpj0Bh2VoV5LAQU0mvvcZGVCP1aBQwiHELudxG3YpWqhPqokuiVz7a3VWV5X3cZErcig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vFZlg1DM1zur4hHnlIZNdK0Gc8isr4xz9rAAfySm5JE=; b=cYjG8pawaSx9PN52ynecWipsBqaML0m+s8yZmDypJS67ToFEI7F6IFCBTlYTtwlLcTLgzxkOkIMM9gNbZedOiJ4lPpDMcnNs5V0XboSEa7sHxXxGzjvZT72249WZWXoMx39349gKGU34MlHEAzmV7KXX7dpx8PgFv55TW0vBFJc= Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0809.namprd00.prod.outlook.com (2603:10b6:610:6f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3107.0; Thu, 4 Jun 2020 23:25:30 +0000 Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::f158:8611:537b:9f84]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::f158:8611:537b:9f84%7]) with mapi id 15.20.3109.000; Thu, 4 Jun 2020 23:25:30 +0000 From: Mike Jones To: Yaron Sheffer , "txauth@ietf.org" Thread-Topic: Call for WG name preferences Thread-Index: AQHWLhz1JMnyE3kgbUehUCuB6MwuwajJLmvw Date: Thu, 4 Jun 2020 23:25:29 +0000 Message-ID: References: <9FD428B4-F3C1-426B-9677-611F5FEC85C8@gmail.com> In-Reply-To: <9FD428B4-F3C1-426B-9677-611F5FEC85C8@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=dc634a89-540d-493a-b972-000089946e8a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-04T23:10:22Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 82a6363d-ddef-4767-fad4-08d808de922a x-ms-traffictypediagnostic: CH2PR00MB0809: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-forefront-prvs: 04244E0DC5 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YzkvtGZqMr93nxABsZkXlpC2HAhkMAg2DTWPr/uoBovTgcmbcD9o+uaRel1ZLSISKQi3z4l4CQQrb6bdjMGsHPjNhvG/moEJeVVjnCHbX4lkq0xtb7Oes2FPqiaNgcVzPLs/Pl7oXht3p3k6+1ps+N9+YZH6wNxeqUV66t/IAa512wTyDs2/XCdX5sNZJ9MLevLincjVFsLTeJ5q4gGdAcK1heXQl6DNxEUQSs8fp3YOftOwjxQIwG5B1hoyq9T4w5Ok84eRDxsLH0Nk+eF18xynjNpw/C8B849hx+n1vQuWy/0vUsH4bMjTdOFqU7nSMFko4XCSYKjL/asQSjNDAA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(366004)(376002)(396003)(346002)(55016002)(478600001)(316002)(8676002)(52536014)(8936002)(9686003)(2906002)(110136005)(10290500003)(71200400001)(8990500004)(5660300002)(6506007)(26005)(186003)(66476007)(33656002)(66556008)(83380400001)(66446008)(86362001)(66946007)(7696005)(82950400001)(76116006)(64756008)(82960400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: mHjvF2t/cHs099ua2rucL6z7vWg+GZ2a81S7J23Wmv0HKucCZ+2MfWPwc4c9SRfYP0jcvmj/ckP3dxD/3hdyRyKsIwBRxOFNyX/bAOmfZTokimi0prNXVpt2zZrw2+7ujhaT7zsfDAyDTbngRJxZl3VMvWDoZYlXcNOlH/vqKgsaH3b6YZQllXgrXPLJ8V8dDyVsGy0QGIFmlSs+4OC0ISxACglfHVw5mFuK0ZIXJu+QGwEf+kPnNzUQkG51fPf1BSMdRryG6hgyQdLdmEc8/hjcrpWnH8cZLLfGs3P7jEQT6GHr/6e5sKDYA7oqOHUDY1z9jdaNBh5/93m3/MlWtzRAW638PTi62iYBs6qnexktX8zW+Orc6a2Tb1WpKYZ0pKNwiY7rcNC5Et/RXoFmss3cMAuD4LrEUc2RwQjuaqJWRK03r/6B8KURTNGzpjR7ZrIFqsO9SAPU1S/IDS+fjs+6V+4LvOF6SqHfmUIcEgU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0678F2BD3C70191D28A639E5F5890CH2PR00MB0678namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 82a6363d-ddef-4767-fad4-08d808de922a X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2020 23:25:30.0509 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JbsWvWlXcmiZN57LdtkET35hnDI/OPDgACqzamtVvDnZhj18X9LBOeggKq9kMNel12zXlBPDCunVPpgObMhBEQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0809 Archived-At: Subject: Re: [Txauth] Call for WG name preferences 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, 04 Jun 2020 23:25:37 -0000 --_000_CH2PR00MB0678F2BD3C70191D28A639E5F5890CH2PR00MB0678namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHJlZmVyOg0KDQogICAgKiBHTkFQICAgIEdyYW50IE5lZ290aWF0aW9uIGFuZCBBdXRob3JpemF0 aW9uIFByb3RvY29sIOKAkyBUaGUgZm9jdXMgb24gZ3JhbnRzIGlzIGNvcnJlY3QuICBBbmQgaXTi gJlzIGEgc25hcHB5IG5hbWUuDQoNCiAgICAqIEdyYW5Qcm8gICAgR1JBbnQgTmVnb3RpYXRpb24g UHJvdG9jb2wg4oCTIFRoZSBmb2N1cyBvbiBncmFudHMgaXMgY29ycmVjdC4gIFByb25vdW5jZWFi bGUuDQoNCiAgICAqIE5JUkFEICAgIE5lZ290aWF0aW9uIG9mIEludGVudCBSZWdpc3RyYXRpb24g YW5kIEF1dGhvcml0eSBEZWxlZ2F0aW9uIOKAkyBDb29sIHNjaS1maSBzb3VuZGluZyBuYW1lLg0K DQogICAgKiBQQXV0aFogICAgUHJvdG9jb2wgZm9yIEF1dGhvcml6YXRpb24g4oCTIEFjY3VyYXRl IGRlc2NyaXB0aW9uLg0KDQogICAgKiBSZWZBdXRoWiAgICBSZWZhY3RvcmVkIEF1dGhvcml6YXRp b24gUHJvdG9jb2wg4oCTIEFjY3VyYXRlIGRlc2NyaXB0aW9uLg0KDQogICAgKiBSZUF1dGhaICAg IFJlaW1hZ2luZWQgQXV0aG9yaXphdGlvbiBQcm90b2NvbCDigJMgQWNjdXJhdGUgZGVzY3JpcHRp b24uDQoNCiAgICAqIFdSQUMgKFdlYiBSZXNvdXJjZSBBdXRob3JpemF0aW9uIENvbGxhYm9yYXRp b24pIC0gUHJvbm91bmNlZCBsaWtlIFJBQ0sg4oCTIENvb2wgbmFtZSwgd2l0aCBoaXN0b3J5IGdv aW5nIGJhY2sgdG8gT0F1dGggV1JBUC4NCg0KICAgICogWEF1dGhaICAgIGVYdGVuc2libGUgYXV0 aG9yaVphdGlvbiBwcm90b2NvbCDigJMgQWNjdXJhdGUgZGVzY3JpcHRpb24uDQoNCg0KDQpXb3Vs ZG4ndCBvYmplY3QgdG86DQoNCiAgICAqIEFBdXRoWiAgICBBbHRlcm5hdGl2ZSBBdXRob3JpemF0 aW9uIFByb3RvY29sIChBQXV0aFopDQoNCiAgICAqIEFaQVJQICAgIEF1dGhvcmlaZWQgQWNjZXNz IHRvIFJlc291cmNlcyBQcm90b2NvbA0KDQogICAgKiBBWkFSQVAgICAgQXV0aG9yaVphdGlvbiBB bmQgUmVzb3VyY2UgQWNjZXNzIFByb3RvY29sDQoNCiAgICAqIEJlQkF1dGhaICAgIEJhY2stZW5k IEJhc2VkIEF1dGhvcml6YXRpb24gUHJvdG9jb2wNCg0KICAgICogREFaQVJBUCAgICBEZWxlZ2F0 ZWQgQXV0aG9yaVphdGlvbiBBbmQgUmVzb3VyY2UgQWNjZXNzIFByb3RvY29sDQoNCiAgICAqIFRJ Tk9BICAgVGhpcyBJcyBOb3QgT0F1dGgNCg0KDQoNCk9iamVjdCB0bzoNCg0KICAgICogQllPQXV0 aFogICAgQnVpbGQtWW91ci1Pd24gQXV0aG9yaXphdGlvbiBQcm90b2NvbCDigJMgVG9vIGNoZWVz eS4NCg0KICAgICogQ1BBQVAgICAgQ29tcHJlaGVuc2l2ZSBQcml2aWxlZ2VkIEF1dGhlbnRpY2F0 aW9uIEF1dGhvcml6YXRpb24gUHJvdG9jb2wg4oCTIFRvbyBtdWNoIGxpa2UgYSBtZWRpY2FsIGRl dmljZSBuYW1lLg0KDQogICAgKiBESVlBdXRoWiAgICBEby1JdC1Zb3Vyc2VsZiBBdXRob3JpemF0 aW9uIFByb3RvY29sIOKAkyBUb28gY3V0ZS4NCg0KICAgICogSURQQXV0aFogICAgSW50ZW50IERy aXZlbiBQcm90b2NvbCBmb3IgQXV0aG9yaXphdGlvbiDigJMgSURQIGFscmVhZHkgbWVhbnMgc29t ZXRoaW5nIGVsc2UuDQoNCiAgICAqIFRJQUFQICAgIFRva2VuaXplZCBJZGVudGl0eSBhbmQgQWNj ZXNzIFByb3RvY29sIOKAkyBJIGRvbuKAmXQga25vdyB3aGF0IOKAnHRva2VuaXplZOKAnSBpcyBy ZWZlcnJpbmcgdG8gaGVyZS4NCg0KICAgICogVElERUF1dGggICAgVHJ1c3QgdmlhIEludGVudCBE cml2ZW4gRXh0ZW5zaW9uIEF1dGgg4oCTIEkgZG9u4oCZdCBrbm93IHdoYXQg4oCcaW50ZW504oCd IGlzIHJlZmVycmluZyB0byBoZXJlLg0KDQogICAgKiBUSURZQXV0aCAgICBUcnVzdCB2aWEgSW50 ZW50IERyaXZlbiBZaWVsZCBBdXRoIOKAkyBJIGRvbuKAmXQga25vdyB3aGF0IOKAnGludGVudOKA nSBpcyByZWZlcnJpbmcgdG8gaGVyZS4NCg0KICAgICogVElFQXV0aCAgICBUcnVzdCB2aWEgSW50 ZW50IEV4dGVuc2lvbiBBdXRoIOKAkyBJIGRvbuKAmXQga25vdyB3aGF0IOKAnGludGVudOKAnSBp cyByZWZlcnJpbmcgdG8gaGVyZS4NCg0KICAgICogVFhBdXRoICAgIFRlc3RhYmxlIGVYdGVuc2li bGUgQXV0aG9yaXphdGlvbiDigJMgSSBkb27igJl0IGtub3cgd2hhdCDigJx0ZXN0YWJsZeKAnSBp cyByZWZlcnJpbmcgdG8gaGVyZS4NCg0KICAgICogVHhBdXRoICAgICAgVHJhbnNtaXNzaW9uIG9m IEF1dGhvcml0eSDigJMgSXTigJlzIGRlbGVnYXRpb24gb2YgYXV0aG9yaXR5IOKAkyBub3QgdHJh bnNmZXIgb2YgYXV0aG9yaXR5Lg0KDQogICAgKiBUWEF1dGggICAgICBUcnVseSBlWHRlbnNpYmxl IEF1dGhvcml6YXRpb24g4oCTIFRvbyBjdXRlLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KDQo= --_000_CH2PR00MB0678F2BD3C70191D28A639E5F5890CH2PR00MB0678namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFp blRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGI+UHJlZmVyOjxvOnA+PC9vOnA+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAqIEdOQVAmbmJzcDsmbmJz cDsmbmJzcDsgR3JhbnQgTmVnb3RpYXRpb24gYW5kIEF1dGhvcml6YXRpb24gUHJvdG9jb2wg4oCT IFRoZSBmb2N1cyBvbiBncmFudHMgaXMgY29ycmVjdC4mbmJzcDsgQW5kIGl04oCZcyBhIHNuYXBw eSBuYW1lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7ICogR3JhblBybyZuYnNwOyZuYnNwOyZuYnNwOyBHUkFudCBOZWdvdGlhdGlvbiBQ cm90b2NvbCDigJMgVGhlIGZvY3VzIG9uIGdyYW50cyBpcyBjb3JyZWN0LiZuYnNwOyBQcm9ub3Vu Y2VhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7ICogTklSQUQmbmJzcDsmbmJzcDsmbmJzcDsgTmVnb3RpYXRpb24gb2YgSW50ZW50 IFJlZ2lzdHJhdGlvbiBhbmQgQXV0aG9yaXR5IERlbGVnYXRpb24g4oCTIENvb2wgc2NpLWZpIHNv dW5kaW5nIG5hbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgKiBQQXV0aFombmJzcDsmbmJzcDsmbmJzcDsgUHJvdG9jb2wgZm9yIEF1 dGhvcml6YXRpb24g4oCTIEFjY3VyYXRlIGRlc2NyaXB0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogUmVmQXV0aFombmJzcDsm bmJzcDsmbmJzcDsgUmVmYWN0b3JlZCBBdXRob3JpemF0aW9uIFByb3RvY29sIOKAkyBBY2N1cmF0 ZSBkZXNjcmlwdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyAqIFJlQXV0aFombmJzcDsmbmJzcDsmbmJzcDsgUmVpbWFnaW5lZCBB dXRob3JpemF0aW9uIFByb3RvY29sIOKAkyBBY2N1cmF0ZSBkZXNjcmlwdGlvbi48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAqIFdSQUMg KFdlYiBSZXNvdXJjZSBBdXRob3JpemF0aW9uIENvbGxhYm9yYXRpb24pIC0gUHJvbm91bmNlZCBs aWtlIFJBQ0sg4oCTIENvb2wgbmFtZSwgd2l0aCBoaXN0b3J5IGdvaW5nIGJhY2sgdG8gT0F1dGgg V1JBUC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyAqIFhBdXRoWiZuYnNwOyZuYnNwOyZuYnNwOyBlWHRlbnNpYmxlIGF1dGhvcmlaYXRp b24gcHJvdG9jb2wg4oCTIEFjY3VyYXRlIGRlc2NyaXB0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PGI+PG86cD4mbmJzcDs8L286cD48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PGI+V291bGRuJ3Qgb2JqZWN0IHRvOjxvOnA+PC9vOnA+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAqIEFBdXRoWiZu YnNwOyZuYnNwOyZuYnNwOyBBbHRlcm5hdGl2ZSBBdXRob3JpemF0aW9uIFByb3RvY29sIChBQXV0 aFopPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsgKiBBWkFSUCZuYnNwOyZuYnNwOyZuYnNwOyBBdXRob3JpWmVkIEFjY2VzcyB0byBSZXNv dXJjZXMgUHJvdG9jb2w8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyAqIEFaQVJBUCZuYnNwOyZuYnNwOyZuYnNwOyBBdXRob3JpWmF0aW9u IEFuZCBSZXNvdXJjZSBBY2Nlc3MgUHJvdG9jb2w8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAqIEJlQkF1dGhaJm5ic3A7Jm5ic3A7Jm5i c3A7IEJhY2stZW5kIEJhc2VkIEF1dGhvcml6YXRpb24gUHJvdG9jb2w8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAqIERBWkFSQVAmbmJz cDsmbmJzcDsmbmJzcDsgRGVsZWdhdGVkIEF1dGhvcmlaYXRpb24gQW5kIFJlc291cmNlIEFjY2Vz cyBQcm90b2NvbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICogVElOT0EmbmJzcDsmbmJzcDsgVGhpcyBJcyBOb3QgT0F1dGg8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PGI+T2JqZWN0IHRvOjxvOnA+PC9vOnA+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAqIEJZT0F1dGhaJm5i c3A7Jm5ic3A7Jm5ic3A7IEJ1aWxkLVlvdXItT3duIEF1dGhvcml6YXRpb24gUHJvdG9jb2wg4oCT IFRvbyBjaGVlc3kuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgKiBDUEFBUCZuYnNwOyZuYnNwOyZuYnNwOyBDb21wcmVoZW5zaXZlIFBy aXZpbGVnZWQgQXV0aGVudGljYXRpb24gQXV0aG9yaXphdGlvbiBQcm90b2NvbCDigJMgVG9vIG11 Y2ggbGlrZSBhIG1lZGljYWwgZGV2aWNlIG5hbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgKiBESVlBdXRoWiZuYnNwOyZuYnNwOyZu YnNwOyBEby1JdC1Zb3Vyc2VsZiBBdXRob3JpemF0aW9uIFByb3RvY29sIOKAkyBUb28gY3V0ZS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyAqIElEUEF1dGhaJm5ic3A7Jm5ic3A7Jm5ic3A7IEludGVudCBEcml2ZW4gUHJvdG9jb2wgZm9y IEF1dGhvcml6YXRpb24g4oCTIElEUCBhbHJlYWR5IG1lYW5zIHNvbWV0aGluZyBlbHNlLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICog VElBQVAmbmJzcDsmbmJzcDsmbmJzcDsgVG9rZW5pemVkIElkZW50aXR5IGFuZCBBY2Nlc3MgUHJv dG9jb2wg4oCTIEkgZG9u4oCZdCBrbm93IHdoYXQg4oCcdG9rZW5pemVk4oCdIGlzIHJlZmVycmlu ZyB0byBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICogVElERUF1dGggJm5ic3A7Jm5ic3A7Jm5ic3A7VHJ1c3QgdmlhIEludGVu dCBEcml2ZW4gRXh0ZW5zaW9uIEF1dGgg4oCTIEkgZG9u4oCZdCBrbm93IHdoYXQg4oCcaW50ZW50 4oCdIGlzIHJlZmVycmluZyB0byBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogVElEWUF1dGgmbmJzcDsmbmJzcDsmbmJzcDsg VHJ1c3QgdmlhIEludGVudCBEcml2ZW4gWWllbGQgQXV0aCDigJMgSSBkb27igJl0IGtub3cgd2hh dCDigJxpbnRlbnTigJ0gaXMgcmVmZXJyaW5nIHRvIGhlcmUuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgKiBUSUVBdXRoJm5ic3A7Jm5i c3A7Jm5ic3A7IFRydXN0IHZpYSBJbnRlbnQgRXh0ZW5zaW9uIEF1dGgg4oCTIEkgZG9u4oCZdCBr bm93IHdoYXQg4oCcaW50ZW504oCdIGlzIHJlZmVycmluZyB0byBoZXJlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogVFhBdXRoJm5i c3A7Jm5ic3A7Jm5ic3A7IFRlc3RhYmxlIGVYdGVuc2libGUgQXV0aG9yaXphdGlvbiDigJMgSSBk b27igJl0IGtub3cgd2hhdCDigJx0ZXN0YWJsZeKAnSBpcyByZWZlcnJpbmcgdG8gaGVyZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyAq IFR4QXV0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUcmFuc21pc3Npb24gb2YgQXV0 aG9yaXR5IOKAkyBJdOKAmXMgZGVsZWdhdGlvbiBvZiBhdXRob3JpdHkg4oCTIG5vdCB0cmFuc2Zl ciBvZiBhdXRob3JpdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsgKiBUWEF1dGgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VHJ1bHkgZVh0ZW5zaWJsZSBBdXRob3JpemF0aW9uIOKAkyBUb28gY3V0ZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC0tIE1pa2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CH2PR00MB0678F2BD3C70191D28A639E5F5890CH2PR00MB0678namp_-- From nobody Fri Jun 5 07:59:17 2020 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 E9AF73A0812 for ; Fri, 5 Jun 2020 07:59:15 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 kFd9aeHA_vFz for ; Fri, 5 Jun 2020 07:59:13 -0700 (PDT) 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 45CED3A07E6 for ; Fri, 5 Jun 2020 07:59:10 -0700 (PDT) Received: from [192.168.1.14] (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 055Ex6gn021007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 5 Jun 2020 10:59:07 -0400 From: Justin Richer Message-Id: <1E2C45F5-3879-47ED-BDAD-5C3271D70D78@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_334B113E-F7C9-4326-B871-121A2BC00A11" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 5 Jun 2020 10:59:06 -0400 In-Reply-To: Cc: Yaron Sheffer , "txauth@ietf.org" To: Mike Jones References: <9FD428B4-F3C1-426B-9677-611F5FEC85C8@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Call for WG name preferences 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, 05 Jun 2020 14:59:16 -0000 --Apple-Mail=_334B113E-F7C9-4326-B871-121A2BC00A11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Since there seems to be some confusion by a few people about the term = =E2=80=9CIntent=E2=80=9D and its inclusion here, I wanted to clarify = that for people. There is a protocol feature is variously known as = =E2=80=9Cintent registration=E2=80=9D or =E2=80=9Clodging intent=E2=80=9D,= where the party starting the process (the client) makes a statement = about what it wants to do and is then given the tools to complete the = next steps to do that. It=E2=80=99s a key feature of the pattern we=E2=80=99= re looking to codify in this group=E2=80=99s work. The FAPI working group in the OIDF has done a lot of work around it, and = you see this style in a bunch of different financial APIs dating back = decades: = https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.= md = = https://bitbucket.org/openid/fapi/issues/142/standardising-lodging-intent = Torsten Lodderstedt has a great blog post that touches on it as well: = https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-= think-oauth-scopes-2326e2038948 = And it=E2=80=99s the basis behind OAuth 2.0=E2=80=99s Pushed = Authorization Request (PAR) extension that=E2=80=99s happening now: https://tools.ietf.org/html/draft-ietf-oauth-par = = https://medium.com/oauth-2/pushed-authorization-requests-draft-adopted-by-= oauth-working-group-a1060007150f = To be clear, I=E2=80=99m not saying this is sufficient for it driving = the name, but I do think it=E2=80=99s important that people be familiar = with this terminology as its likely to come up again as the work = progresses.=20 =E2=80=94 Justin > On Jun 4, 2020, at 7:25 PM, Mike Jones = wrote: >=20 > Prefer: > * GNAP Grant Negotiation and Authorization Protocol =E2=80=93 = The focus on grants is correct. And it=E2=80=99s a snappy name. > * GranPro GRAnt Negotiation Protocol =E2=80=93 The focus on = grants is correct. Pronounceable. > * NIRAD Negotiation of Intent Registration and Authority = Delegation =E2=80=93 Cool sci-fi sounding name. > * PAuthZ Protocol for Authorization =E2=80=93 Accurate = description. > * RefAuthZ Refactored Authorization Protocol =E2=80=93 Accurate = description. > * ReAuthZ Reimagined Authorization Protocol =E2=80=93 Accurate = description. > * WRAC (Web Resource Authorization Collaboration) - Pronounced = like RACK =E2=80=93 Cool name, with history going back to OAuth WRAP. > * XAuthZ eXtensible authoriZation protocol =E2=80=93 Accurate = description. > =20 > Wouldn't object to: > * AAuthZ Alternative Authorization Protocol (AAuthZ) > * AZARP AuthoriZed Access to Resources Protocol > * AZARAP AuthoriZation And Resource Access Protocol > * BeBAuthZ Back-end Based Authorization Protocol > * DAZARAP Delegated AuthoriZation And Resource Access Protocol > * TINOA This Is Not OAuth > =20 > Object to: > * BYOAuthZ Build-Your-Own Authorization Protocol =E2=80=93 Too = cheesy. > * CPAAP Comprehensive Privileged Authentication Authorization = Protocol =E2=80=93 Too much like a medical device name. > * DIYAuthZ Do-It-Yourself Authorization Protocol =E2=80=93 Too = cute. > * IDPAuthZ Intent Driven Protocol for Authorization =E2=80=93 = IDP already means something else. > * TIAAP Tokenized Identity and Access Protocol =E2=80=93 I = don=E2=80=99t know what =E2=80=9Ctokenized=E2=80=9D is referring to = here. > * TIDEAuth Trust via Intent Driven Extension Auth =E2=80=93 I = don=E2=80=99t know what =E2=80=9Cintent=E2=80=9D is referring to here. > * TIDYAuth Trust via Intent Driven Yield Auth =E2=80=93 I = don=E2=80=99t know what =E2=80=9Cintent=E2=80=9D is referring to here. > * TIEAuth Trust via Intent Extension Auth =E2=80=93 I don=E2=80=99= t know what =E2=80=9Cintent=E2=80=9D is referring to here. > * TXAuth Testable eXtensible Authorization =E2=80=93 I don=E2=80=99= t know what =E2=80=9Ctestable=E2=80=9D is referring to here. > * TxAuth Transmission of Authority =E2=80=93 It=E2=80=99s = delegation of authority =E2=80=93 not transfer of authority. > * TXAuth Truly eXtensible Authorization =E2=80=93 Too cute. > =20 > -- Mike > =20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_334B113E-F7C9-4326-B871-121A2BC00A11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Since= there seems to be some confusion by a few people about the term = =E2=80=9CIntent=E2=80=9D and its inclusion here, I wanted to clarify = that for people. There is a protocol feature is variously known as = =E2=80=9Cintent registration=E2=80=9D or =E2=80=9Clodging intent=E2=80=9D,= where the party starting the process (the client) makes a statement = about what it wants to do and is then given the tools to complete the = next steps to do that. It=E2=80=99s a key feature of the pattern = we=E2=80=99re looking to codify in this group=E2=80=99s work.

The FAPI working group = in the OIDF has done a lot of work around it, and you see this style in = a bunch of different financial APIs dating back decades:

https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodg= ing_Intent.md

https://bitbucket.org/openid/fapi/issues/142/standardising-lodg= ing-intent


Torsten Lodderstedt has = a great blog post that touches on it as well:

https://medium.com/oauth-2/transaction-authorization-or-why-we-= need-to-re-think-oauth-scopes-2326e2038948

And it=E2=80=99s the basis behind OAuth = 2.0=E2=80=99s Pushed Authorization Request (PAR) extension that=E2=80=99s = happening now:

https://tools.ietf.org/html/draft-ietf-oauth-par

https://medium.com/oauth-2/pushed-authorization-requests-draft-= adopted-by-oauth-working-group-a1060007150f


To = be clear, I=E2=80=99m not saying this is sufficient for it driving the = name, but I do think it=E2=80=99s important that people be familiar with = this terminology as its likely to come up again as the work = progresses. 

 =E2=80=94 = Justin

On Jun 4, 2020, at 7:25 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

Prefer:
    * GNAP    Grant Negotiation = and Authorization Protocol =E2=80=93 The focus on grants is = correct.  And it=E2=80=99s a snappy name.
    * GranPro    GRAnt = Negotiation Protocol =E2=80=93 The focus on grants is correct.  = Pronounceable.
    * NIRAD    Negotiation of = Intent Registration and Authority Delegation =E2=80=93 Cool sci-fi = sounding name.
    * PAuthZ    Protocol for = Authorization =E2=80=93 Accurate description.
    * RefAuthZ    Refactored = Authorization Protocol =E2=80=93 Accurate description.
    * ReAuthZ    Reimagined = Authorization Protocol =E2=80=93 Accurate description.
    * WRAC (Web Resource Authorization = Collaboration) - Pronounced like RACK =E2=80=93 Cool name, with history = going back to OAuth WRAP.
    * XAuthZ    eXtensible = authoriZation protocol =E2=80=93 Accurate description.
 
Wouldn't object to:
    * AAuthZ    Alternative = Authorization Protocol (AAuthZ)
    * = AZARP    AuthoriZed Access to Resources Protocol
    * AZARAP    AuthoriZation = And Resource Access Protocol
    * = BeBAuthZ    Back-end Based Authorization Protocol
    * DAZARAP    Delegated = AuthoriZation And Resource Access Protocol
    * TINOA   = This Is Not OAuth
 
Object to:
    * = BYOAuthZ    Build-Your-Own Authorization Protocol =E2=80=93= Too cheesy.
    * CPAAP    Comprehensive = Privileged Authentication Authorization Protocol =E2=80=93 Too much like = a medical device name.
    * DIYAuthZ    = Do-It-Yourself Authorization Protocol =E2=80=93 Too cute.
    * IDPAuthZ    Intent Driven = Protocol for Authorization =E2=80=93 IDP already means something = else.
    * TIAAP    Tokenized = Identity and Access Protocol =E2=80=93 I don=E2=80=99t know what = =E2=80=9Ctokenized=E2=80=9D is referring to here.
    * TIDEAuth    Trust via = Intent Driven Extension Auth =E2=80=93 I don=E2=80=99t know what = =E2=80=9Cintent=E2=80=9D is referring to here.
    * TIDYAuth    Trust via = Intent Driven Yield Auth =E2=80=93 I don=E2=80=99t know what = =E2=80=9Cintent=E2=80=9D is referring to here.
    * TIEAuth    Trust via = Intent Extension Auth =E2=80=93 I don=E2=80=99t know what =E2=80=9Cintent=E2= =80=9D is referring to here.
    * = TXAuth    Testable eXtensible Authorization =E2=80=93 I = don=E2=80=99t know what =E2=80=9Ctestable=E2=80=9D is referring to = here.
    * TxAuth      = Transmission of Authority =E2=80=93 It=E2=80=99s delegation of authority = =E2=80=93 not transfer of authority.
    * = TXAuth      Truly eXtensible Authorization =E2=80= =93 Too cute.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
-- Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_334B113E-F7C9-4326-B871-121A2BC00A11-- From nobody Fri Jun 5 08:09:46 2020 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 703F93A0793 for ; Fri, 5 Jun 2020 08:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 iMlBODoq01b6 for ; Fri, 5 Jun 2020 08:09:41 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 62D813A078A for ; Fri, 5 Jun 2020 08:09:41 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id g28so10010455qkl.0 for ; Fri, 05 Jun 2020 08:09:41 -0700 (PDT) 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 :mime-version; bh=HXpl6HVHPnIgDHemOGMUzr/dB0uCdW6MQfEEBLACK9k=; b=C1IePVYgHSzV44t7bvOXvfSTveio79DXsoO5DcGKuamspC6cM2lylIga1E50npujsW 0QjKtyGU0x7i8C9ltoKpLxHeax0EQ5586tzM5F2V+nqUnnQazHDEGRfmRGhd7R8VM2Fp LFpcjSqo8JtgZK+jSrJDFO1hFp3CTifOpzYi/OwaLn9aNYZ0tzvOFxiy7o0ngF6ArGXy 8BfsAKcyNiVCvoTEzznweK5B5k8k8ruWsvvJjalA3jlB6ji0EwspIHHU6caiGU/uBcRh ZvMH0+lZeZzXD9AWt1by95xy/egC+28UAyLOCUkn/tPtySsmnquY6GMzmO3r2dNF237f lilQ== 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:mime-version; bh=HXpl6HVHPnIgDHemOGMUzr/dB0uCdW6MQfEEBLACK9k=; b=RaZQ20skTfFo2uJHegAU+/3W35vvn3KLMxvo6BABO0V0iq+aWR23t3IOlN3ro8AOPz JA4VR7YrwKnQbTp8I16pRxaMix9LHlBH55GyEnBAFPtvmOGWKpLDehCsNx0b38DqRHON VHIRQjEW/BOHSqd+d89P/CQSD53mOt8Z/AX/6dwo8BlWYcUOTvJ6fnmULOCFskp4LjVy IF2MMmkPWh7XIzycicsfbgykY0TCRug5dMKBSMnkYvGI9zNMEAyQhDnA00dd0+51nisj TGPQJWUxXFBcUnOo78OI6HRJoJ1uqvqk+24I/xcSioF8LvnpwdQ5EtFHuT0KJWO6IeI3 J5JA== X-Gm-Message-State: AOAM530Z1N8KW9xXeg0z7sE1mzxgpxQ27bfLw/VrXruOTtTPK8RLM63v StkUz5pOeJbB2yq+xXutxOk= X-Google-Smtp-Source: ABdhPJxc/foxLXZeLELYE0vazum8IBcklXXITzONensznd7Rs81/LpB6YiX84AAso3aCwqO6iFExGw== X-Received: by 2002:a37:67c7:: with SMTP id b190mr10157933qkc.228.1591369780360; Fri, 05 Jun 2020 08:09:40 -0700 (PDT) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id w94sm24521qte.19.2020.06.05.08.09.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 08:09:39 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.37.20051002 Date: Fri, 05 Jun 2020 18:09:36 +0300 From: Yaron Sheffer To: Justin Richer , Mike Jones CC: "txauth@ietf.org" Message-ID: <3C69EF55-FC4D-44D1-A619-8736936E4E6D@gmail.com> Thread-Topic: [Txauth] Call for WG name preferences - done! Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3674225378_1658071922" Archived-At: Subject: Re: [Txauth] Call for WG name preferences - done! 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, 05 Jun 2020 15:09:44 -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_3674225378_1658071922 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Folks, we are past the deadline for name selections. Thank you all who shar= ed their thoughts on time. Dick and I will go through all the responses and = (most hopefully) will be able to announce the group=E2=80=99s consensus and submit= it to the AD and IESG. =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: Justin Richer Date: Friday, June 5, 2020 at 17:59 To: Mike Jones Cc: Yaron Sheffer , "txauth@ietf.org" Subject: Re: [Txauth] Call for WG name preferences =20 Since there seems to be some confusion by a few people about the term =E2=80=9CIn= tent=E2=80=9D and its inclusion here, I wanted to clarify that for people. There i= s a protocol feature is variously known as =E2=80=9Cintent registration=E2=80=9D or =E2=80=9Cl= odging intent=E2=80=9D, where the party starting the process (the client) makes a = statement about what it wants to do and is then given the tools to complete = the next steps to do that. It=E2=80=99s a key feature of the pattern we=E2=80=99re looki= ng to codify in this group=E2=80=99s work. =20 The FAPI working group in the OIDF has done a lot of work around it, and yo= u see this style in a bunch of different financial APIs dating back decades: =20 https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.m= d =20 https://bitbucket.org/openid/fapi/issues/142/standardising-lodging-intent =20 =20 Torsten Lodderstedt has a great blog post that touches on it as well: =20 https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-t= hink-oauth-scopes-2326e2038948 =20 And it=E2=80=99s the basis behind OAuth 2.0=E2=80=99s Pushed Authorization Request (PAR= ) extension that=E2=80=99s happening now: =20 https://tools.ietf.org/html/draft-ietf-oauth-par =20 https://medium.com/oauth-2/pushed-authorization-requests-draft-adopted-by-o= auth-working-group-a1060007150f =20 =20 To be clear, I=E2=80=99m not saying this is sufficient for it driving the name, b= ut I do think it=E2=80=99s important that people be familiar with this terminology= as its likely to come up again as the work progresses.=20 =20 =E2=80=94 Justin On Jun 4, 2020, at 7:25 PM, Mike Jones wrote: =20 Prefer: * GNAP Grant Negotiation and Authorization Protocol =E2=80=93 The focus on= grants is correct. And it=E2=80=99s a snappy name. * GranPro GRAnt Negotiation Protocol =E2=80=93 The focus on grants is corr= ect. Pronounceable. * NIRAD Negotiation of Intent Registration and Authority Delegation = =E2=80=93 Cool sci-fi sounding name. * PAuthZ Protocol for Authorization =E2=80=93 Accurate description. * RefAuthZ Refactored Authorization Protocol =E2=80=93 Accurate descriptio= n. * ReAuthZ Reimagined Authorization Protocol =E2=80=93 Accurate description= . * WRAC (Web Resource Authorization Collaboration) - Pronounced like RAC= K =E2=80=93 Cool name, with history going back to OAuth WRAP. * XAuthZ eXtensible authoriZation protocol =E2=80=93 Accurate description. =20 Wouldn't object to: * AAuthZ Alternative Authorization Protocol (AAuthZ) * AZARP AuthoriZed Access to Resources Protocol * AZARAP AuthoriZation And Resource Access Protocol * BeBAuthZ Back-end Based Authorization Protocol * DAZARAP Delegated AuthoriZation And Resource Access Protocol * TINOA This Is Not OAuth =20 Object to: * BYOAuthZ Build-Your-Own Authorization Protocol =E2=80=93 Too cheesy. * CPAAP Comprehensive Privileged Authentication Authorization Protoc= ol =E2=80=93 Too much like a medical device name. * DIYAuthZ Do-It-Yourself Authorization Protocol =E2=80=93 Too cute. * IDPAuthZ Intent Driven Protocol for Authorization =E2=80=93 IDP already = means something else. * TIAAP Tokenized Identity and Access Protocol =E2=80=93 I don=E2=80=99t know wh= at =E2=80=9Ctokenized=E2=80=9D is referring to here. * TIDEAuth Trust via Intent Driven Extension Auth =E2=80=93 I don=E2=80=99t know= what =E2=80=9Cintent=E2=80=9D is referring to here. * TIDYAuth Trust via Intent Driven Yield Auth =E2=80=93 I don=E2=80=99t know wha= t =E2=80=9Cintent=E2=80=9D is referring to here. * TIEAuth Trust via Intent Extension Auth =E2=80=93 I don=E2=80=99t know what =E2=80= =9Cintent=E2=80=9D is referring to here. * TXAuth Testable eXtensible Authorization =E2=80=93 I don=E2=80=99t know what =E2= =80=9Ctestable=E2=80=9D is referring to here. * TxAuth Transmission of Authority =E2=80=93 It=E2=80=99s delegation of author= ity =E2=80=93 not transfer of authority. * TXAuth Truly eXtensible Authorization =E2=80=93 Too cute. =20 -- Mike =20 --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth =20 --B_3674225378_1658071922 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Folks, we are past the deadline for name selection= s. Thank you all who shared their thoughts on time. Dick and I will go throu= gh all the responses and (most hopefully) will be able to announce the group= =E2=80=99s consensus and submit it to the AD and IESG.

 

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

 

From: Justin Richer <jricher@mit.edu>
Date: Friday, June 5, 2= 020 at 17:59
To: Mike Jones <Michael.Jones=3D40microsoft.com@dmar= c.ietf.org>
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, &q= uot;txauth@ietf.org" <txauth@ietf.org>
Subject: Re: [Tx= auth] Call for WG name preferences

 

Since there seems to= be some confusion by a few people about the term =E2=80=9CIntent=E2=80=9D and its inclu= sion here, I wanted to clarify that for people. There is a protocol feature = is variously known as =E2=80=9Cintent registration=E2=80=9D or =E2=80=9Clodging intent=E2=80=9D, whe= re the party starting the process (the client) makes a statement about what = it wants to do and is then given the tools to complete the next steps to do = that. It=E2=80=99s a key feature of the pattern we=E2=80=99re looking to codify in = this group=E2=80=99s work.

 =

The FAPI working group in the OIDF has don= e a lot of work around it, and you see this style in a bunch of different fi= nancial APIs dating back decades:

 

 

 = ;

 

Torsten Lodderstedt has a great blog post that touches on it= as well:

 

<= /div>

=  

And it=E2=80=99s the basis behind OA= uth 2.0=E2=80=99s Pushed Authorization Request (PAR) extension that=E2=80=99s happening = now:

 

=

https://tools.ietf.org/html/draft-ietf-oauth-par

 

 



<= o:p>

=  

Prefer:

    * GNAP    Gran= t Negotiation and Authorization Protocol =E2=80=93 The focus on grants is correct.=   And it=E2=80=99s a snappy name.

    * GranPro    GRAnt Negotiation Protocol =E2= =80=93 The focus on grants is correct.  Pronounceable.

=

    * NIRAD    Negotia= tion of Intent Registration and Authority Delegation =E2=80=93 Cool sci-fi soundin= g name.

    * PAu= thZ    Protocol for Authorization =E2=80=93 Accurate description.

    * RefAuthZ&nbs= p;   Refactored Authorization Protocol =E2=80=93 Accurate description.

    * ReAuthZ = ;   Reimagined Authorization Protocol =E2=80=93 Accurate description.

    * WRAC (Web Res= ource Authorization Collaboration) - Pronounced like RACK =E2=80=93 Cool name, wit= h history going back to OAuth WRAP.

    * XAuthZ    eXtensible authoriZation p= rotocol =E2=80=93 Accurate description.

 

Wouldn't obje= ct to:

    * = AAuthZ    Alternative Authorization Protocol (AAuthZ)

    * AZARP  &= nbsp; AuthoriZed Access to Resources Protocol

    * AZARAP    AuthoriZation An= d Resource Access Protocol

 = ;   * BeBAuthZ    Back-end Based Authorization Prot= ocol

    * DAZARA= P    Delegated AuthoriZation And Resource Access Protocol

    * TINOA &nb= sp; This Is Not OAuth

 

Object to:

    * BYOAuthZ    B= uild-Your-Own Authorization Protocol =E2=80=93 Too cheesy.

    * CPAAP    Comprehens= ive Privileged Authentication Authorization Protocol =E2=80=93 Too much like a med= ical device name.

  &n= bsp; * DIYAuthZ    Do-It-Yourself Authorization Protocol =E2=80=93 = Too cute.

    * I= DPAuthZ    Intent Driven Protocol for Authorization =E2=80=93 IDP a= lready means something else.

&nb= sp;   * TIAAP    Tokenized Identity and Access Prot= ocol =E2=80=93 I don=E2=80=99t know what =E2=80=9Ctokenized=E2=80=9D is referring to here.

    * TIDEAuth   = ; Trust via Intent Driven Extension Auth =E2=80=93 I don=E2=80=99t know what =E2=80=9Cint= ent=E2=80=9D is referring to here.

&nb= sp;   * TIDYAuth    Trust via Intent Driven Yield A= uth =E2=80=93 I don=E2=80=99t know what =E2=80=9Cintent=E2=80=9D is referring to here.

    * TIEAuth   = ; Trust via Intent Extension Auth =E2=80=93 I don=E2=80=99t know what =E2=80=9Cintent=E2=80=9D is re= ferring to here.

  &nb= sp; * TXAuth    Testable eXtensible Authorization =E2=80=93 I don=E2=80= =99t know what =E2=80=9Ctestable=E2=80=9D is referring to here.

<= p class=3DMsoNormal>    * TxAuth      = Transmission of Authority =E2=80=93 It=E2=80=99s delegation of authority =E2=80=93 not transfe= r of authority.

  &nbs= p; * TXAuth      Truly eXtensible Authorization =E2=80=93= Too cute.

 

=

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

 

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

=  

--B_3674225378_1658071922-- From nobody Fri Jun 5 10:26:02 2020 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 4B8E53A0A51 for ; Fri, 5 Jun 2020 10:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 J5GZiV57JH9i for ; Fri, 5 Jun 2020 10:25:58 -0700 (PDT) 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 CCAC83A0A4E for ; Fri, 5 Jun 2020 10:25:57 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id i27so1753838ljb.12 for ; Fri, 05 Jun 2020 10:25:57 -0700 (PDT) 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=wzZ0T6jQKEJLw6HX9QJkcD+ted6M81f4mT5j321RXR4=; b=CsKZ4HdoZKil/J91H/2VEej7sjLUFzhrUtscIGodWbLnO8fMh5IPkT1YnFQ837K2Fa XwD5Ui9s5/44jtMHywjGeyp7YqmY0dqCgOY2ACBxFpvA+YXxqwl8UKUDkmGOF56P7YWF 9BOrA8afKAuDjCG98qY2IrgOdR8oFRjQSMEx1AcpKGLOghMeYjnSAC+b1h8WWUsRNI1n 70S8Qovr2Q1UF+IfCPhcqUw+F9bNLx0SRf5TPkI9aJnl1uyRJbTjdvoMfY5FnmBSgWFO NWRPrXLqi584IrDt117M099I4xzfzbA77gdat4qcT4WujvA2G2TdjWWvR4ih6x9z3rcw LMLw== 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=wzZ0T6jQKEJLw6HX9QJkcD+ted6M81f4mT5j321RXR4=; b=nYO8cn4KL8HDA8Zo/MHVjJshcjpG9PJNsX+CA9jMEiM5AFTOE88FZaxPPV4Bp8gtXw nKH1TmbxSpdWty1TW1ISuw+qiXN7qXT8eAJ0Qm74auDowFhtaMuyO6HzkXS5bzWUBbaz l+lxTaF6ZgUDv60os6VHnwt4fy3WIFBNEmAAuB695bEEL7Th0euuaNBNSZxUdXHwDxgm E+L0GvzYKaRyaioX+f7+NkwXf8EACWPo0qDU9DdfCr5zyaJNkBhPXSMQjKTFqJb3hfnj xbCrF/4skZl7uiOmDLti64ubvmZ8l5it3AxIo3nB7XW0/098H5eQ8HzpYCnY5Nm0LcE2 Glkg== X-Gm-Message-State: AOAM53050lPycoP8H2+jO1jwaAmJWgzje/gj8gYtwYmEFpFsrdQ75q1l aihQqpIhb5/p5HuAqZT/ve8pDuDXA5vOcT3Lbzk= X-Google-Smtp-Source: ABdhPJyRoa4KjVBbzYPlK41HDGeNyGIuC/kGbZ7mwWaWAgoInZ1JCEtdlBRg9H8KWE+Vf3qmInhtm06VyFsQlqiV72Q= X-Received: by 2002:a05:651c:3cc:: with SMTP id f12mr5233360ljp.244.1591377955747; Fri, 05 Jun 2020 10:25:55 -0700 (PDT) MIME-Version: 1.0 References: <9FD428B4-F3C1-426B-9677-611F5FEC85C8@gmail.com> <1E2C45F5-3879-47ED-BDAD-5C3271D70D78@mit.edu> In-Reply-To: <1E2C45F5-3879-47ED-BDAD-5C3271D70D78@mit.edu> From: Dick Hardt Date: Fri, 5 Jun 2020 10:25:29 -0700 Message-ID: To: Justin Richer Cc: Mike Jones , Yaron Sheffer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c17d9e05a7598d5b" Archived-At: Subject: Re: [Txauth] Call for WG name preferences 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, 05 Jun 2020 17:26:00 -0000 --000000000000c17d9e05a7598d5b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for posting Justin, speaking for myself, I appreciate the background as I had not seen the term "intent" be used. Can you share any history why "lodging intent" was the term selected vs other choices? Why not "request"? Overused? To me, an intent is an action ie. the client saying "I am going to do X", whereas a request is asking for something, the client saying "I would like X" Or is the idea the client saying "I intend to request X"? FWIW: I don't see the term "intent" used in PAR. It is a "request". On Fri, Jun 5, 2020 at 7:59 AM Justin Richer wrote: > Since there seems to be some confusion by a few people about the term > =E2=80=9CIntent=E2=80=9D and its inclusion here, I wanted to clarify that= for people. There > is a protocol feature is variously known as =E2=80=9Cintent registration= =E2=80=9D or > =E2=80=9Clodging intent=E2=80=9D, where the party starting the process (t= he client) makes a > statement about what it wants to do and is then given the tools to comple= te > the next steps to do that. It=E2=80=99s a key feature of the pattern we= =E2=80=99re looking > to codify in this group=E2=80=99s work. > > The FAPI working group in the OIDF has done a lot of work around it, and > you see this style in a bunch of different financial APIs dating back > decades: > > > https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent= .md > > https://bitbucket.org/openid/fapi/issues/142/standardising-lodging-intent > > > Torsten Lodderstedt has a great blog post that touches on it as well: > > > https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re= -think-oauth-scopes-2326e2038948 > > And it=E2=80=99s the basis behind OAuth 2.0=E2=80=99s Pushed Authorizatio= n Request (PAR) > extension that=E2=80=99s happening now: > > https://tools.ietf.org/html/draft-ietf-oauth-par > > > https://medium.com/oauth-2/pushed-authorization-requests-draft-adopted-by= -oauth-working-group-a1060007150f > > > To be clear, I=E2=80=99m not saying this is sufficient for it driving the= name, > but I do think it=E2=80=99s important that people be familiar with this t= erminology > as its likely to come up again as the work progresses. > > =E2=80=94 Justin > > On Jun 4, 2020, at 7:25 PM, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > > *Prefer:* > * GNAP Grant Negotiation and Authorization Protocol =E2=80=93 The = focus on > grants is correct. And it=E2=80=99s a snappy name. > * GranPro GRAnt Negotiation Protocol =E2=80=93 The focus on grants= is > correct. Pronounceable. > * NIRAD Negotiation of Intent Registration and Authority Delegatio= n > =E2=80=93 Cool sci-fi sounding name. > * PAuthZ Protocol for Authorization =E2=80=93 Accurate description= . > * RefAuthZ Refactored Authorization Protocol =E2=80=93 Accurate de= scription. > * ReAuthZ Reimagined Authorization Protocol =E2=80=93 Accurate des= cription. > * WRAC (Web Resource Authorization Collaboration) - Pronounced like > RACK =E2=80=93 Cool name, with history going back to OAuth WRAP. > * XAuthZ eXtensible authoriZation protocol =E2=80=93 Accurate desc= ription. > > *Wouldn't object to:* > * AAuthZ Alternative Authorization Protocol (AAuthZ) > * AZARP AuthoriZed Access to Resources Protocol > * AZARAP AuthoriZation And Resource Access Protocol > * BeBAuthZ Back-end Based Authorization Protocol > * DAZARAP Delegated AuthoriZation And Resource Access Protocol > * TINOA This Is Not OAuth > > *Object to:* > * BYOAuthZ Build-Your-Own Authorization Protocol =E2=80=93 Too che= esy. > * CPAAP Comprehensive Privileged Authentication Authorization > Protocol =E2=80=93 Too much like a medical device name. > * DIYAuthZ Do-It-Yourself Authorization Protocol =E2=80=93 Too cut= e. > * IDPAuthZ Intent Driven Protocol for Authorization =E2=80=93 IDP = already > means something else. > * TIAAP Tokenized Identity and Access Protocol =E2=80=93 I don=E2= =80=99t know what > =E2=80=9Ctokenized=E2=80=9D is referring to here. > * TIDEAuth Trust via Intent Driven Extension Auth =E2=80=93 I don= =E2=80=99t know > what =E2=80=9Cintent=E2=80=9D is referring to here. > * TIDYAuth Trust via Intent Driven Yield Auth =E2=80=93 I don=E2= =80=99t know what > =E2=80=9Cintent=E2=80=9D is referring to here. > * TIEAuth Trust via Intent Extension Auth =E2=80=93 I don=E2=80=99= t know what > =E2=80=9Cintent=E2=80=9D is referring to here. > * TXAuth Testable eXtensible Authorization =E2=80=93 I don=E2=80= =99t know what > =E2=80=9Ctestable=E2=80=9D is referring to here. > * TxAuth Transmission of Authority =E2=80=93 It=E2=80=99s delega= tion of authority > =E2=80=93 not transfer of authority. > * TXAuth Truly eXtensible Authorization =E2=80=93 Too cute. > > -- Mike > > -- > 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 > =E1=90=A7 --000000000000c17d9e05a7598d5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for posting Justin, speaking for m= yself, I appreciate=C2=A0the=C2=A0background as I had not seen the term &qu= ot;intent" be used.=C2=A0

Can you share any history why "lodging intent" was the term = selected vs other choices? Why not "request"? Overused?

To me, an intent is an action ie. the client say= ing "I am going to do=C2=A0X", whereas a request is asking for so= mething, the client saying "I would like X"

<= div>Or is the idea=C2=A0the client saying "I intend to request X"= ?

FWIW: I don't s= ee the term "intent" used in PAR. It is a "request".

On Fri, Jun 5, 2020 at 7:59 AM Justin Richer <jricher@mit.edu> wrote:
Since = there seems to be some confusion by a few people about the term =E2=80=9CIn= tent=E2=80=9D and its inclusion here, I wanted to clarify that for people. = There is a protocol feature is variously known as =E2=80=9Cintent registrat= ion=E2=80=9D or =E2=80=9Clodging intent=E2=80=9D, where the party starting = the process (the client) makes a statement about what it wants to do and is= then given the tools to complete the next steps to do that.=C2=A0It=E2=80= =99s a key feature of the pattern we=E2=80=99re looking to codify in this g= roup=E2=80=99s work.

The FAPI working group in the OIDF = has done a lot of work around it, and you see this style in a bunch of diff= erent financial APIs dating back decades:




Torsten Lodderstedt = has a great blog post that touches on it as well:


And it=E2=80=99s the basis be= hind OAuth 2.0=E2=80=99s Pushed Authorization Request (PAR) extension that= =E2=80=99s happening now:




To be clear, I=E2=80=99m= not saying this is sufficient for it driving the name, but I do think it= =E2=80=99s important that people be familiar with this terminology as its l= ikely to come up again as the work progresses.=C2=A0

=C2=A0=E2=80=94 Justin

On J= un 4, 2020, at 7:25 PM, Mike Jones <Michael.Jones=3D40microsoft= .com@dmarc.ietf.org> wrote:

Prefer:
=C2=A0=C2=A0=C2=A0 * GNAP= =C2=A0=C2=A0=C2=A0 Grant Negotiation and Authorization Protocol =E2=80=93 T= he focus on grants is correct.=C2=A0 And it=E2=80=99s a snappy name.=
=C2=A0=C2=A0=C2=A0 * GranPro=C2=A0=C2=A0=C2=A0 GRAnt= Negotiation Protocol =E2=80=93 The focus on grants is correct.=C2=A0 Prono= unceable.
=C2=A0=C2=A0=C2=A0 * NIRAD=C2=A0=C2= =A0=C2=A0 Negotiation of Intent Registration and Authority Delegation =E2= =80=93 Cool sci-fi sounding name.
=C2=A0=C2=A0= =C2=A0 * PAuthZ=C2=A0=C2=A0=C2=A0 Protocol for Authorization =E2=80=93 Accu= rate description.
=C2=A0=C2=A0=C2=A0 * RefAuth= Z=C2=A0=C2=A0=C2=A0 Refactored Authorization Protocol =E2=80=93 Accurate de= scription.
=C2=A0=C2=A0=C2=A0 * ReAuthZ=C2=A0= =C2=A0=C2=A0 Reimagined Authorization Protocol =E2=80=93 Accurate descripti= on.
=C2=A0=C2=A0=C2=A0 * WRAC (Web Resource Au= thorization Collaboration) - Pronounced like RACK =E2=80=93 Cool name, with= history going back to OAuth WRAP.
=C2=A0=C2= =A0=C2=A0 * XAuthZ=C2=A0=C2=A0=C2=A0 eXtensible authoriZation protocol =E2= =80=93 Accurate description.
=C2=A0<= u>
Wouldn't object to:
=C2=A0=C2=A0=C2=A0 * AAuthZ=C2=A0=C2=A0=C2=A0 Alternative Author= ization Protocol (AAuthZ)
=C2=A0=C2=A0=C2=A0 *= AZARP=C2=A0=C2=A0=C2=A0 AuthoriZed Access to Resources Protocol<= /u>
=C2=A0=C2=A0=C2=A0 * AZARAP=C2=A0=C2=A0=C2=A0 AuthoriZat= ion And Resource Access Protocol
=C2=A0=C2=A0= =C2=A0 * BeBAuthZ=C2=A0=C2=A0=C2=A0 Back-end Based Authorization Protocol
=C2=A0=C2=A0=C2=A0 * DAZARAP=C2=A0=C2=A0=C2=A0 = Delegated AuthoriZation And Resource Access Protocol
=C2=A0=C2=A0=C2=A0 * TINOA=C2=A0=C2=A0 This Is Not OAuth
=C2=A0
Object to:<= u>
=C2=A0=C2=A0=C2=A0 * BYOAuthZ=C2=A0=C2=A0=C2=A0 B= uild-Your-Own Authorization Protocol =E2=80=93 Too cheesy.
=C2=A0=C2=A0=C2=A0 * CPAAP=C2=A0=C2=A0=C2=A0 Comprehensive Pri= vileged Authentication Authorization Protocol =E2=80=93 Too much like a med= ical device name.
=C2=A0=C2=A0=C2=A0 * DIYAuth= Z=C2=A0=C2=A0=C2=A0 Do-It-Yourself Authorization Protocol =E2=80=93 Too cut= e.
=C2=A0=C2=A0=C2=A0 * IDPAuthZ=C2=A0=C2=A0= =C2=A0 Intent Driven Protocol for Authorization =E2=80=93 IDP already means= something else.
=C2=A0=C2=A0=C2=A0 * TIAAP=C2= =A0=C2=A0=C2=A0 Tokenized Identity and Access Protocol =E2=80=93 I don=E2= =80=99t know what =E2=80=9Ctokenized=E2=80=9D is referring to here.<= u>
=C2=A0=C2=A0=C2=A0 * TIDEAuth =C2=A0=C2=A0=C2=A0Trust= via Intent Driven Extension Auth =E2=80=93 I don=E2=80=99t know what =E2= =80=9Cintent=E2=80=9D is referring to here.
= =C2=A0=C2=A0=C2=A0 * TIDYAuth=C2=A0=C2=A0=C2=A0 Trust via Intent Driven Yie= ld Auth =E2=80=93 I don=E2=80=99t know what =E2=80=9Cintent=E2=80=9D is ref= erring to here.
=C2=A0=C2=A0=C2=A0 * TIEAuth= =C2=A0=C2=A0=C2=A0 Trust via Intent Extension Auth =E2=80=93 I don=E2=80=99= t know what =E2=80=9Cintent=E2=80=9D is referring to here.
=C2=A0=C2=A0=C2=A0 * TXAuth=C2=A0=C2=A0=C2=A0 Testable eXtensi= ble Authorization =E2=80=93 I don=E2=80=99t know what =E2=80=9Ctestable=E2= =80=9D is referring to here.
=C2=A0=C2=A0=C2= =A0 * TxAuth=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Transmission of Authority =E2=80= =93 It=E2=80=99s delegation of authority =E2=80=93 not transfer of authorit= y.
=C2=A0=C2=A0=C2=A0 * TXAuth=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Truly eXtensible Authorization =E2=80=93 Too cute.
=C2=A0
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -- Mike
=C2=A0
--=C2=A0
Txaut= h mailing list
Txauth@ietf.org
https://www.ietf.org/mailma= n/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
3D""= =E1=90=A7
--000000000000c17d9e05a7598d5b-- From nobody Fri Jun 5 12:48:44 2020 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 C7E9A3A07E0 for ; Fri, 5 Jun 2020 12:48:42 -0700 (PDT) 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 vTZGM3PiyFsn for ; Fri, 5 Jun 2020 12:48:40 -0700 (PDT) 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 316E53A07DD for ; Fri, 5 Jun 2020 12:48:40 -0700 (PDT) Received: from [192.168.1.14] (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 055JmSo5027008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 5 Jun 2020 15:48:28 -0400 From: Justin Richer Message-Id: <458AE9D0-2844-4F0A-986D-5A3DB82DCFB8@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_02CFB774-2F1C-44D0-A946-EF328479AA32" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 5 Jun 2020 15:48:28 -0400 In-Reply-To: Cc: Mike Jones , Yaron Sheffer , "txauth@ietf.org" To: Dick Hardt References: <9FD428B4-F3C1-426B-9677-611F5FEC85C8@gmail.com> <1E2C45F5-3879-47ED-BDAD-5C3271D70D78@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Call for WG name preferences 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, 05 Jun 2020 19:48:43 -0000 --Apple-Mail=_02CFB774-2F1C-44D0-A946-EF328479AA32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 PAR aligns itself with OAuth 2 terminology, as it should given it=E2=80=99= s an OAuth 2 extension. And I=E2=80=99ll point out that it isn=E2=80=99t = a =E2=80=9Crequest=E2=80=9D but an =E2=80=9Cauthorization request=E2=80=9D= which is a specific item. The =E2=80=9Crequest=E2=80=9D variable name = is actually from OIDC, where it is used as a means to protect = information while it is in the front channel and not in an intent = lodging pattern. For people who want just the intent lodging pattern in an OAuth 2 = compatible way, PAR is absolutely the way to go and I encourage people = to do just that. If you do that, you can re-use client IDs and scopes = and client secrets and everything else directly. So if, for example, = you=E2=80=99re doing OIDC today and you want to get the benefits of the = intent lodging pattern while changing the minimum amount of code, then = you should be using PAR. It even allows you to package the entire = incoming request to the PAR endpoint as a JWT, since it can use OIDC=E2=80= =99s request objects as part of the incoming request.=20 But it=E2=80=99s not ideal, because it=E2=80=99s grafted on to a system = that wasn=E2=80=99t meant to have it. Having implemented it on several = platforms now I can say that it=E2=80=99s a little odd to get right, as = is the case with most OAuth 2 extensions that have to deal with its = quirks and baggage. I bring this up because our proposed charter and = working group goal aren't just to implement PAR with slightly prettier = syntax; instead, we=E2=80=99ve got an opportunity to do a whole lot more = than that and to really question the model and capabilities that a = delegation protocol can bring. That=E2=80=99s why we aren=E2=80=99t just = an offshoot of the OAuth WG in the first place. And because of that, = this working group is going to need to be able to direct implementors = and conversations in the appropriate direction (which is also part of = our charter), and things like PAR key to that conversation in helping = people find the right solution that fits their needs. Not everyone=E2=80=99= s going to want or need what we=E2=80=99re building here, and we need to = be OK with that. In my time working with XYZ over the last year and a half or so, I=E2=80=99= ve had a number of people approach me to see if it=E2=80=99s a good fit = for what they=E2=80=99re doing. In some cases, it really is, for a lot = of the reasons that we outline as needs to address within the charter. = In a bunch of cases, though, I=E2=80=99ve pointed people at PAR, RAR, = DPoP, and related work because it makes more sense for many people to be = more tightly aligned with the existing OAuth 2 ecosystem. But if you = aren=E2=80=99t already tied to OAuth 2 or OIDC, it might not be worth = the trouble. As a consultant I=E2=80=99m used to doing that kind of = redirecting, but the unique niche this working group will occupy = alongside OAuth means we=E2=80=99re going to need to do it as a = community as well. Otherwise, we run the risk of new work being = unnecessarily fettered to old ways, or of people not availing themselves = of legacy solutions that would work better for them just because they = think this work is the new shiny that they=E2=80=99re supposed to use = instead. This is why the proposed charter says we aren=E2=80=99t = building things that are necessarily compatible with OAuth 2 =E2=80=94 = they can and should be influenced by the ecosystem of OAuth 2, but = it=E2=80=99s also our job to help the new protocol evolve beyond that. =E2=80=94 Justin > On Jun 5, 2020, at 1:25 PM, Dick Hardt wrote: >=20 > Thanks for posting Justin, speaking for myself, I appreciate the = background as I had not seen the term "intent" be used.=20 >=20 > Can you share any history why "lodging intent" was the term selected = vs other choices? Why not "request"? Overused? >=20 > To me, an intent is an action ie. the client saying "I am going to do = X", whereas a request is asking for something, the client saying "I = would like X" >=20 > Or is the idea the client saying "I intend to request X"? >=20 > FWIW: I don't see the term "intent" used in PAR. It is a "request". >=20 > On Fri, Jun 5, 2020 at 7:59 AM Justin Richer > wrote: > Since there seems to be some confusion by a few people about the term = =E2=80=9CIntent=E2=80=9D and its inclusion here, I wanted to clarify = that for people. There is a protocol feature is variously known as = =E2=80=9Cintent registration=E2=80=9D or =E2=80=9Clodging intent=E2=80=9D,= where the party starting the process (the client) makes a statement = about what it wants to do and is then given the tools to complete the = next steps to do that. It=E2=80=99s a key feature of the pattern we=E2=80=99= re looking to codify in this group=E2=80=99s work. >=20 > The FAPI working group in the OIDF has done a lot of work around it, = and you see this style in a bunch of different financial APIs dating = back decades: >=20 > = https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Intent.= md = >=20 > = https://bitbucket.org/openid/fapi/issues/142/standardising-lodging-intent = >=20 >=20 > Torsten Lodderstedt has a great blog post that touches on it as well: >=20 > = https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-= think-oauth-scopes-2326e2038948 = >=20 > And it=E2=80=99s the basis behind OAuth 2.0=E2=80=99s Pushed = Authorization Request (PAR) extension that=E2=80=99s happening now: >=20 > https://tools.ietf.org/html/draft-ietf-oauth-par = >=20 > = https://medium.com/oauth-2/pushed-authorization-requests-draft-adopted-by-= oauth-working-group-a1060007150f = >=20 >=20 > To be clear, I=E2=80=99m not saying this is sufficient for it driving = the name, but I do think it=E2=80=99s important that people be familiar = with this terminology as its likely to come up again as the work = progresses.=20 >=20 > =E2=80=94 Justin >=20 >> On Jun 4, 2020, at 7:25 PM, Mike Jones = > wrote: >>=20 >> Prefer: >> * GNAP Grant Negotiation and Authorization Protocol =E2=80=93 = The focus on grants is correct. And it=E2=80=99s a snappy name. >> * GranPro GRAnt Negotiation Protocol =E2=80=93 The focus on = grants is correct. Pronounceable. >> * NIRAD Negotiation of Intent Registration and Authority = Delegation =E2=80=93 Cool sci-fi sounding name. >> * PAuthZ Protocol for Authorization =E2=80=93 Accurate = description. >> * RefAuthZ Refactored Authorization Protocol =E2=80=93 = Accurate description. >> * ReAuthZ Reimagined Authorization Protocol =E2=80=93 Accurate = description. >> * WRAC (Web Resource Authorization Collaboration) - Pronounced = like RACK =E2=80=93 Cool name, with history going back to OAuth WRAP. >> * XAuthZ eXtensible authoriZation protocol =E2=80=93 Accurate = description. >> =20 >> Wouldn't object to: >> * AAuthZ Alternative Authorization Protocol (AAuthZ) >> * AZARP AuthoriZed Access to Resources Protocol >> * AZARAP AuthoriZation And Resource Access Protocol >> * BeBAuthZ Back-end Based Authorization Protocol >> * DAZARAP Delegated AuthoriZation And Resource Access Protocol >> * TINOA This Is Not OAuth >> =20 >> Object to: >> * BYOAuthZ Build-Your-Own Authorization Protocol =E2=80=93 Too = cheesy. >> * CPAAP Comprehensive Privileged Authentication Authorization = Protocol =E2=80=93 Too much like a medical device name. >> * DIYAuthZ Do-It-Yourself Authorization Protocol =E2=80=93 Too = cute. >> * IDPAuthZ Intent Driven Protocol for Authorization =E2=80=93 = IDP already means something else. >> * TIAAP Tokenized Identity and Access Protocol =E2=80=93 I = don=E2=80=99t know what =E2=80=9Ctokenized=E2=80=9D is referring to = here. >> * TIDEAuth Trust via Intent Driven Extension Auth =E2=80=93 I = don=E2=80=99t know what =E2=80=9Cintent=E2=80=9D is referring to here. >> * TIDYAuth Trust via Intent Driven Yield Auth =E2=80=93 I = don=E2=80=99t know what =E2=80=9Cintent=E2=80=9D is referring to here. >> * TIEAuth Trust via Intent Extension Auth =E2=80=93 I don=E2=80=99= t know what =E2=80=9Cintent=E2=80=9D is referring to here. >> * TXAuth Testable eXtensible Authorization =E2=80=93 I don=E2=80= =99t know what =E2=80=9Ctestable=E2=80=9D is referring to here. >> * TxAuth Transmission of Authority =E2=80=93 It=E2=80=99s = delegation of authority =E2=80=93 not transfer of authority. >> * TXAuth Truly eXtensible Authorization =E2=80=93 Too cute. >> =20 >> -- Mike >> =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 = > =E1=90=A7 --Apple-Mail=_02CFB774-2F1C-44D0-A946-EF328479AA32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 PAR = aligns itself with OAuth 2 terminology, as it should given it=E2=80=99s = an OAuth 2 extension. And I=E2=80=99ll point out that it isn=E2=80=99t a = =E2=80=9Crequest=E2=80=9D but an =E2=80=9Cauthorization request=E2=80=9D = which is a specific item. The =E2=80=9Crequest=E2=80=9D variable name is = actually from OIDC, where it is used as a means to protect information = while it is in the front channel and not in an intent lodging = pattern.

For people = who want just the intent lodging pattern in an OAuth 2 compatible way, = PAR is absolutely the way to go and I encourage people to do just that. = If you do that, you can re-use client IDs and scopes and client secrets = and everything else directly. So if, for example, you=E2=80=99re doing = OIDC today and you want to get the benefits of the intent lodging = pattern while changing the minimum amount of code, then you should be = using PAR. It even allows you to package the entire incoming request to = the PAR endpoint as a JWT, since it can use OIDC=E2=80=99s request = objects as part of the incoming request. 

But it=E2=80=99s not ideal, because = it=E2=80=99s grafted on to a system that wasn=E2=80=99t meant to have = it. Having implemented it on several platforms now I can say that it=E2=80= =99s a little odd to get right, as is the case with most OAuth 2 = extensions that have to deal with its quirks and baggage. I bring this = up because our proposed charter and working group goal aren't just to = implement PAR with slightly prettier syntax; instead, we=E2=80=99ve got = an opportunity to do a whole lot more than that and to really question = the model and capabilities that a delegation protocol can bring. = That=E2=80=99s why we aren=E2=80=99t just an offshoot of the OAuth WG in = the first place. And because of that, this working group is going to = need to be able to direct implementors and conversations in the = appropriate direction (which is also part of our charter), and things = like PAR key to that conversation in helping people find the right = solution that fits their needs. Not everyone=E2=80=99s going to want or = need what we=E2=80=99re building here, and we need to be OK with = that.

In my = time working with XYZ over the last year and a half or so, I=E2=80=99ve = had a number of people approach me to see if it=E2=80=99s a good fit for = what they=E2=80=99re doing. In some cases, it really is, for a lot of = the reasons that we outline as needs to address within the charter. In a = bunch of cases, though, I=E2=80=99ve pointed people at PAR, RAR, DPoP, = and related work because it makes more sense for many people to be more = tightly aligned with the existing OAuth 2 ecosystem. But if you aren=E2=80= =99t already tied to OAuth 2 or OIDC, it might not be worth the trouble. = As a consultant I=E2=80=99m used to doing that kind of redirecting, but = the unique niche this working group will occupy alongside OAuth means = we=E2=80=99re going to need to do it as a community as well. Otherwise, = we run the risk of new work being unnecessarily fettered to old ways, or = of people not availing themselves of legacy solutions that would work = better for them just because they think this work is the new shiny that = they=E2=80=99re supposed to use instead. This is why the proposed = charter says we aren=E2=80=99t building things that are necessarily = compatible with OAuth 2 =E2=80=94 they can and should be influenced by = the ecosystem of OAuth 2, but it=E2=80=99s also our job to help the new = protocol evolve beyond that.

 =E2=80=94 Justin

On Jun 5, 2020, at 1:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Thanks = for posting Justin, speaking for myself, I = appreciate the background as I had not seen the term "intent" = be used. 

Can you share any history why "lodging intent" = was the term selected vs other choices? Why not "request"? Overused?

To me, an intent is an action ie. the client saying "I am = going to do X", whereas a request is asking for something, the = client saying "I would like X"

Or is the idea the client saying = "I intend to request X"?

FWIW: I = don't see the term "intent" used in PAR. It is a = "request".

On Fri, Jun 5, 2020 at 7:59 AM Justin = Richer <jricher@mit.edu> wrote:
Since there seems to be some confusion by a few = people about the term =E2=80=9CIntent=E2=80=9D and its inclusion here, I = wanted to clarify that for people. There is a protocol feature is = variously known as =E2=80=9Cintent registration=E2=80=9D or =E2=80=9Clodgi= ng intent=E2=80=9D, where the party starting the process (the client) = makes a statement about what it wants to do and is then given the tools = to complete the next steps to do that. It=E2=80=99s a key feature = of the pattern we=E2=80=99re looking to codify in this group=E2=80=99s = work.

The FAPI = working group in the OIDF has done a lot of work around it, and you see = this style in a bunch of different financial APIs dating back = decades:

https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodg= ing_Intent.md

https://bitbucket.org/openid/fapi/issues/142/standardising-lodg= ing-intent


Torsten Lodderstedt has = a great blog post that touches on it as well:

https://medium.com/oauth-2/transaction-authorization-or-why-we-= need-to-re-think-oauth-scopes-2326e2038948

And it=E2=80=99s the basis behind OAuth = 2.0=E2=80=99s Pushed Authorization Request (PAR) extension that=E2=80=99s = happening now:

https://tools.ietf.org/html/draft-ietf-oauth-par

https://medium.com/oauth-2/pushed-authorization-requests-draft-= adopted-by-oauth-working-group-a1060007150f


To be clear, I=E2=80=99m not saying this is sufficient for it = driving the name, but I do think it=E2=80=99s important that people be = familiar with this terminology as its likely to come up again as the = work progresses. 

 =E2=80=94 Justin

On Jun = 4, 2020, at 7:25 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

Prefer:
    * GNAP    Grant Negotiation = and Authorization Protocol =E2=80=93 The focus on grants is = correct.  And it=E2=80=99s a snappy name.
    * GranPro    GRAnt = Negotiation Protocol =E2=80=93 The focus on grants is correct.  = Pronounceable.
    * NIRAD    Negotiation of = Intent Registration and Authority Delegation =E2=80=93 Cool sci-fi = sounding name.
    * PAuthZ    Protocol for = Authorization =E2=80=93 Accurate description.
    * RefAuthZ    Refactored = Authorization Protocol =E2=80=93 Accurate description.
    * ReAuthZ    Reimagined = Authorization Protocol =E2=80=93 Accurate description.
    * WRAC (Web Resource Authorization = Collaboration) - Pronounced like RACK =E2=80=93 Cool name, with history = going back to OAuth WRAP.
    * XAuthZ    eXtensible = authoriZation protocol =E2=80=93 Accurate description.
 
Wouldn't object to:
    * AAuthZ    Alternative = Authorization Protocol (AAuthZ)
    * AZARP    AuthoriZed = Access to Resources Protocol
    * AZARAP    AuthoriZation = And Resource Access Protocol
    * BeBAuthZ    Back-end = Based Authorization Protocol
    * DAZARAP    Delegated = AuthoriZation And Resource Access Protocol
    * TINOA   This Is Not OAuth
 
Object to:
    * BYOAuthZ    = Build-Your-Own Authorization Protocol =E2=80=93 Too cheesy.
    * CPAAP    Comprehensive = Privileged Authentication Authorization Protocol =E2=80=93 Too much like = a medical device name.
    * DIYAuthZ    = Do-It-Yourself Authorization Protocol =E2=80=93 Too cute.
    * IDPAuthZ    Intent Driven = Protocol for Authorization =E2=80=93 IDP already means something else.
    * TIAAP    Tokenized = Identity and Access Protocol =E2=80=93 I don=E2=80=99t know what = =E2=80=9Ctokenized=E2=80=9D is referring to here.
    * TIDEAuth    Trust via = Intent Driven Extension Auth =E2=80=93 I don=E2=80=99t know what = =E2=80=9Cintent=E2=80=9D is referring to here.
    * TIDYAuth    Trust via = Intent Driven Yield Auth =E2=80=93 I don=E2=80=99t know what = =E2=80=9Cintent=E2=80=9D is referring to here.
    * TIEAuth    Trust via = Intent Extension Auth =E2=80=93 I don=E2=80=99t know what =E2=80=9Cintent=E2= =80=9D is referring to here.
    * TXAuth    Testable = eXtensible Authorization =E2=80=93 I don=E2=80=99t know what = =E2=80=9Ctestable=E2=80=9D is referring to here.
    * TxAuth      = Transmission of Authority =E2=80=93 It=E2=80=99s delegation of authority = =E2=80=93 not transfer of authority.
    * TXAuth      = Truly eXtensible Authorization =E2=80=93 Too cute.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
-- 
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
=
3D""=E1=90=A7

= --Apple-Mail=_02CFB774-2F1C-44D0-A946-EF328479AA32-- From nobody Fri Jun 5 12:56:56 2020 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 48D153A0827 for ; Fri, 5 Jun 2020 12:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_PDS_OTHER_BAD_TLD=0.01, 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 kYQo8s5MhqEG for ; Fri, 5 Jun 2020 12:56:52 -0700 (PDT) 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 2D4D93A0A6C for ; Fri, 5 Jun 2020 12:56:40 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id n24so13174089lji.10 for ; Fri, 05 Jun 2020 12:56:40 -0700 (PDT) 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=StmXLeX8L+JC91PXHW9PDbdZfLadbfM7kp/lrCHB7aE=; b=iIeVGvAuCmWnVAyAK9S60xaG5HQfS9Ir7Vum6TfdNSmr7E8j3ZWxq5JrqI4uOELFbT Fat2TALehEy/SpB6a56iTX2QhyxT4izrOVjS7I3HTIfEF0M8lYeO6vtVGwNGzBUpm9MP 55AnhN9MFlZVmzqj1OWBaIx2yaMQIvXWCIiQDYEi/2OrrEQZZbz1WA5TvyvL+Qs4ss8R WZS2uPQ9eCW+6wQfiecY83mZC7L3wmYAZDu1WBB3nEAsPuTQpOW9C3sonoVY/lhoZgtH OogcSl67oPb/p40vGeoPiBnRLlbyQNPV8fps/fzS5LVarUCnF6b72Pc3HsRo26jxDHLu TJuw== 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=StmXLeX8L+JC91PXHW9PDbdZfLadbfM7kp/lrCHB7aE=; b=dwXc93OWlvPBbljzquw1TnF3HU175a1Ht/gGU5+qm0xGmTRL7VfkCu4V7BxJ4ow2x2 unrqqqPsVgvvE8hZrwF2cNBAzSMd6k55Sbo/aq8ilENJIVg6KWiQnFLYjRo7C66Jhdl2 YHbprcd0LLswhugHoShgt0wnX+C5ocO5M+zHsJucQMV8spmR0HOEX0pCGwxJBNac53Ci BgaElk8V8IeIaFTTgqf6c+UPgOd44MEXSKg0wnYyYR2BqWUabZSqtedSVrdvXPdJqeqS qJaqIYo3xR8UymwCGRqVYxHvTHhTzUOhrXZ3G68NAdVBRoAwmztJFt0J2qvYa/DNzHPV EUDA== X-Gm-Message-State: AOAM5329XMtAfgeG3iS3rgdU67pCtISNZod+aARcH+/SD+IAcs4JB/Wc 353pDiTlzObGfOGo/CTH5xdb54iyh39KTkREBQc= X-Google-Smtp-Source: ABdhPJxdWQOe2KuAwRItu4foKLHSogCMqZV1Qhs0aDJ1rsqVdEFulp6MBc+w/MOT/rDJgkTtzfn7TbvU8DMg8SlrVKw= X-Received: by 2002:a2e:140a:: with SMTP id u10mr5563053ljd.56.1591386994383; Fri, 05 Jun 2020 12:56:34 -0700 (PDT) MIME-Version: 1.0 References: <9FD428B4-F3C1-426B-9677-611F5FEC85C8@gmail.com> <1E2C45F5-3879-47ED-BDAD-5C3271D70D78@mit.edu> <458AE9D0-2844-4F0A-986D-5A3DB82DCFB8@mit.edu> In-Reply-To: <458AE9D0-2844-4F0A-986D-5A3DB82DCFB8@mit.edu> From: Dick Hardt Date: Fri, 5 Jun 2020 12:56:07 -0700 Message-ID: To: Justin Richer Cc: Mike Jones , Yaron Sheffer , "txauth@ietf.org" Content-Type: multipart/related; boundary="00000000000080768705a75ba82f" Archived-At: Subject: Re: [Txauth] Call for WG name preferences 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, 05 Jun 2020 19:56:54 -0000 --00000000000080768705a75ba82f Content-Type: multipart/alternative; boundary="00000000000080768505a75ba82e" --00000000000080768505a75ba82e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the response Justin, but you did not answer my questions. My question was why was "intent lodging" selected. I am also not sure what "the intent lodging pattern" is. Additionally, you say, "we=E2=80=99ve got an opportunity to do a whole lot = more than that and to really question the model and capabilities that a delegation protocol can bring." This sounds nice, but is not specific. Would you share more on what you think we should question, and what the opportunities are? Assume most of us have not read oauth.xyz or seen your talks on the topic. [image: image.gif] On Fri, Jun 5, 2020 at 12:48 PM Justin Richer wrote: > PAR aligns itself with OAuth 2 terminology, as it should given it=E2=80= =99s an > OAuth 2 extension. And I=E2=80=99ll point out that it isn=E2=80=99t a =E2= =80=9Crequest=E2=80=9D but an > =E2=80=9Cauthorization request=E2=80=9D which is a specific item. The =E2= =80=9Crequest=E2=80=9D variable > name is actually from OIDC, where it is used as a means to protect > information while it is in the front channel and not in an intent lodging > pattern. > > For people who want just the intent lodging pattern in an OAuth 2 > compatible way, PAR is absolutely the way to go and I encourage people to > do just that. If you do that, you can re-use client IDs and scopes and > client secrets and everything else directly. So if, for example, you=E2= =80=99re > doing OIDC today and you want to get the benefits of the intent lodging > pattern while changing the minimum amount of code, then you should be usi= ng > PAR. It even allows you to package the entire incoming request to the PAR > endpoint as a JWT, since it can use OIDC=E2=80=99s request objects as par= t of the > incoming request. > > But it=E2=80=99s not ideal, because it=E2=80=99s grafted on to a system t= hat wasn=E2=80=99t meant > to have it. Having implemented it on several platforms now I can say that > it=E2=80=99s a little odd to get right, as is the case with most OAuth 2 = extensions > that have to deal with its quirks and baggage. I bring this up because ou= r > proposed charter and working group goal aren't just to implement PAR with > slightly prettier syntax; instead, we=E2=80=99ve got an opportunity to do= a whole > lot more than that and to really question the model and capabilities that= a > delegation protocol can bring. That=E2=80=99s why we aren=E2=80=99t just = an offshoot of the > OAuth WG in the first place. And because of that, this working group is > going to need to be able to direct implementors and conversations in the > appropriate direction (which is also part of our charter), and things lik= e > PAR key to that conversation in helping people find the right solution th= at > fits their needs. Not everyone=E2=80=99s going to want or need what we=E2= =80=99re building > here, and we need to be OK with that. > > In my time working with XYZ over the last year and a half or so, I=E2=80= =99ve had > a number of people approach me to see if it=E2=80=99s a good fit for what= they=E2=80=99re > doing. In some cases, it really is, for a lot of the reasons that we > outline as needs to address within the charter. In a bunch of cases, > though, I=E2=80=99ve pointed people at PAR, RAR, DPoP, and related work b= ecause it > makes more sense for many people to be more tightly aligned with the > existing OAuth 2 ecosystem. But if you aren=E2=80=99t already tied to OAu= th 2 or > OIDC, it might not be worth the trouble. As a consultant I=E2=80=99m used= to doing > that kind of redirecting, but the unique niche this working group will > occupy alongside OAuth means we=E2=80=99re going to need to do it as a co= mmunity as > well. Otherwise, we run the risk of new work being unnecessarily fettered > to old ways, or of people not availing themselves of legacy solutions tha= t > would work better for them just because they think this work is the new > shiny that they=E2=80=99re supposed to use instead. This is why the propo= sed > charter says we aren=E2=80=99t building things that are necessarily compa= tible with > OAuth 2 =E2=80=94 they can and should be influenced by the ecosystem of O= Auth 2, > but it=E2=80=99s also our job to help the new protocol evolve beyond that= . > > =E2=80=94 Justin > > On Jun 5, 2020, at 1:25 PM, Dick Hardt wrote: > > Thanks for posting Justin, speaking for myself, I > appreciate the background as I had not seen the term "intent" be used. > > Can you share any history why "lodging intent" was the term selected vs > other choices? Why not "request"? Overused? > > To me, an intent is an action ie. the client saying "I am going to do X", > whereas a request is asking for something, the client saying "I would lik= e > X" > > Or is the idea the client saying "I intend to request X"? > > FWIW: I don't see the term "intent" used in PAR. It is a "request". > > On Fri, Jun 5, 2020 at 7:59 AM Justin Richer wrote: > >> Since there seems to be some confusion by a few people about the term >> =E2=80=9CIntent=E2=80=9D and its inclusion here, I wanted to clarify tha= t for people. There >> is a protocol feature is variously known as =E2=80=9Cintent registration= =E2=80=9D or >> =E2=80=9Clodging intent=E2=80=9D, where the party starting the process (= the client) makes a >> statement about what it wants to do and is then given the tools to compl= ete >> the next steps to do that. It=E2=80=99s a key feature of the pattern we= =E2=80=99re looking >> to codify in this group=E2=80=99s work. >> >> The FAPI working group in the OIDF has done a lot of work around it, and >> you see this style in a bunch of different financial APIs dating back >> decades: >> >> >> https://bitbucket.org/openid/fapi/src/master/Financial_API_Lodging_Inten= t.md >> >> https://bitbucket.org/openid/fapi/issues/142/standardising-lodging-inten= t >> >> >> Torsten Lodderstedt has a great blog post that touches on it as well: >> >> >> https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-r= e-think-oauth-scopes-2326e2038948 >> >> And it=E2=80=99s the basis behind OAuth 2.0=E2=80=99s Pushed Authorizati= on Request (PAR) >> extension that=E2=80=99s happening now: >> >> https://tools.ietf.org/html/draft-ietf-oauth-par >> >> >> https://medium.com/oauth-2/pushed-authorization-requests-draft-adopted-b= y-oauth-working-group-a1060007150f >> >> >> To be clear, I=E2=80=99m not saying this is sufficient for it driving th= e name, >> but I do think it=E2=80=99s important that people be familiar with this = terminology >> as its likely to come up again as the work progresses. >> >> =E2=80=94 Justin >> >> On Jun 4, 2020, at 7:25 PM, Mike Jones < >> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >> >> *Prefer:* >> * GNAP Grant Negotiation and Authorization Protocol =E2=80=93 The= focus on >> grants is correct. And it=E2=80=99s a snappy name. >> * GranPro GRAnt Negotiation Protocol =E2=80=93 The focus on grant= s is >> correct. Pronounceable. >> * NIRAD Negotiation of Intent Registration and Authority >> Delegation =E2=80=93 Cool sci-fi sounding name. >> * PAuthZ Protocol for Authorization =E2=80=93 Accurate descriptio= n. >> * RefAuthZ Refactored Authorization Protocol =E2=80=93 Accurate >> description. >> * ReAuthZ Reimagined Authorization Protocol =E2=80=93 Accurate de= scription. >> * WRAC (Web Resource Authorization Collaboration) - Pronounced like >> RACK =E2=80=93 Cool name, with history going back to OAuth WRAP. >> * XAuthZ eXtensible authoriZation protocol =E2=80=93 Accurate des= cription. >> >> *Wouldn't object to:* >> * AAuthZ Alternative Authorization Protocol (AAuthZ) >> * AZARP AuthoriZed Access to Resources Protocol >> * AZARAP AuthoriZation And Resource Access Protocol >> * BeBAuthZ Back-end Based Authorization Protocol >> * DAZARAP Delegated AuthoriZation And Resource Access Protocol >> * TINOA This Is Not OAuth >> >> *Object to:* >> * BYOAuthZ Build-Your-Own Authorization Protocol =E2=80=93 Too ch= eesy. >> * CPAAP Comprehensive Privileged Authentication Authorization >> Protocol =E2=80=93 Too much like a medical device name. >> * DIYAuthZ Do-It-Yourself Authorization Protocol =E2=80=93 Too cu= te. >> * IDPAuthZ Intent Driven Protocol for Authorization =E2=80=93 IDP= already >> means something else. >> * TIAAP Tokenized Identity and Access Protocol =E2=80=93 I don=E2= =80=99t know what >> =E2=80=9Ctokenized=E2=80=9D is referring to here. >> * TIDEAuth Trust via Intent Driven Extension Auth =E2=80=93 I don= =E2=80=99t know >> what =E2=80=9Cintent=E2=80=9D is referring to here. >> * TIDYAuth Trust via Intent Driven Yield Auth =E2=80=93 I don=E2= =80=99t know what >> =E2=80=9Cintent=E2=80=9D is referring to here. >> * TIEAuth Trust via Intent Extension Auth =E2=80=93 I don=E2=80= =99t know what >> =E2=80=9Cintent=E2=80=9D is referring to here. >> * TXAuth Testable eXtensible Authorization =E2=80=93 I don=E2=80= =99t know what >> =E2=80=9Ctestable=E2=80=9D is referring to here. >> * TxAuth Transmission of Authority =E2=80=93 It=E2=80=99s deleg= ation of >> authority =E2=80=93 not transfer of authority. >> * TXAuth Truly eXtensible Authorization =E2=80=93 Too cute. >> >> -- Mike >> >> -- >> 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 >> > =E1=90=A7 > > > --00000000000080768505a75ba82e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the response = Justin, but you did not answer my questions. My question was why was "= intent lodging" selected.

I am also not sure wh= at "the intent lodging pattern" is.=C2=A0

Additionally, you say, "we=E2=80=99ve got an opportunity to do a who= le lot more than that and to really question the model and capabilities tha= t a delegation protocol can bring."

This soun= ds nice, but is not specific. Would you share more on what you think we sho= uld question, and what the opportunities are? Assume most of us have not re= ad oauth.xyz or seen your talks on the top= ic.
3D"image.gif"


<= div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 5, 2020 at 12:48 PM Justin= Richer <jricher@mit.edu> wrot= e:
PAR aligns itself with OAuth 2 terminology, as= it should given it=E2=80=99s an OAuth 2 extension. And I=E2=80=99ll point = out that it isn=E2=80=99t a =E2=80=9Crequest=E2=80=9D but an =E2=80=9Cautho= rization request=E2=80=9D which is a specific item. The =E2=80=9Crequest=E2= =80=9D variable name is actually from OIDC, where it is used as a means to = protect information while it is in the front channel and not in an intent l= odging pattern.

For people who want just the intent lodg= ing pattern in an OAuth 2 compatible way, PAR is absolutely the way to go a= nd I encourage people to do just that. If you do that, you can re-use clien= t IDs and scopes and client secrets and everything else directly. So if, fo= r example, you=E2=80=99re doing OIDC today and you want to get the benefits= of the intent lodging pattern while changing the minimum amount of code, t= hen you should be using PAR. It even allows you to package the entire incom= ing request to the PAR endpoint as a JWT, since it can use OIDC=E2=80=99s r= equest objects as part of the incoming request.=C2=A0

<= div>But it=E2=80=99s not ideal, because it=E2=80=99s grafted on to a system= that wasn=E2=80=99t meant to have it. Having implemented it on several pla= tforms now I can say that it=E2=80=99s a little odd to get right, as is the= case with most OAuth 2 extensions that have to deal with its quirks and ba= ggage. I bring this up because our proposed charter and working group goal = aren't just to implement PAR with slightly prettier syntax; instead, we= =E2=80=99ve got an opportunity to do a whole lot more than that and to real= ly question the model and capabilities that a delegation protocol can bring= . That=E2=80=99s why we aren=E2=80=99t just an offshoot of the OAuth WG in = the first place. And because of that, this working group is going to need t= o be able to direct implementors and conversations in the appropriate direc= tion (which is also part of our charter), and things like PAR key to that c= onversation in helping people find the right solution that fits their needs= . Not everyone=E2=80=99s going to want or need what we=E2=80=99re building = here, and we need to be OK with that.

In my time w= orking with XYZ over the last year and a half or so, I=E2=80=99ve had a num= ber of people approach me to see if it=E2=80=99s a good fit for what they= =E2=80=99re doing. In some cases, it really is, for a lot of the reasons th= at we outline as needs to address within the charter. In a bunch of cases, = though, I=E2=80=99ve pointed people at PAR, RAR, DPoP, and related work bec= ause it makes more sense for many people to be more tightly aligned with th= e existing OAuth 2 ecosystem. But if you aren=E2=80=99t already tied to OAu= th 2 or OIDC, it might not be worth the trouble. As a consultant I=E2=80=99= m used to doing that kind of redirecting, but the unique niche this working= group will occupy alongside OAuth means we=E2=80=99re going to need to do = it as a community as well. Otherwise, we run the risk of new work being unn= ecessarily fettered to old ways, or of people not availing themselves of le= gacy solutions that would work better for them just because they think this= work is the new shiny that they=E2=80=99re supposed to use instead. This i= s why the proposed charter says we aren=E2=80=99t building things that are = necessarily compatible with OAuth 2 =E2=80=94 they can and should be influe= nced by the ecosystem of OAuth 2, but it=E2=80=99s also our job to help the= new protocol evolve beyond that.

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

On Jun 5, 2020, at 1:25 P= M, Dick Hardt <dick.hardt@gmail.com> wrote:

Thanks for posting Justin, speaking for myself, I appreciate=C2= =A0the=C2=A0background as I had not seen the term "intent" be use= d.=C2=A0

Can you share any= history why "lodging intent" was the term selected vs other choi= ces? Why not "request"? Overused?

=
To me, an intent is an action ie. the client saying "I am going t= o do=C2=A0X", whereas a request is asking for something, the client sa= ying "I would like X"

Or is the idea=C2= =A0the client saying "I intend to request X"?

FWIW: I don't see the term "int= ent" used in PAR. It is a "request".

On Fri, Jun 5, 202= 0 at 7:59 AM Justin Richer <jricher@mit.edu> wrote:
Since there seems to be some confusion by a fe= w people about the term =E2=80=9CIntent=E2=80=9D and its inclusion here, I = wanted to clarify that for people. There is a protocol feature is variously= known as =E2=80=9Cintent registration=E2=80=9D or =E2=80=9Clodging intent= =E2=80=9D, where the party starting the process (the client) makes a statem= ent about what it wants to do and is then given the tools to complete the n= ext steps to do that.=C2=A0It=E2=80=99s a key feature of the pattern we=E2= =80=99re looking to codify in this group=E2=80=99s work.

The FAPI working group in the OIDF has done a lot of work around it, and y= ou see this style in a bunch of different financial APIs dating back decade= s:



Torsten Lodderstedt has a great blog post that touches on it a= s well:


<= div>And it=E2=80=99s the basis behind OAuth 2.0=E2=80=99s Pushed Authorizat= ion Request (PAR) extension that=E2=80=99s happening now:

=


To be clear, I=E2=80=99m not saying this is sufficient for it drivi= ng the name, but I do think it=E2=80=99s important that people be familiar = with this terminology as its likely to come up again as the work progresses= .=C2=A0

=C2=A0=E2=80=94 Justin

On Jun 4, 2020, at 7:25 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

<= div>
Prefer:
=C2=A0=C2=A0=C2=A0 * GNAP=C2=A0=C2=A0=C2=A0 Grant Negotiation and Autho= rization Protocol =E2=80=93 The focus on grants is correct.=C2=A0 And it=E2= =80=99s a snappy name.
=C2=A0=C2=A0=C2=A0 * Gr= anPro=C2=A0=C2=A0=C2=A0 GRAnt Negotiation Protocol =E2=80=93 The focus on g= rants is correct.=C2=A0 Pronounceable.
=C2=A0= =C2=A0=C2=A0 * NIRAD=C2=A0=C2=A0=C2=A0 Negotiation of Intent Registration a= nd Authority Delegation =E2=80=93 Cool sci-fi sounding name.<= /div>
=C2=A0=C2=A0=C2=A0 * PAuthZ=C2=A0=C2=A0=C2=A0 Protocol for A= uthorization =E2=80=93 Accurate description.
= =C2=A0=C2=A0=C2=A0 * RefAuthZ=C2=A0=C2=A0=C2=A0 Refactored Authorization Pr= otocol =E2=80=93 Accurate description.
=C2=A0= =C2=A0=C2=A0 * ReAuthZ=C2=A0=C2=A0=C2=A0 Reimagined Authorization Protocol = =E2=80=93 Accurate description.
=C2=A0=C2=A0= =C2=A0 * WRAC (Web Resource Authorization Collaboration) - Pronounced like = RACK =E2=80=93 Cool name, with history going back to OAuth WRAP.<= /u>
=C2=A0=C2=A0=C2=A0 * XAuthZ=C2=A0=C2=A0=C2=A0 eXtensible= authoriZation protocol =E2=80=93 Accurate description.
=
=C2=A0
Wouldn't object= to:
=C2=A0=C2=A0=C2=A0 * AAuthZ=C2=A0=C2= =A0=C2=A0 Alternative Authorization Protocol (AAuthZ)
=C2=A0=C2=A0=C2=A0 * AZARP=C2=A0=C2=A0=C2=A0 AuthoriZed Access to R= esources Protocol
=C2=A0=C2=A0=C2=A0 * AZARAP= =C2=A0=C2=A0=C2=A0 AuthoriZation And Resource Access Protocol=
=C2=A0=C2=A0=C2=A0 * BeBAuthZ=C2=A0=C2=A0=C2=A0 Back-end Ba= sed Authorization Protocol
=C2=A0=C2=A0=C2=A0 = * DAZARAP=C2=A0=C2=A0=C2=A0 Delegated AuthoriZation And Resource Access Pro= tocol
=C2=A0=C2=A0=C2=A0 * TINOA=C2=A0=C2=A0 T= his Is Not OAuth
=C2=A0
Object to:
=C2=A0=C2=A0=C2=A0 * = BYOAuthZ=C2=A0=C2=A0=C2=A0 Build-Your-Own Authorization Protocol =E2=80=93 = Too cheesy.
=C2=A0=C2=A0=C2=A0 * CPAAP=C2=A0= =C2=A0=C2=A0 Comprehensive Privileged Authentication Authorization Protocol= =E2=80=93 Too much like a medical device name.
=C2=A0=C2=A0= =C2=A0 * IDPAuthZ=C2=A0=C2=A0=C2=A0 Intent Driven Protocol for Authorizatio= n =E2=80=93 IDP already means something else.
= =C2=A0=C2=A0=C2=A0 * TIAAP=C2=A0=C2=A0=C2=A0 Tokenized Identity and Access = Protocol =E2=80=93 I don=E2=80=99t know what =E2=80=9Ctokenized=E2=80=9D is= referring to here.
=C2=A0=C2=A0=C2=A0 * TIDEA= uth =C2=A0=C2=A0=C2=A0Trust via Intent Driven Extension Auth =E2=80=93 I do= n=E2=80=99t know what =E2=80=9Cintent=E2=80=9D is referring to here.=
=C2=A0=C2=A0=C2=A0 * TIDYAuth=C2=A0=C2=A0=C2=A0 Trus= t via Intent Driven Yield Auth =E2=80=93 I don=E2=80=99t know what =E2=80= =9Cintent=E2=80=9D is referring to here.
=C2= =A0=C2=A0=C2=A0 * TIEAuth=C2=A0=C2=A0=C2=A0 Trust via Intent Extension Auth= =E2=80=93 I don=E2=80=99t know what =E2=80=9Cintent=E2=80=9D is referring = to here.
=C2=A0=C2=A0=C2=A0 * TXAuth=C2=A0=C2= =A0=C2=A0 Testable eXtensible Authorization =E2=80=93 I don=E2=80=99t know = what =E2=80=9Ctestable=E2=80=9D is referring to here.
=C2=A0=C2=A0=C2=A0 * TxAuth=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Transmiss= ion of Authority =E2=80=93 It=E2=80=99s delegation of authority =E2=80=93 n= ot transfer of authority.
=C2=A0=C2=A0=C2=A0 *= TXAuth=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Truly eXtensible Authorization =E2=80= =93 Too cute.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
= =C2=A0
--= =C2=A0
Txauth mailing list
Txauth@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/txauth

<= /div>
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
3D""=E1=90=A7

--00000000000080768505a75ba82e-- --00000000000080768705a75ba82f Content-Type: image/gif; name="image.gif" Content-Disposition: inline; filename="image.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_kb2mnq0g0 R0lGODlhAQABAPAAAAAAAAAAACH5BAUAAAAALAAAAAABAAEAAAICRAEAOw== --00000000000080768705a75ba82f-- From nobody Fri Jun 5 13:17:01 2020 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 1AF453A09B1 for ; Fri, 5 Jun 2020 13:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 3mIWXUcE8rig for ; Fri, 5 Jun 2020 13:16:58 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 CE7883A09AA for ; Fri, 5 Jun 2020 13:16:58 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id g5so8611319otg.6 for ; Fri, 05 Jun 2020 13:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=npmwUDi6HAZk8JKjrrMKYc2/9m/8iyFBTvV/uhr6vlA=; b=UzGDSmNIvlVdP+gMeFniSuUjNqk+PnDzs31Lv4P8ngNNmP3iAa15/vXAWMCmAbL8J6 TkZyBpPHwv88ds3eqBG7SelJPrzlItc0NcKCsfU45TXr+/Xb0mEwKaFYh/BRS8/aSdUG 4qQUUFxfED1Cq8RO6lfh3JTvEpyocYdGZZtvw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=npmwUDi6HAZk8JKjrrMKYc2/9m/8iyFBTvV/uhr6vlA=; b=h6wB3D9TTF+T31iafCci0qXHVAP/ShW6F3oulu+Adydr2ywz/4cXy+dpCkd1UKDFbu 1W4IUdMDj0KVcMecJiBukP6ZwCvUm+mGVTPiTMZOCKtGY5V5kWPSpKtXcfH9zjo/GmqK fae3HLP6GD5XurkL4HS4ihkTj6kvhftUcy6IxNiLO4PR4DFDYGhM1xQsJJ8CduZYOTa9 kp0zCbU6YPcR4Nu2qx1qfLDx/ziiS3GO0+0ai/2RXy45/QHmzRjoZafA/DPAaNtTkLX0 ijeSOZAikMUg//04AE01bX9/Q7qiNek8puAwJ6wOfSq26zYhAuAvakAgN1z6MRyat2Ny GDJA== X-Gm-Message-State: AOAM532o+C5gIPo/0MaGB1JhowUBOQFQiiO3NQCftG0XxBjVjiMl5Nsr E/JyTc/mkwfe4m7x64e3PxdERQ== X-Google-Smtp-Source: ABdhPJxZoavTKbyRtUpl4DMGnKvygxejkJdY9+Hy6zGkMtR65ZdY9wooc5OY4hbhMEP/A+/Om3GdTw== X-Received: by 2002:a9d:768a:: with SMTP id j10mr9532540otl.188.1591388213132; Fri, 05 Jun 2020 13:16:53 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id j46sm129531ota.69.2020.06.05.13.16.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Jun 2020 13:16:52 -0700 (PDT) To: txauth@ietf.org From: Peter Saint-Andre Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= mQINBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABtCdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT6JAlQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekLkCDQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAYkCPAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: Date: Fri, 5 Jun 2020 14:16:51 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Txauth] what's in a name? 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, 05 Jun 2020 20:17:00 -0000 I suggest Token-Oriented Authorization for Secure Transactions or TOAST, which is what this working group will be if it takes this much effort to come up with a WG name! Peter From nobody Fri Jun 5 13:35:22 2020 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 D3B7D3A0D16 for ; Fri, 5 Jun 2020 13:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, 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 SQQu83VEYBNQ for ; Fri, 5 Jun 2020 13:35:19 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 AF8893A0D0E for ; Fri, 5 Jun 2020 13:35:19 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id g28so11154261qkl.0 for ; Fri, 05 Jun 2020 13:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=Ubyck27jQLDAHXD3Qhpa+yR8oRVSHmTWuYOe+QeCp8c=; b=LvwpqLMsLAg5DWgTq3QXdX2jRnV7DY/LwPpCZa1wpMe6mMaUJxcNrNOyjJ6AHLWHrt a1B7EFEQcbAZbRr3mWpvWUksm2z7KTB3WXMCw/9+XvnWKHdFPH/goIp/m9eP7lcgdTXt XXEoPFxAE6pXQdlDEnwS1Iqc5gnWdvuNkrUxbVi0g20vcyi2dwd+cVg32EjWQYxnNcsO qVIiC/TAYsIC94nn2LDeuJhVEQlylfdDx49V1DBVFbjgnfebgVntDyZyBoIOAImKsueP bMvFyLnkDlznq02+G2bBDo3L3Kp0zGLkE6h443HFoha4yDIwh9JptSQEtVdBD7J4DphR 9aKg== 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:message-id :thread-topic:mime-version:content-transfer-encoding; bh=Ubyck27jQLDAHXD3Qhpa+yR8oRVSHmTWuYOe+QeCp8c=; b=ikRzNLb3ir9PI9Yn9sNw6UCWQABRX9MkFFPaXaOap/9A75hZ8c2Gy2UWm50I1Cc6is 6wIqcHLkz2JwYOl1LAvdWLZtQdN6MRUvlW5/W3gs8r6+uPMsaAZ+tHca3yKyazrNjOoB 1Kc+PO45u+JpzZ7wFtkjag5pTx0FFiLqU9kLEDxj9rAo+7Lbg3jQ+fl6GZoOu0xhwlwQ 43sFLaWOVdm08fRbYAgvR29RX2A7mAdz8rOrHKpcn/sngE8pkV3ySuGvCdv3alWNg4ip xA71m/rAmfMJs13XXIy7sHoR0Oay3ZNaASqVnexsZV8ZRgvLCKlDg1VEMQChdvddeJot DcuQ== X-Gm-Message-State: AOAM533YrRd4CbBqmXWoLgwDVhE2qbDv01JWW8FCPi7mhrAw1RxowQGm oTtAYQb35A8BnMkq1LUYAZmvbhnF X-Google-Smtp-Source: ABdhPJwvGgijLekQvTbakWz1VpD9R/sTc+ovg1iJh38LL2kd5MveiQDcz7SoNLbYirvEDAcRt74T9w== X-Received: by 2002:a37:a995:: with SMTP id s143mr11603229qke.147.1591389318588; Fri, 05 Jun 2020 13:35:18 -0700 (PDT) Received: from [172.26.49.35] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id c4sm655416qko.118.2020.06.05.13.35.17 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jun 2020 13:35:18 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.37.20051002 Date: Fri, 05 Jun 2020 23:35:17 +0300 From: Yaron Sheffer To: "txauth@ietf.org" Message-ID: <2626827D-194C-4BA7-A62C-22387942B571@gmail.com> Thread-Topic: Working group name Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: [Txauth] Working group name 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, 05 Jun 2020 20:35:21 -0000 Thank you to all who participated in the two rounds of name selection. This= process has been longer than we ever expected, and I=E2=80=99m glad we can declar= e consensus now and move forward. Based on the last two weeks=E2=80=99 worth of discussion, we have rough consensus= on a name for the proposed working group: GNAP: Grant Negotiation and Authorization Protocol This decision will now enable our AD to put our charter [1] on the IESG's t= able, where I hope we will be approved as a working group. Heads up: we intend to meet in the upcoming all-virtual IETF 108 in late Ju= ly, either as a BoF or as a newly chartered WG. Thanks, Yaron [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/ From nobody Fri Jun 5 13:59:38 2020 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 8EF823A0D8D for ; Fri, 5 Jun 2020 13:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 loy2Kbk_NZcr for ; Fri, 5 Jun 2020 13:59:36 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 2EFC03A0D51 for ; Fri, 5 Jun 2020 13:59:36 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id b18so8724590oti.1 for ; Fri, 05 Jun 2020 13:59:36 -0700 (PDT) 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=+8l+pN/ZqqbRZ0xVcRjPeYj9WUwMCTvan8ysNeBG/Cc=; b=Jt6w3rTQHGGE31aT+EIMnes78C3UAM4xuOw36/VHsgF9cXmoiviDY2/OttbfLa2P5j Nn5nNgoMPyuWir1XmM4EKA3x0wPNYKGpMZQ1MjBaSjlNlemHsA8CpT3Oc2zBnEs2dTsQ i09sdx6UjxaHB20QQa8NiWot9bey8Aj+U+bHZ3VFqX+mGuRvXsa5ZeP05MIRcr0Z4188 HPTs54tlX+3V47ycokXKxaAt7BL3yTbbro+kxfw9nkbDoSnY6UhAInYsANIh6bLAsPQP kMfVQWfmPKY36YZ6JIHW3twCTAFhl8y1sM5jgYXclRjzt/WKGRIYfFKt/8KkRnj7RfBa 4Riw== 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=+8l+pN/ZqqbRZ0xVcRjPeYj9WUwMCTvan8ysNeBG/Cc=; b=F3QnFzNd8DXb8zEdAPyCn6ejaVKN3rQ0ecftGea64ZO/Bt/vLG05GgxqtNt3wxad1w kx5/25cvmfqAnLGcurHfDSCAk/ntpT73ycFboOKmSth1jGCFeVh/3Nzzg3FVWaPl1lUw Y10InGX2BbXk8jnTS7FSfQrtto8dfZIvdIimwCshfvUOn4IsZ6ptfJS6MMDIIlQiakxx Tmd+RE+wx+Ci5OBhb7keKpxXoWHwGwQiLAug59Po8P2UJ7/nMfy74q1rOmR3E/bEKAaD FodxrTiJ3XUncp1j8P7/ttf8WgtF6FFZz0b7tMLVmF1tMZsTx7NceuVgw5Rnjw8oa0ku sXUA== X-Gm-Message-State: AOAM533trL5/USBMrHYrBCOQGf9Wt6lMZ3VOMPxsgOOMLlrijJbfjbxu VFCIOJWaRDfOQcdNEZzX1Xuv7wcwbMkrs1rDnKo= X-Google-Smtp-Source: ABdhPJwOxTrXQhac8St/i/6y4fO/1Go7ClYh9HGB5z6X5KiL3rRbFguhhC+E3/B695W11QpCngxBlkPG27S+hLtyyJk= X-Received: by 2002:a05:6830:2054:: with SMTP id f20mr8197168otp.358.1591390774049; Fri, 05 Jun 2020 13:59:34 -0700 (PDT) MIME-Version: 1.0 References: <2626827D-194C-4BA7-A62C-22387942B571@gmail.com> In-Reply-To: <2626827D-194C-4BA7-A62C-22387942B571@gmail.com> From: Tom Jones Date: Fri, 5 Jun 2020 13:59:22 -0700 Message-ID: To: Yaron Sheffer Cc: "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c9413305a75c89bf" Archived-At: Subject: Re: [Txauth] Working group name 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, 05 Jun 2020 20:59:38 -0000 --000000000000c9413305a75c89bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Before we settle on this name, I must ask if the work group is prepared for the creation of a negotiation protocol, which as I understand it will include the client asking for grants, the user responding with their intent (potentially either can start the flow) and the grant jwt (jose, whatever). Presumably to complete the lifecycle some means for the user to revoke the grants and query the grants would also be provided. That seems like more of an integrated solution than prior work efforts have involved. What is the current status of the charter? Peace ..tom On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer wrote: > Thank you to all who participated in the two rounds of name selection. > This process has been longer than we ever expected, and I=E2=80=99m glad = we can > declare consensus now and move forward. > > Based on the last two weeks=E2=80=99 worth of discussion, we have rough c= onsensus > on a name for the proposed working group: > > GNAP: Grant Negotiation and Authorization Protocol > > This decision will now enable our AD to put our charter [1] on the IESG's > table, where I hope we will be approved as a working group. > > Heads up: we intend to meet in the upcoming all-virtual IETF 108 in late > July, either as a BoF or as a newly chartered WG. > > Thanks, > Yaron > > > [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/ > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000c9413305a75c89bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Before we settle on this name, I must ask if the work grou= p is prepared for the creation of a negotiation protocol, which as I unders= tand it will include the client asking for grants, the user responding with= their intent (potentially either can start the flow) and the grant jwt (jo= se, whatever). Presumably to complete the lifecycle some means for the user= to revoke the grants and query=C2=A0the grants would also be provided.
That seems like more of an integrated solution than prior w= ork efforts have involved.
What is the current status of the char= ter?
Peace ..tom
=


On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Thank you to all = who participated in the two rounds of name selection. This process has been= longer than we ever expected, and I=E2=80=99m glad we can declare consensu= s now and move forward.

Based on the last two weeks=E2=80=99 worth of discussion, we have rough con= sensus on a name for the proposed working group:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 GNAP: Grant Negotiation and Authorization Proto= col

This decision will now enable our AD to put our charter [1] on the IESG'= ;s table, where I hope we will be approved as a working group.

Heads up: we intend to meet in the upcoming all-virtual IETF 108 in late Ju= ly, either as a BoF or as a newly chartered WG.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


[1] https://datatracker.ietf.org/doc/charter-= ietf-txauth/


--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000c9413305a75c89bf-- From nobody Fri Jun 5 15:37:07 2020 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 E119B3A0ECD for ; Fri, 5 Jun 2020 15:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 Z2VjNLFfjVv3 for ; Fri, 5 Jun 2020 15:37:05 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70CE63A0FBA for ; Fri, 5 Jun 2020 15:36:44 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id e4so13662816ljn.4 for ; Fri, 05 Jun 2020 15:36:44 -0700 (PDT) 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=ECyP0Mc6n3RkPMjpogAhinGlEHlriVccJ2hDk9Sv1rA=; b=i1jq9+66DvItAo+xw40xdeUPquXAQaLLPIL2Ryg6tHK8gltwBpO8LSopHroLZA3s18 dz/1BLcnNifMcZYN7C/oOEtjpTfWAhCdH7OeoJwtci6Sb45AhLF86sde+Nhx4WKpsP+Y hc1eCGtOgnhfpYRxzZTZlHS+DPLblOUggy38EaZ0c/Ed91B2KDDSF5xA9m+I93W6ENp0 zSmtOmkJ/hgVSo/LJCaoJG6EqcSvnYis7/M3b2bEvpdsvQU48ePVhAx7UhwuzS1NgpsK KgkxmiLzL4SlMe6h5AUZ7vuPYidti0nWrj/b0mTfo6dZGHOD6OlANt/dtwJ0n1KbR+1+ 3+LA== 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=ECyP0Mc6n3RkPMjpogAhinGlEHlriVccJ2hDk9Sv1rA=; b=W7gyA8HAMt/mr5sGVD96Iy7y/gIBOlCCM4Pg42qS4I0VNxgh/qT8lQ+L9GIv+RfSuo kVDYyA7BXM0gi7/yW+QrOzvSgIRIv45bADLFQC6XYg1VzQKqsI7v6Oh3nqI1FLf/KCAl qyYbCuCP2quuh1MCuEsMm26WG/5OI65wqszNIpkqvlLvoRLFmpyE8+mIdbyyLG0Ete4h XbnojruEjFYk1qo2q/nCdSEHI13TO5Zv0D8dAULw/J3JJin8wp+tx9jW2hvjDxbaOOkw BFVdxN4AUPlrNEC0PDD/jDaBI+YRb87NOIXTVod0JlFz3P8a6YLRaiP9KrIxTNmaa7dN tEew== X-Gm-Message-State: AOAM531qsloJWTDc8TVn5tnp95RimOJeokLriG7rNACH8IrdJknmyoAh 2gpUit8gScgcxogWiuguooH6CSzRV37xd3J8GlQ= X-Google-Smtp-Source: ABdhPJxOnTw/gZuauYOzRRH8LPAciR+Q0iyoRpGH5Akn/hn5DGmPrsk9Y6BcL2c8v99J2SWIrZ7lT9M99YWRrXMHOHM= X-Received: by 2002:a2e:9987:: with SMTP id w7mr5450862lji.215.1591396602574; Fri, 05 Jun 2020 15:36:42 -0700 (PDT) MIME-Version: 1.0 References: <2626827D-194C-4BA7-A62C-22387942B571@gmail.com> In-Reply-To: From: Dick Hardt Date: Fri, 5 Jun 2020 15:36:16 -0700 Message-ID: To: Tom Jones Cc: Yaron Sheffer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000317e5505a75de546" Archived-At: Subject: Re: [Txauth] Working group name 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, 05 Jun 2020 22:37:07 -0000 --000000000000317e5505a75de546 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom The charter is here https://datatracker.ietf.org/wg/txauth/about/ As I understand it, one of the items we are standardizing is negotiation protocol between the client and the server. How the server gathers consent from the user is currently not in scope, and it is not clear to me what could be standardized in the experience between the user and the server that would be in scope for the IETF. Similarly for consent revocation. Additionally, a user may not be involved in the negotiation process at all. =E1=90=A7 On Fri, Jun 5, 2020 at 1:59 PM Tom Jones wrote: > Before we settle on this name, I must ask if the work group is prepared > for the creation of a negotiation protocol, which as I understand it will > include the client asking for grants, the user responding with their inte= nt > (potentially either can start the flow) and the grant jwt (jose, whatever= ). > Presumably to complete the lifecycle some means for the user to revoke th= e > grants and query the grants would also be provided. > > That seems like more of an integrated solution than prior work efforts > have involved. > What is the current status of the charter? > Peace ..tom > > > On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer > wrote: > >> Thank you to all who participated in the two rounds of name selection. >> This process has been longer than we ever expected, and I=E2=80=99m glad= we can >> declare consensus now and move forward. >> >> Based on the last two weeks=E2=80=99 worth of discussion, we have rough = consensus >> on a name for the proposed working group: >> >> GNAP: Grant Negotiation and Authorization Protocol >> >> This decision will now enable our AD to put our charter [1] on the IESG'= s >> table, where I hope we will be approved as a working group. >> >> Heads up: we intend to meet in the upcoming all-virtual IETF 108 in late >> July, either as a BoF or as a newly chartered WG. >> >> Thanks, >> Yaron >> >> >> [1] https://datatracker.ietf.org/doc/charter-ietf-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 > --000000000000317e5505a75de546 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom


As I understand it, one = of the items we are standardizing is=C2=A0negotiation=C2=A0protocol between= the client and the server. How the server gathers consent from the user is= currently not in scope, and it is not clear to me what could be standardiz= ed in the experience between the user and the server that would be in scope= for the IETF. Similarly for consent revocation. Additionally, a user may n= ot be involved in the negotiation=C2=A0process at all.

=


3D""=E1=90=A7

On Fri, Jun 5,= 2020 at 1:59 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
Before we settle on this = name, I must ask if the work group is prepared for the creation of a negoti= ation protocol, which as I understand it will include the client asking for= grants, the user responding with their intent (potentially either can star= t the flow) and the grant jwt (jose, whatever). Presumably to complete the = lifecycle some means for the user to revoke the grants and query=C2=A0the g= rants would also be provided.

That seems like more of an= integrated solution than prior work efforts have involved.
What = is the current status of the charter?
Peace ..tom

=
On Fri= , Jun 5, 2020 at 1:35 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Thank you to all who partic= ipated in the two rounds of name selection. This process has been longer th= an we ever expected, and I=E2=80=99m glad we can declare consensus now and = move forward.

Based on the last two weeks=E2=80=99 worth of discussion, we have rough con= sensus on a name for the proposed working group:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 GNAP: Grant Negotiation and Authorization Proto= col

This decision will now enable our AD to put our charter [1] on the IESG'= ;s table, where I hope we will be approved as a working group.

Heads up: we intend to meet in the upcoming all-virtual IETF 108 in late Ju= ly, either as a BoF or as a newly chartered WG.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


[1] https://datatracker.ietf.org/doc/charter-= ietf-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
--000000000000317e5505a75de546-- From nobody Fri Jun 5 15:55:17 2020 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 13BBA3A0EF4 for ; Fri, 5 Jun 2020 15:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 ih1nXV_fFoN7 for ; Fri, 5 Jun 2020 15:55:14 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E523A0EE3 for ; Fri, 5 Jun 2020 15:55:14 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id p70so9578568oic.12 for ; Fri, 05 Jun 2020 15:55:14 -0700 (PDT) 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=ewCiPrHQr4DaA6pDmVXJNxtxu7C6JtSCSQ9t4fnKrY8=; b=LUSW07oRKEK+bW4wDb2DvTtt3TtmTo6ZO+Ip5XwtJpV+JUvfUBLt7w+IiwTdxDuPd2 DsoEeOwJsU14Bx0aN6As+z3itOPoMn/LYB7lnphUStjhgxlByCeF2aMEHauXZMhWHyo6 YEOfs16WWgT8L3N7vOGeypVYweE3a2uGoVx7V3NgwdZqH+Q+b5niL/BVmTHoTlMQ8ndD C0JUkvR0ONZ1KLyZMX7Wbwm/LZjdIRCANAtRLLvIKGrG2JBmUZMFLEhVd5ZC66wCnOpH h8QwAnUUPprM912DVu/ztaI+xuenIs5YC/nnZZJpiBKo9H4098SS6MB6gtbx0tZvs5dH OSkg== 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=ewCiPrHQr4DaA6pDmVXJNxtxu7C6JtSCSQ9t4fnKrY8=; b=bCb0IVB3sNMSbdWmziiEed4pnoOOq/WRlAzVeLZTU+bEymZReorWTegD1w7Mhl54oE Mx18aUuU6xla4W260bzVTpC3c2WI6bA/rY1bak6K8TcKMc07Ymd5isuBe2lSZbFUEFuo YcHpX3XAgX9OA3c2VsyZwe+8upt0x6XN39vSCZk3TyJ2fQYlYt3PVfBhioxrqQzztXIY nWF53xrsWWB7+nk6ASesS+S8w5pe6aeO3cy2Gk6NZ7IHvWQE7mta/cltfFEQV3mqIn9D r2m3f/x6C8B3xZpD2f3AEs6WjKTiEH8P+l1eT5jB3Jd+AuYNhefIm8n3sfFSAyUQl17w Fvhw== X-Gm-Message-State: AOAM530/ShYIwBHWMl+SNJ9BhwupS+m+ncpBQVNnsxzvdXO9wF/9NWzV u/vB4VMyPWXHeozexPBND+f74+PzgkFZhhE93Uw= X-Google-Smtp-Source: ABdhPJzeLioH62WX9kknPDpEEYEQrpoSlVyfNC6L88hge08hcQi1JNDLRCR+QRULcBpMub+wwTXaw/c6waJrQvdvkGA= X-Received: by 2002:aca:b309:: with SMTP id c9mr3297078oif.63.1591397713458; Fri, 05 Jun 2020 15:55:13 -0700 (PDT) MIME-Version: 1.0 References: <2626827D-194C-4BA7-A62C-22387942B571@gmail.com> In-Reply-To: From: Tom Jones Date: Fri, 5 Jun 2020 15:55:02 -0700 Message-ID: To: Dick Hardt Cc: Yaron Sheffer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006837b405a75e279a" Archived-At: Subject: Re: [Txauth] Working group name 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, 05 Jun 2020 22:55:16 -0000 --0000000000006837b405a75e279a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable if it is to be a negotiation - irrespective of the user's direct involvement, then then I see this sort of flow 1 cl to as - give me a, b c 2 as to cl - here is a grant to a 3 cl to as - no, i really need b or i can't let you in 4 as to cl - here is a grant to a, b of course an alternate is that might be 1 cl to as i want a, b, c and b is essential (I know justin hates that - but california law requires it) That is what i think negotiation is, or is some other kind of negotiation imagined Peace ..tom On Fri, Jun 5, 2020 at 3:36 PM Dick Hardt wrote: > Hi Tom > > The charter is here https://datatracker.ietf.org/wg/txauth/about/ > > As I understand it, one of the items we are standardizing > is negotiation protocol between the client and the server. How the server > gathers consent from the user is currently not in scope, and it is not > clear to me what could be standardized in the experience between the user > and the server that would be in scope for the IETF. Similarly for consent > revocation. Additionally, a user may not be involved in the > negotiation process at all. > > > > =E1=90=A7 > > On Fri, Jun 5, 2020 at 1:59 PM Tom Jones > wrote: > >> Before we settle on this name, I must ask if the work group is prepared >> for the creation of a negotiation protocol, which as I understand it wil= l >> include the client asking for grants, the user responding with their int= ent >> (potentially either can start the flow) and the grant jwt (jose, whateve= r). >> Presumably to complete the lifecycle some means for the user to revoke t= he >> grants and query the grants would also be provided. >> >> That seems like more of an integrated solution than prior work efforts >> have involved. >> What is the current status of the charter? >> Peace ..tom >> >> >> On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer >> wrote: >> >>> Thank you to all who participated in the two rounds of name selection. >>> This process has been longer than we ever expected, and I=E2=80=99m gla= d we can >>> declare consensus now and move forward. >>> >>> Based on the last two weeks=E2=80=99 worth of discussion, we have rough >>> consensus on a name for the proposed working group: >>> >>> GNAP: Grant Negotiation and Authorization Protocol >>> >>> This decision will now enable our AD to put our charter [1] on the >>> IESG's table, where I hope we will be approved as a working group. >>> >>> Heads up: we intend to meet in the upcoming all-virtual IETF 108 in lat= e >>> July, either as a BoF or as a newly chartered WG. >>> >>> Thanks, >>> Yaron >>> >>> >>> [1] https://datatracker.ietf.org/doc/charter-ietf-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 >> > --0000000000006837b405a75e279a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
if it is to be a negotiation - irrespective of the user= 9;s direct involvement, then then I see this sort of flow
1 cl to as - = give me a, b c
2 as to cl - here is a grant to a
3 cl t= o as - no, i really need b or i can't let you in
4 as to cl -= here is a grant to a, b
of course an alternate is that might be<= /div>
1 cl to as i want a, b, c and b is essential (I know justin hates= that - but california law requires it)

That is wh= at=C2=A0i think negotiation is, or is some other kind of negotiation imagin= ed

Peace ..tom


On Fri, Jun 5, 2020 at 3:36 PM Dick Hardt &l= t;dick.hardt@gmail.com> wrot= e:
Hi Tom


As I understand it,= one of the items we are standardizing is=C2=A0negotiation=C2=A0protocol be= tween the client and the server. How the server gathers consent from the us= er is currently not in scope, and it is not clear to me what could be stand= ardized in the experience between the user and the server that would be in = scope for the IETF. Similarly for consent revocation. Additionally, a user = may not be involved in the negotiation=C2=A0process at all.

<= /div>


3D""=E1=90=A7
On = Fri, Jun 5, 2020 at 1:59 PM Tom Jones <thomasclinganjones@gmail.com> wrote= :
Before we settle on this name, I must ask if the work group is prepared = for the creation of a negotiation protocol, which as I understand it will i= nclude the client asking for grants, the user responding with their intent = (potentially either can start the flow) and the grant jwt (jose, whatever).= Presumably to complete the lifecycle some means for the user to revoke the= grants and query=C2=A0the grants would also be provided.

That seems like more of an integrated solution than prior work efforts ha= ve involved.
What is the current status of the charter?
Peace ..tom


On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer <yaronf.ietf@gmail.c= om> wrote:
https://datatracker.ietf.org/doc/charter-= ietf-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
--0000000000006837b405a75e279a-- From nobody Fri Jun 5 16:03:47 2020 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 4E31C3A0F0D for ; Fri, 5 Jun 2020 16:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 b0b6drNpWhST for ; Fri, 5 Jun 2020 16:03:44 -0700 (PDT) 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 3FFAD3A0F0B for ; Fri, 5 Jun 2020 16:03:44 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id b6so13726599ljj.1 for ; Fri, 05 Jun 2020 16:03:44 -0700 (PDT) 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=XjF1fkkPoI6qbZ7K/D8qvS37ok6gTgQI4CVW+kYNIog=; b=MV3ioddWXOZUSxMyK3Kv+SzhhnC1XokF4tLRhXKjClcaSbJivP+Pc+4ULfu03fZhmL Khan18dfWJmSmq83DiFsImGk7L5Q3caznMPOAaiY9POYBr7vsrx3K3RqJsDp1UBiIG1s 4UoCgVZqAyig5tUPbx0M5dxemB9WjeMbmteLXp5Q2gP4Qa4bFaVUsrc1ja+eB9sRFHX9 /MA8mKKPBxx9fbtH6cIzK7Uxp23YnS9kUoLuSxNMcUHoWlvDrn5BeXUUh+xCd9XCaLKO iFN6y5G1caz3IdoBEWN5rQ6uDpQWalqZM3lzHpCL4YuQi8C8lXbhsEestDMa/xLblDzJ obQA== 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=XjF1fkkPoI6qbZ7K/D8qvS37ok6gTgQI4CVW+kYNIog=; b=a4qHwnp1n1krtYAJidfdHCeZD8dVhEIArVzsMHYhj32Utv/zW6+9pLRiBYnPliHwak mZcAElAJuIFH0/QKpehrGUxXtkZwTVq8wBAYG+7o0NfmBiuWEsUy4TZJAMeter1MckdS dmdn3BjyNjL0u9vylBhb7bonPZZY5oFnPF+0OcnYBRk0aK6mvkUKpkn2AikrhKydb3Oi RbYmjp4wJoeK63xm1Kg4U8QZxyrHEUFrTVTsmEbWz7P8GqrVx9cykuGTcp57lrMti5qn zGqngaltMaUHq/OSyCVJGORaV5v9jq/fmxbjKgo/O+upPsld1ENmlxAD9EMUbsmrOQ9Q P2MQ== X-Gm-Message-State: AOAM530sGgjhrUVXOBuAApsoljDSj6fAID3cm1S1ifgPVacPEQh4cUCP /HkBHUBbxMIuavPqigl1A0fNEGUrv9EHTfyjvrA= X-Google-Smtp-Source: ABdhPJxbg9qlQQxr2n9BV3oMp/S00HNsPn8iH6Ah20wInZgi3mYQeiQl4+3incriwG54P0DtzxtjC22XalL5CdAigko= X-Received: by 2002:a2e:140a:: with SMTP id u10mr5842699ljd.56.1591398222297; Fri, 05 Jun 2020 16:03:42 -0700 (PDT) MIME-Version: 1.0 References: <2626827D-194C-4BA7-A62C-22387942B571@gmail.com> In-Reply-To: From: Dick Hardt Date: Fri, 5 Jun 2020 16:03:16 -0700 Message-ID: To: Tom Jones Cc: Yaron Sheffer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bc7e8905a75e4538" Archived-At: Subject: Re: [Txauth] Working group name 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, 05 Jun 2020 23:03:46 -0000 --000000000000bc7e8905a75e4538 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sortof There are other aspects besides the grant contents that may be negotiated. In my opinion, I don't see why steps 3 and 4 are needed if in step 1 the client is clear on what is required, and what is optional. I do think that the following flow is useful, what I call a multi step negotiation: 1 Client -> AS give me a 2. AS -> Client here is a =3D 9 3. Client -> AS I also want x (the value of a determines what else, if anything the Client may need) 4. AS -> Client x =3D foo =E1=90=A7 On Fri, Jun 5, 2020 at 3:55 PM Tom Jones wrote: > if it is to be a negotiation - irrespective of the user's direct > involvement, then then I see this sort of flow > 1 cl to as - give me a, b c > 2 as to cl - here is a grant to a > 3 cl to as - no, i really need b or i can't let you in > 4 as to cl - here is a grant to a, b > of course an alternate is that might be > 1 cl to as i want a, b, c and b is essential (I know justin hates that - > but california law requires it) > > That is what i think negotiation is, or is some other kind of negotiation > imagined > > Peace ..tom > > > On Fri, Jun 5, 2020 at 3:36 PM Dick Hardt wrote: > >> Hi Tom >> >> The charter is here https://datatracker.ietf.org/wg/txauth/about/ >> >> As I understand it, one of the items we are standardizing >> is negotiation protocol between the client and the server. How the serve= r >> gathers consent from the user is currently not in scope, and it is not >> clear to me what could be standardized in the experience between the use= r >> and the server that would be in scope for the IETF. Similarly for consen= t >> revocation. Additionally, a user may not be involved in the >> negotiation process at all. >> >> >> >> =E1=90=A7 >> >> On Fri, Jun 5, 2020 at 1:59 PM Tom Jones >> wrote: >> >>> Before we settle on this name, I must ask if the work group is prepared >>> for the creation of a negotiation protocol, which as I understand it wi= ll >>> include the client asking for grants, the user responding with their in= tent >>> (potentially either can start the flow) and the grant jwt (jose, whatev= er). >>> Presumably to complete the lifecycle some means for the user to revoke = the >>> grants and query the grants would also be provided. >>> >>> That seems like more of an integrated solution than prior work efforts >>> have involved. >>> What is the current status of the charter? >>> Peace ..tom >>> >>> >>> On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer >>> wrote: >>> >>>> Thank you to all who participated in the two rounds of name selection. >>>> This process has been longer than we ever expected, and I=E2=80=99m gl= ad we can >>>> declare consensus now and move forward. >>>> >>>> Based on the last two weeks=E2=80=99 worth of discussion, we have roug= h >>>> consensus on a name for the proposed working group: >>>> >>>> GNAP: Grant Negotiation and Authorization Protocol >>>> >>>> This decision will now enable our AD to put our charter [1] on the >>>> IESG's table, where I hope we will be approved as a working group. >>>> >>>> Heads up: we intend to meet in the upcoming all-virtual IETF 108 in >>>> late July, either as a BoF or as a newly chartered WG. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> >>>> [1] https://datatracker.ietf.org/doc/charter-ietf-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 >>> >> --000000000000bc7e8905a75e4538 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sortof

There are other aspects besides = the grant contents that may be negotiated.=C2=A0

I= n my opinion, I don't see why steps 3 and 4 are needed if in step 1 the= client is clear on what is required, and what is optional.

<= /div>
I do think that the following flow is useful, what I call a multi= step negotiation:

1 Client -> AS give me a
2. AS -> Client here is a =3D 9
3. Client -> AS I al= so want x (the value of a determines what else, if anything the Client may = need)
4. AS -> Client x =3D foo=C2=A0



3D""=E1=90=A7

On Fri, Jun 5, 202= 0 at 3:55 PM Tom Jones <= thomasclinganjones@gmail.com> wrote:
if it is to be a negotiation -= irrespective of the user's direct involvement, then then I see this so= rt of flow
1 cl to as - give me a, b c
2 as to cl - here is a= grant to a
3 cl to as - no, i really need b or i can't let y= ou in
4 as to cl - here is a grant to a, b
of course an= alternate is that might be
1 cl to as i want a, b, c and b is es= sential (I know justin hates that - but california law requires it)

That is what=C2=A0i think negotiation is, or is some othe= r kind of negotiation imagined

Peace ..tom


On= Fri, Jun 5, 2020 at 3:36 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom
=

As I understand it, one of the ite= ms we are standardizing is=C2=A0negotiation=C2=A0protocol between the clien= t and the server. How the server gathers consent from the user is currently= not in scope, and it is not clear to me what could be standardized in the = experience between the user and the server that would be in scope for the I= ETF. Similarly for consent revocation. Additionally, a user may not be invo= lved in the negotiation=C2=A0process at all.


<= /div>

=E1=90=A7

On Fri, Jun 5, 202= 0 at 1:59 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
Before we se= ttle on this name, I must ask if the work group is prepared for the creatio= n of a negotiation protocol, which as I understand it will include the clie= nt asking for grants, the user responding with their intent (potentially ei= ther can start the flow) and the grant jwt (jose, whatever). Presumably to = complete the lifecycle some means for the user to revoke the grants and que= ry=C2=A0the grants would also be provided.

That seems li= ke more of an integrated solution than prior work efforts have involved.
What is the current status of the charter?
Peace ..tom

On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote= :
Thank you to a= ll who participated in the two rounds of name selection. This process has b= een longer than we ever expected, and I=E2=80=99m glad we can declare conse= nsus now and move forward.

Based on the last two weeks=E2=80=99 worth of discussion, we have rough con= sensus on a name for the proposed working group:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 GNAP: Grant Negotiation and Authorization Proto= col

This decision will now enable our AD to put our charter [1] on the IESG'= ;s table, where I hope we will be approved as a working group.

Heads up: we intend to meet in the upcoming all-virtual IETF 108 in late Ju= ly, either as a BoF or as a newly chartered WG.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


[1] https://datatracker.ietf.org/doc/charter-= ietf-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
--000000000000bc7e8905a75e4538-- From nobody Sat Jun 6 01:34:29 2020 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 B8D913A0F8D for ; Sat, 6 Jun 2020 01:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 JTGjRyuY4E9i for ; Sat, 6 Jun 2020 01:34:25 -0700 (PDT) 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 6F3EF3A0F7C for ; Sat, 6 Jun 2020 01:34:25 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id a13so11968086ilh.3 for ; Sat, 06 Jun 2020 01:34:25 -0700 (PDT) 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=JtZs7A34PvdqC71ncgwhunMfToKBBsvhMoFnTPa2+n0=; b=FMIGSzQpdiwE3FhreQUzcCSd6HuoUJ038huKqv3tNbadY4OcEMUPiovEMTkTMu1PVM JSTPCHrphvUfzd4JKiSYoiXxq7xJ1P0VS4jeLAM6BjV/iK0lWJzhyz5lpxRnl4BivOaZ ngJzk7kxnZvCmRQWUILPuIn5Enioi5/HPhXuZ/+Su4QvLyYGnUQQjChdviCG8D6AKZEM 5xfzi33fNgi74WMCcZSTVsPkyOWwmY/HIfq4ksgHpxjsKkV0bDUG+3M2IKL2JyA9wYD5 O2eYkWTszBQTlu0F3m99q6UDqZxSBy3twDs6jA+kKKplr1hg1SPoBMRgAH6hiTqjjgiH CrcQ== 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=JtZs7A34PvdqC71ncgwhunMfToKBBsvhMoFnTPa2+n0=; b=geCzeInIpBv7i+FjlHGLVu8dQGs11rndhc4H8FyS7OmlWEKmSbmgFjkKOeQKWgHyps 3STVsx2pi7D1DTLpTRUySF1fnxbAyv90ZZozx0dLE3TomgPGzUIxxJcM+8MxTKG4esfo KKi0EwjICqwWJA/WxKWZHTGOk76rWkkcBCSLItzgGXMJPSb0bMJGRHN7Vv5HA1iV53QH ISHjfmh963GTftlrlj8CYB6+boMKXHg1FgAIdT3Qe2M45AKcdWVm465SicPe1uQ+ztyr gW59/6VISKFZVuUnSv6w8WK6yhiVzz1SMDGG6RRMngPPeOAuKl/wOCg1eDYDKsPnZ0Cx 0wQQ== X-Gm-Message-State: AOAM531SSlQMykbiA/cZljj+yxw2VkPdg7WRH5zgrxc/JM6+A6ynMXES BLyDWNaAX2WTuPvT0H4lnc0bIL/iWLp91UrdXnfDvn41 X-Google-Smtp-Source: ABdhPJz5EWRlhl3rwn1xCrdTaP3u9HZH0auliHJ+oIeCQ7sxQkjeBj3636ARUin8UxhnION1b4Hj7DzppQrVC5zeiD0= X-Received: by 2002:a92:c84f:: with SMTP id b15mr11414941ilq.123.1591432464454; Sat, 06 Jun 2020 01:34:24 -0700 (PDT) MIME-Version: 1.0 From: Fabien Imbault Date: Sat, 6 Jun 2020 10:34:14 +0200 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000ba57d305a7663eef" Archived-At: Subject: [Txauth] GNAP it is 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, 06 Jun 2020 08:34:27 -0000 --000000000000ba57d305a7663eef Content-Type: text/plain; charset="UTF-8" So, let's adopt a GNAP! We can even come with a little mascot (a bit like go gopher) as imagined by http://elisegravel.com/blog/adopte-un-gnap/, loved by little Canadians :-) Just to be sure, how do you recommand we pronounce it? Looking forward to the next steps too. Thxs Fabien --000000000000ba57d305a7663eef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, let's adopt a GNAP! We can even= come with a little mascot (a bit like go gopher) as imagined by=C2=A0http://elisegravel.com/blog/adopte-un-gnap/, loved by litt= le Canadians :-)=C2=A0

J= ust to be sure, how do you recommand we pronounce it?=C2=A0

Looking forward to the next steps too= .=C2=A0

Thxs
Fabien
--000000000000ba57d305a7663eef-- From nobody Sat Jun 6 03:11:47 2020 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 E513E3A105C for ; Sat, 6 Jun 2020 03:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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=sunet.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T03oor6cDb4E for ; Sat, 6 Jun 2020 03:11:35 -0700 (PDT) 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 631673A1096 for ; Sat, 6 Jun 2020 03:11:34 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id a9so11188872ljn.6 for ; Sat, 06 Jun 2020 03:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=nSdMKcnjnOStyC3xOS5nVNN9DyT0BgDZ0TVZYRijwls=; b=g4imG1rHksOX9kR/Pv12P7nZn5PGsQxnWekVsUni4XT6mVQ6XF5F8usEPXkw+1mfCf g5tj/RTQF2jOKwKxkrHNMwLGMQBfsR2Xyt/3D3nS7mnyTJC8tIg2ijLDnme1k4jGeWe6 h4tBqQAffC9HX7rRi/mpINYqkgm0vImhnM4n4KhxOZJFlxRubiRMTTVMQzONWyF4aIsW Z23ckSKfU87etliPGhTFe2fDDk9wklHBAhv7l2AORoHmbsJTLsasNvnaTStoDnhKiO8V A/pFa+j29zyyPL/yX+MAilSQ9wf4xi4OKqckDFPQm1okTWiRbSBzDqRYZPyUcPxvZG6Z Qiuw== 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:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=nSdMKcnjnOStyC3xOS5nVNN9DyT0BgDZ0TVZYRijwls=; b=UeYYIKJo0p3o2QNC+bEPKJFqz1GfNuQaVdvv7SbGFgTuPOieszLpLdEP83m+WSdDGO W5pNqeFRobN6P10XrIfVnDCYgSlGxwk8SlxT4V7KXEK6wBs/mOKUHP+GcMMcEpy5p6oH UTJKrJMO3igfiVhOU5x9Ol9SiwafSksQhx+7YyludkM//FehWe+5EnWKyYd+oCzq7I55 e0Q6DUCEtpJUWL8DZI3x6tU47pHJzeEyPKH2SjaLexvMLoAFRaAUvpASMdKxumUQ4fbu 0fYbutv0IUHGY2cy9dr3E1V4LKThopMQcIK3GX6cCMKkHtPFlUJM0Pz1W+1atFLW3T58 U5yA== X-Gm-Message-State: AOAM531kBxusOkJBg4cN7xtnTD94aTL8yo4c8k/nIfgku9zeYSQQEcx8 7GASzpLM1fbmYOWUCRLMs43QxQ== X-Google-Smtp-Source: ABdhPJwc1vQEtCJo4PlEgDumlosEpqNMvtn8+4hrle6x77BcfgunYlpBd2c8C3Tfq7auD2KsZj2Xig== X-Received: by 2002:a2e:6c15:: with SMTP id h21mr7120465ljc.403.1591438292863; Sat, 06 Jun 2020 03:11:32 -0700 (PDT) Received: from [10.0.0.193] (h-98-128-229-119.NA.cust.bahnhof.se. [98.128.229.119]) by smtp.gmail.com with ESMTPSA id b15sm2013534lfa.74.2020.06.06.03.11.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Jun 2020 03:11:31 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-5502E30C-9555-461E-B6D6-B67078D58EC1 Content-Transfer-Encoding: 7bit From: Leif Johansson Mime-Version: 1.0 (1.0) Date: Sat, 6 Jun 2020 12:11:28 +0200 Message-Id: <02A4F3E7-4681-4902-B625-0BA63E5E238B@sunet.se> References: Cc: txauth@ietf.org In-Reply-To: To: Fabien Imbault X-Mailer: iPhone Mail (17E262) Archived-At: Subject: Re: [Txauth] GNAP it is 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, 06 Jun 2020 10:11:46 -0000 --Apple-Mail-5502E30C-9555-461E-B6D6-B67078D58EC1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Skickat fr=C3=A5n min iPhone > 6 juni 2020 kl. 10:34 skrev Fabien Imbault : >=20 > =EF=BB=BF > So, let's adopt a GNAP! We can even come with a little mascot (a bit like g= o gopher) as imagined by http://elisegravel.com/blog/adopte-un-gnap/, loved b= y little Canadians :-)=20 >=20 > Just to be sure, how do you recommand we pronounce it? https://smurfs.fandom.com/wiki/Purple_Smurf I=E2=80=99ll just leave that there...= --Apple-Mail-5502E30C-9555-461E-B6D6-B67078D58EC1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Skickat fr=C3=A5n m= in iPhone

6 juni 2020 kl= . 10:34 skrev Fabien Imbault <fabien.imbault@gmail.com>:

=EF=BB=BF
So, let's adopt a GNAP! We can even come with a lit= tle mascot (a bit like go gopher) as imagined by http:= //elisegravel.com/blog/adopte-un-gnap/, loved by little Canadians :-)&nb= sp;

Just to be sure, how d= o you recommand we pronounce it?


I=E2=80=99ll just leave tha= t there...
= --Apple-Mail-5502E30C-9555-461E-B6D6-B67078D58EC1-- From nobody Sat Jun 6 06:45:14 2020 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 3F8583A09CD for ; Sat, 6 Jun 2020 06:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 S-Kvkq_P4qbF for ; Sat, 6 Jun 2020 06:45:09 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716023A09D1 for ; Sat, 6 Jun 2020 06:45:09 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id e4so15179092ljn.4 for ; Sat, 06 Jun 2020 06:45:09 -0700 (PDT) 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=IzVF5IVpin45v3+ttkzb5E0J8nWNmMQmU8X63K1E9RA=; b=pp7Y2qDu98KlU70Rm8TShERvjMyKNzXBwsf+jK0mduj9unzlvRRJcsDpZsPeYF5gTM KfQ/4ux3i8dLT72pkzNhcc81Td1gxALXt6XuWj6DxLWRgliilo+otqqbFoVZbJx+YYt/ 0hNye8Q1oMFE+6eBFjsB9h6AhMxVQZEwhgYK44jr3commX/H/kkbxCy35RubPTtEL0uz IUSNbCbHwDEl8CTpgvLdwF5WvnUSdh+t0TL2dUJkoHyMAaUoy8ztNbnJFBVwdY+iUopU Sy4scGkl6V5PwzF4+wnmjFADfLX2Lb4BDL8kBfhjX2U3cD+npLYPgVjCPVKGq7DOIpFt PMlA== 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=IzVF5IVpin45v3+ttkzb5E0J8nWNmMQmU8X63K1E9RA=; b=AkdbeE2EUZFC0/bjRSrVmyILse80WY/1Rj5UmrjjXElJteqba44vnL+7X1WGU4PCoG Pckn0MkladTJSgm8sy43QvZGIyNxYwmQNjMFUp2Cn4AWQAqJJ793MTsmjo4RUJzrwTxC G1l6GXfR1nNgvWUghN1w6HwiP5BjOTrHM7brUE1uAMJqz36rNequCI8xwUBvU+SWYhLn uUhfO1UhygKvBTnoxkdecllEDX5+C7bk3YTZcFrII7CJ03iGOBIGn9o4YjLDW6C9yxJc dtWN7SNdk3/u4QulZQl9aa1LCIG4PybC80zmLnYAOLunAQiC/8gNrWdY69v1D0fbQPyx R46Q== X-Gm-Message-State: AOAM532SX3edf0p/i9qKvTylpxqPH8axoqrH+cc2cXbIfSijB9qnCC8n JU4mDMnZxg7KoQaerCP2UBmBF/gPnYQoe7nSn4o= X-Google-Smtp-Source: ABdhPJyKcTcJcPqWilLP64t42+yduexJqeJkmNISScGkkOmr+YzcdnUNrX/uCPoORrKWRSUhTWi9Ir3Y+zBbhHfHBm0= X-Received: by 2002:a2e:140a:: with SMTP id u10mr7088432ljd.56.1591451105990; Sat, 06 Jun 2020 06:45:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sat, 6 Jun 2020 06:44:39 -0700 Message-ID: To: Fabien Imbault Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000d99e2f05a76a959a" Archived-At: Subject: Re: [Txauth] GNAP it is 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, 06 Jun 2020 13:45:12 -0000 --000000000000d99e2f05a76a959a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The obvious pronunciation choices are: nap (silent g as in gnaw) guh-nap (as in the GNU OS - https://www.gnu.org/gnu/pronunciation.en.html) gee-nap (as in G-man - government man - https://en.wikipedia.org/wiki/G-man= ) =E1=90=A7 On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault wrote: > So, let's adopt a GNAP! We can even come with a little mascot (a bit like > go gopher) as imagined by http://elisegravel.com/blog/adopte-un-gnap/, > loved by little Canadians :-) > > Just to be sure, how do you recommand we pronounce it? > > Looking forward to the next steps too.. > > Thxs > Fabien > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000d99e2f05a76a959a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The obvious pronunciation choices are:

nap (silent g as in gnaw)

guh-nap (as in the GNU = OS -=C2=A0https:/= /www.gnu.org/gnu/pronunciation.en.html)

gee-na= p (as in G-man - government man -=C2=A0https://en.wikipedia.org/wiki/G-man)



3D""=E1=90=A7

On Sat, Jun 6, 2= 020 at 1:34 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
So, let'= s adopt a GNAP! We can even come with a little mascot (a bit like go gopher= ) as imagined by=C2=A0http://elisegravel.com/blog/adopte-= un-gnap/, loved by little Canadians :-)=C2=A0
Just to be sure, how do you recommand we pronounc= e it?=C2=A0

Looking forw= ard to the next steps too..=C2=A0

Thxs
Fabien
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000d99e2f05a76a959a-- From nobody Sat Jun 6 07:52:27 2020 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 64A513A0A34 for ; Sat, 6 Jun 2020 07:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, 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 lSroPTk7BG2k for ; Sat, 6 Jun 2020 07:52:25 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 B41573A0A2C for ; Sat, 6 Jun 2020 07:52:24 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id l1so9779167ede.11 for ; Sat, 06 Jun 2020 07:52:24 -0700 (PDT) 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=YCEPNl8pXjBo1nbwOMAhMJfMOHefEmfRoU7k0Km8A7c=; b=iwONd6vcjPob0WB0j/QxmXZ29NGDy3G3MqUPeD4FgTpHtQoFyq1eQ3tTCV46kTOvLr E9T3Broxkgltufv2U+/6qdOku+Dgswf0u51OxMAOsNPNQb1E/FA4exjfRYTMFUgzYmZC wxPhf/VPRgAjS6Gm9r9bY0eYNKW64OFSyp51VyBPlkMsOVjdDwBohANtuqNUJpwbp+t4 UUyoNECSFweB+7HRzH/tK7xVRgnixWdGCRnID+HnjDbt9ohhQMKLYIVxV1kPrIZCox4O W3orcv7WeCyL5mZJDP9I7RaFZ+kYWSpn14eu66xN9THuo6o9l6uWQp+rqo6MTqoVxfbW tKpQ== 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=YCEPNl8pXjBo1nbwOMAhMJfMOHefEmfRoU7k0Km8A7c=; b=DdV21C86bygbZxqWCu9p6ZwPv6xzTivwTIxGKsESguy1+1gdnUuKba3fjjozhFt4J5 LVV3+hsJqNWF0x7hFf/TZlsRfwoHSFLu0EChrTMr68SNmhbcNij0jnrsacjCFn4wmAdK 6beVePdo2DbnL3P1mNXJggAGgfy4Q7ZAcf62K0kb9vo6TBLsepvQYgKqJkkHKqNU9bv/ jPJdZCS9+4dTMda+V0WI0Fifus8gU1XsJ4bYl6meWboRria3EOgPBV/CHCcJ/F/QDd5F Dq8B/plK++0mNfUQo5/kuupCDCxEj26/A+I2B5PAPkpTMuMLLACMZeF5ECDur0YD6btl AUlA== X-Gm-Message-State: AOAM531WxcHelBvx8LImvxdgFYyw+6dsUb3/Q3jLUxMaLAl3JehoQVPL M2iD0aULDHtvhc9VK5QHC/EOwf8gXeHbFdlGU48= X-Google-Smtp-Source: ABdhPJxvXebo5mc6Y1VZBw+HKolC0a/0RaGWezf5LCFPqkP4uLOB1EJadkzGeY1nRsz7Z2CKANewgKq7F+phJA9OM04= X-Received: by 2002:a05:6402:8d8:: with SMTP id d24mr13842756edz.287.1591455143122; Sat, 06 Jun 2020 07:52:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jared Jennings Date: Sat, 6 Jun 2020 09:52:10 -0500 Message-ID: To: Dick Hardt Cc: Fabien Imbault , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000007b5c4b05a76b8618" Archived-At: Subject: Re: [Txauth] GNAP it is 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, 06 Jun 2020 14:52:26 -0000 --0000000000007b5c4b05a76b8618 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I vote for G silent. For the reason it's most common to pronounce, especially for those not familiar with open source usages. On Sat, Jun 6, 2020, 08:45 Dick Hardt wrote: > The obvious pronunciation choices are: > > nap (silent g as in gnaw) > > guh-nap (as in the GNU OS - https://www.gnu.org/gnu/pronunciation.en.html= ) > > gee-nap (as in G-man - government man - > https://en.wikipedia.org/wiki/G-man) > > > > =E1=90=A7 > > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault > wrote: > >> So, let's adopt a GNAP! We can even come with a little mascot (a bit lik= e >> go gopher) as imagined by http://elisegravel.com/blog/adopte-un-gnap/, >> loved by little Canadians :-) >> >> Just to be sure, how do you recommand we pronounce it? >> >> Looking forward to the next steps too.. >> >> Thxs >> Fabien >> -- >> 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 > --0000000000007b5c4b05a76b8618 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I vote for G silent. For the reason it's most common = to pronounce, especially for those not familiar with open source usages.
On = Sat, Jun 6, 2020, 08:45 Dick Hardt <dick.hardt@gmail.com> wrote:
The obvious pronunciation choices are:

nap (silent g as in gnaw)

guh-nap (as in the= GNU OS -=C2=A0https://www.gnu.org/gnu/pronunciation.en= .html)

gee-nap (as in G-man - government man -= =C2=A0https://en.wikipedia.org/wiki/G-man)



3D""=E1=90=A7

<= div class=3D"gmail_quote">
On Sat, Jun= 6, 2020 at 1:34 AM Fabien Imbault <fabien.imbault@gmail.com&g= t; wrote:
So, let's adopt a GNAP! We can even come = with a little mascot (a bit like go gopher) as imagined by=C2=A0http://elisegravel.com/blog/adopte-un-gnap/, loved by= little Canadians :-)=C2=A0

Just to be sure, how do you recommand we pronounce it?=C2=A0

Looking forward to the next steps = too..=C2=A0

Thxs
Fabien
--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--0000000000007b5c4b05a76b8618-- From nobody Sat Jun 6 08:03:50 2020 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 A34A43A0A53 for ; Sat, 6 Jun 2020 08:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=amanjeev.com header.b=aEIuJ/OM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sxEMmFA8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlSLCp3Ii5rn for ; Sat, 6 Jun 2020 08:03:47 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E936A3A0A51 for ; Sat, 6 Jun 2020 08:03:46 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2A7EA5C009E; Sat, 6 Jun 2020 11:03:46 -0400 (EDT) Received: from imap8 ([10.202.2.58]) by compute2.internal (MEProxy); Sat, 06 Jun 2020 11:03:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amanjeev.com; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type; s=fm2; bh=pmQnpoOA6sn58s/uR5vZhBRvMJepmOr VCMsRFaZ0NTg=; b=aEIuJ/OMmhWI6Qmk0/HsyJQgu2xml8A9+aKe97zSdZx7Lc+ AnhDk9Vp1SyBmivj2bleZt4TJi64uMC1BXuyHJw56XWk+bxdfGQgtKNFeD9eol0I iSvQZP8V/FG8SKDaYXSuhxL64SgRVaiy3MknJZqOHhjUHjWOpUvKeRg7EGOGXsBq L7kRgPFYSAgdk1o+Kz0IP5qxq7Ez0q3l+pXnO/R/dIMULhPvfW0i0N24hg2NCseR zpLehZzDUTSFGvRGmggzrLZZTeFAP00LnCBD2LqAktQ4dC45bW8STnrHACOZChec fwMgGJJZvy3RPU6740GZbt6xVM1RW/8weTNoyng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=pmQnpo OA6sn58s/uR5vZhBRvMJepmOrVCMsRFaZ0NTg=; b=sxEMmFA8hRLxka0Q58WSUJ IkIFZCs3ISbp/nhqXZPTnJG/B+teKmYqGg6W6b4QlmjTR2dHv6mdydIvzfxgRLz3 8mURA2jxC6kpGYLIuGUnzeaI8GJkPog/YIbIx7cj14RuLeqcStKKgQI92h0GVdpK 1QxmUlx1Jm5kHy/npl7KAUjcaAVppeRYoYUB7r/FE4efockRtJIEZYJidSb8zs7Y iQNP/HX7eSpbzjUYdKSNB6VShHhy5oO2KR9uCyZehcOvvFgzXh/jBob/SYjgQGNC 6ev2NTA40VWHtrFQtUn/1o5yoqWSPs/0rk+KZgEuxwbFrpf5tpPJV6Gi4mTVXcqQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeghedgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdetmhgr nhhjvggvvhcuufgvthhhihdfuceorghjsegrmhgrnhhjvggvvhdrtghomheqnecuggftrf grthhtvghrnhepkefggeeuhedvfeelveduhefhgedugfetueeggfejfeeuteejhfelvdek teevtddvnecuffhomhgrihhnpehgnhhurdhorhhgpdifihhkihhpvgguihgrrdhorhhgpd gvlhhishgvghhrrghvvghlrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrjhesrghmrghnjhgvvghvrdgtoh hm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B4901520094; Sat, 6 Jun 2020 11:03:45 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <399d74e9-96d8-4f61-b01e-df9a8ee972d2@www.fastmail.com> In-Reply-To: References: Date: Sat, 06 Jun 2020 11:03:25 -0400 From: "Amanjeev Sethi" To: "Jared Jennings" , "Dick Hardt" Cc: "Fabien Imbault" , txauth@ietf.org Content-Type: multipart/alternative; boundary=1c950eed6f6f4e97838502e0cf0883ca Archived-At: Subject: Re: [Txauth] GNAP it is 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, 06 Jun 2020 15:03:49 -0000 --1c950eed6f6f4e97838502e0cf0883ca Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Vote for 'G' silent, as in 'lagnappe' ;) On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote: > I vote for G silent. For the reason it's most common to pronounce, esp= ecially for those not familiar with open source usages. >=20 > On Sat, Jun 6, 2020, 08:45 Dick Hardt wrote: >> The obvious pronunciation choices are: >>=20 >> nap (silent g as in gnaw) >>=20 >> guh-nap (as in the GNU OS - https://www.gnu.org/gnu/pronunciation.en.= .html ) >>=20 >> gee-nap (as in G-man - government man - https://en.wikipedia.org/wiki= /G-man) >>=20 >>=20 >>=20 >> =E1=90=A7 >>=20 >> On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault wrote: >>> So, let's adopt a GNAP! We can even come with a little mascot (a bit= like go gopher) as imagined by http://elisegravel.com/blog/adopte-un-gn= ap/, loved by little Canadians :-)=20 >>>=20 >>> Just to be sure, how do you recommand we pronounce it?=20 >>>=20 >>> Looking forward to the next steps too..=20 >>>=20 >>> Thxs >>> Fabien >>> -- >>> 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 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth >=20 --1c950eed6f6f4e97838502e0cf0883ca Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Vote for 'G' si= lent, as in 'lagnappe' ;)

On Sat, Jun 6, 20= 20, at 10:52 AM, Jared Jennings wrote:
I vote for G silent. For the re= ason it's most common to pronounce, especially for those not familiar wi= th open source usages.

On Sat, Jun 6, 2020, 08:45= Dick Hardt <dick.hardt@gmail= .com> wrote:
The obvious pronunciati= on choices are:

nap (silent g as in gnaw)<= br>

guh-nap (as in the GNU OS - https://www.gnu.org/gnu/pronunciation.en..html)

gee-nap (as in G-man - government man - https://en.wikipedia.org/wiki/G-man)



=E1=90=A7

On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbaul= t <fabien.imbault@gmail.com> wrote:
So, let's adopt a GNAP! We can even come with a= little mascot (a bit like go gopher) as imagined by http://elisegravel.com/blog/adopte-un-gnap/, loved= by little Canadians :-) 

Just to be sure, how do you recommand we pronounce it?&nbs= p;

Looking forwar= d to the next steps too.. 

Thxs
Fabien
--
Txauth mailing list
-- 
T= xauth mailing list
https://www.ietf.org/mailman/listinfo/txauth


--1c950eed6f6f4e97838502e0cf0883ca-- From nobody Sun Jun 7 08:48:10 2020 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 25D0A3A0978 for ; Sun, 7 Jun 2020 08:48:08 -0700 (PDT) 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 OHYf2nnZ-xBE for ; Sun, 7 Jun 2020 08:48:05 -0700 (PDT) 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 E9FA23A0977 for ; Sun, 7 Jun 2020 08:48:04 -0700 (PDT) Received: from [192.168.1.14] (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 057Fm18X031526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 7 Jun 2020 11:48:01 -0400 From: Justin Richer Message-Id: <9690012E-5B57-4C1D-BF26-13E30B3DA23C@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_979F3466-7BCB-4674-9D1E-2D3AE0FC2F57" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 7 Jun 2020 11:48:00 -0400 In-Reply-To: Cc: Dick Hardt , Yaron Sheffer , "txauth@ietf.org" To: Tom Jones References: <2626827D-194C-4BA7-A62C-22387942B571@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Working group name 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, 07 Jun 2020 15:48:08 -0000 --Apple-Mail=_979F3466-7BCB-4674-9D1E-2D3AE0FC2F57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tom, The word =E2=80=9Cnegotiation=E2=80=9D in the new name is a synonym of = =E2=80=9Ctransaction=E2=80=9D[1] in the sense that we=E2=80=99re using = it. The negotiation isn=E2=80=99t quite what you=E2=80=99re outlining = below, but it does start between the client and the AS. What is really = happening is the client is requesting something, and the AS is telling = the client what it needs to provide, either directly or through the = user, to fulfill that request. So the items below would really go = something like: 1: cl to as - give me a, b, c 2: as to cl - to get that, give me x, y, or z (and one or more of these = can be =E2=80=9Cinteract with the user=E2=80=9D in some way) 3: user to as - I approve a and b but not c 4: as to cl - here=E2=80=99s a token for a and b 5: cl to user - we didn=E2=80=99t get =E2=80=9Cc=E2=80=9D and I can=E2=80=99= t do anything for you if you don=E2=80=99t let me have =E2=80=9Cc=E2=80=99= , do you want to try that again? 6: cl to as - give me a, b, c (but I can give you proof that I already = got a and b)[2] So if the client didn=E2=80=99t get =E2=80=9Cc=E2=80=9D but really = really needs =E2=80=9Cc=E2=80=9D, that=E2=80=99s an error from the = client=E2=80=99s perspective but I don=E2=80=99t see it as an error from = the protocol perspective. One of the reasons that the client can=E2=80=99t= just mark =E2=80=9Cc=E2=80=9D as =E2=80=9Cessential=E2=80=9D to solve = this problem is that the client can=E2=80=99t always know :why: it = didn=E2=80=99t get =E2=80=9Cc=E2=80=9D in its ultimate token, and in = many cases it can=E2=80=99t do much about it. It could have been the = user didn=E2=80=99t approve that specific one. It could have been that = the AS didn=E2=80=99t allow this particular client to even ask for it. = It could have been that the client didn=E2=80=99t provide the right set = of information upfront (device posture or organization affiliation = credentials come to mind, which are quite separate from client = authentication and one big reason to get away from a =E2=80=9Cclient = ID=E2=80=9D model, but that=E2=80=99s another point).=20 Historically, when we=E2=80=99ve had protocols where the client can mark = some claims as =E2=80=9Coptional=E2=80=9D or =E2=80=9Cessential=E2=80=9D, = we pretty much always end up with all clients marking things as = =E2=80=9Cessential=E2=80=9D when they may or may not be in reality. This = makes the protocol break unnecessarily at runtime. OAuth 2=E2=80=99s = pattern of the client asking for what it needs and getting what it gets = has been shown to be very robust, and I think it=E2=80=99ll be even more = important when we=E2=80=99ve got multiple dimensions of access being = specified (as per our charter). There=E2=80=99s also a whole other = discussion about slitting and directing tokens that this group needs to = have.=20 So that=E2=80=99s why my stance is that we should let the client ask for = what it wants, deal with what it gets, and decide if it needs to bug the = user and try again or not. After all, the protocol path needs to account = for :error: conditions and not just the happy path, and that is what I = think is missing below. I think that (4) in the list below is really = unlikely if it=E2=80=99s just the client being able to have some sort of = =E2=80=9Cno really I insist=E2=80=9D flag. Why would that flag make the = AS change its mind about its auth decision made in (2) in the list = below? That decision was made in some other context, and it=E2=80=99s = not because the client didn=E2=80=99t ask hard enough. Additionally, I think it gets really messy really quickly when we start = letting the client specify some level of desired-ness or required-ness = for the things it=E2=80=99s asking for. We end up with states like =E2=80=9C= I really want this but I can continue without it by doing something = different=E2=80=9D or =E2=80=9CI=E2=80=99m only asking for this ahead of = time but I might not need it until later if at all=E2=80=9D or any = number of other fuzzy bits in between the =E2=80=9Cessential/optional=E2=80= =9D false binary. Therefore I think this protocol should allow exactly = one class of resource request :and: make the behavior consistent and = predictable across it. The means the ideas of what returns an error, = what returns with less than what is asked for, or what other options are = at the AS=E2=80=99s disposal and what the client can do with them. I = think by having a consistent behavior :and: having the ability to do = step-up requests (create a new token request built on an existing one) = are going to be key for solving this in a real and interoperable = fashion, without making things needlessly complicated in ways that = don=E2=80=99t solve our problems. =E2=80=94 Justin [1] https://www.thesaurus.com/browse/negotiation?s=3Dt [2] At least, this is a design feature of the XYZ protocol, and I think = it=E2=80=99s important to be able to build requests on top of each = other. > On Jun 5, 2020, at 6:55 PM, Tom Jones = wrote: >=20 > if it is to be a negotiation - irrespective of the user's direct = involvement, then then I see this sort of flow > 1 cl to as - give me a, b c > 2 as to cl - here is a grant to a > 3 cl to as - no, i really need b or i can't let you in > 4 as to cl - here is a grant to a, b > of course an alternate is that might be > 1 cl to as i want a, b, c and b is essential (I know justin hates that = - but california law requires it) >=20 > That is what i think negotiation is, or is some other kind of = negotiation imagined >=20 > Peace ..tom >=20 >=20 > On Fri, Jun 5, 2020 at 3:36 PM Dick Hardt > wrote: > Hi Tom >=20 > The charter is here https://datatracker..ietf.org/wg/txauth/about/ = >=20 > As I understand it, one of the items we are standardizing is = negotiation protocol between the client and the server. How the server = gathers consent from the user is currently not in scope, and it is not = clear to me what could be standardized in the experience between the = user and the server that would be in scope for the IETF. Similarly for = consent revocation. Additionally, a user may not be involved in the = negotiation process at all. >=20 >=20 >=20 > =E1=90=A7 >=20 > On Fri, Jun 5, 2020 at 1:59 PM Tom Jones > wrote: > Before we settle on this name, I must ask if the work group is = prepared for the creation of a negotiation protocol, which as I = understand it will include the client asking for grants, the user = responding with their intent (potentially either can start the flow) and = the grant jwt (jose, whatever). Presumably to complete the lifecycle = some means for the user to revoke the grants and query the grants would = also be provided. >=20 > That seems like more of an integrated solution than prior work efforts = have involved. > What is the current status of the charter? > Peace ..tom >=20 >=20 > On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer > wrote: > Thank you to all who participated in the two rounds of name selection. = This process has been longer than we ever expected, and I=E2=80=99m glad = we can declare consensus now and move forward. >=20 > Based on the last two weeks=E2=80=99 worth of discussion, we have = rough consensus on a name for the proposed working group: >=20 > GNAP: Grant Negotiation and Authorization Protocol >=20 > This decision will now enable our AD to put our charter [1] on the = IESG's table, where I hope we will be approved as a working group. >=20 > Heads up: we intend to meet in the upcoming all-virtual IETF 108 in = late July, either as a BoF or as a newly chartered WG. >=20 > Thanks, > Yaron >=20 >=20 > [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/ = >=20 >=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 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_979F3466-7BCB-4674-9D1E-2D3AE0FC2F57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Tom,

The word = =E2=80=9Cnegotiation=E2=80=9D in the new name is a synonym of = =E2=80=9Ctransaction=E2=80=9D[1] in the sense that we=E2=80=99re using = it. The negotiation isn=E2=80=99t quite what you=E2=80=99re outlining = below, but it does start between the client and the AS. What is really = happening is the client is requesting something, and the AS is telling = the client what it needs to provide, either directly or through the = user, to fulfill that request. So the items below would really go = something like:


1: cl to as - give me a, = b, c
2: as to cl - to get that, give me x, y, or z = (and one or more of these can be =E2=80=9Cinteract with the user=E2=80=9D = in some way)
3: user to as - I approve a and b but = not c
4: as to cl - here=E2=80=99s a token for a = and b
5: cl to user - we didn=E2=80=99t get =E2=80=9C= c=E2=80=9D and I can=E2=80=99t do anything for you if you don=E2=80=99t = let me have =E2=80=9Cc=E2=80=99, do you want to try that = again?
6: cl to as - give me a, b, c (but I can = give you proof that I already got a and b)[2]


So = if the client didn=E2=80=99t get =E2=80=9Cc=E2=80=9D but really really = needs =E2=80=9Cc=E2=80=9D, that=E2=80=99s an error from the client=E2=80=99= s perspective but I don=E2=80=99t see it as an error from the protocol = perspective. One of the reasons that the client can=E2=80=99t just mark = =E2=80=9Cc=E2=80=9D as =E2=80=9Cessential=E2=80=9D to solve this problem = is that the client can=E2=80=99t always know :why: it didn=E2=80=99t get = =E2=80=9Cc=E2=80=9D in its ultimate token, and in many cases it can=E2=80=99= t do much about it. It could have been the user didn=E2=80=99t approve = that specific one. It could have been that the AS didn=E2=80=99t allow = this particular client to even ask for it. It could have been that the = client didn=E2=80=99t provide the right set of information upfront = (device posture or organization affiliation credentials come to mind, = which are quite separate from client authentication and one big reason = to get away from a =E2=80=9Cclient ID=E2=80=9D model, but that=E2=80=99s = another point). 

Historically, when we=E2=80=99ve had protocols where the = client can mark some claims as =E2=80=9Coptional=E2=80=9D or = =E2=80=9Cessential=E2=80=9D, we pretty much always end up with all = clients marking things as =E2=80=9Cessential=E2=80=9D when they may or = may not be in reality. This makes the protocol break unnecessarily at = runtime. OAuth 2=E2=80=99s pattern of the client asking for what it = needs and getting what it gets has been shown to be very robust, and I = think it=E2=80=99ll be even more important when we=E2=80=99ve got = multiple dimensions of access being specified (as per our charter). = There=E2=80=99s also a whole other discussion about slitting and = directing tokens that this group needs to have. 

So that=E2=80=99s why my = stance is that we should let the client ask for what it wants, deal with = what it gets, and decide if it needs to bug the user and try again or = not. After all, the protocol path needs to account for :error: = conditions and not just the happy path, and that is what I think is = missing below. I think that (4) in the list below is really unlikely if = it=E2=80=99s just the client being able to have some sort of =E2=80=9Cno = really I insist=E2=80=9D flag. Why would that flag make the AS change = its mind about its auth decision made in (2) in the list below? That = decision was made in some other context, and it=E2=80=99s not because = the client didn=E2=80=99t ask hard enough.

Additionally, I think it gets really = messy really quickly when we start letting the client specify some level = of desired-ness or required-ness for the things it=E2=80=99s asking for. = We end up with states like =E2=80=9CI really want this but I can = continue without it by doing something different=E2=80=9D or =E2=80=9CI=E2= =80=99m only asking for this ahead of time but I might not need it until = later if at all=E2=80=9D or any number of other fuzzy bits in between = the =E2=80=9Cessential/optional=E2=80=9D false binary. Therefore I think = this protocol should allow exactly one class of resource request :and: = make the behavior consistent and predictable across it. The means the = ideas of what returns an error, what returns with less than what is = asked for, or what other options are at the AS=E2=80=99s disposal and = what the client can do with them. I think by having a consistent = behavior :and: having the ability to do step-up requests (create a new = token request built on an existing one) are going to be key for solving = this in a real and interoperable fashion, without making things = needlessly complicated in ways that don=E2=80=99t solve our = problems.

 =E2=80=94 Justin

[1] https://www.thesaurus.com/browse/negotiation?s=3Dt

[2] At least, this is = a design feature of the XYZ protocol, and I think it=E2=80=99s important = to be able to build requests on top of each other.

On Jun = 5, 2020, at 6:55 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

if it is to be a negotiation - = irrespective of the user's direct involvement, then then I see this sort = of flow
1 cl to as - give me a, b c
2 = as to cl - here is a grant to a
3 cl to as - no, i = really need b or i can't let you in
4 as to cl - = here is a grant to a, b
of course an alternate is = that might be
1 cl to as i want a, b, c and b is = essential (I know justin hates that - but california law requires = it)

That is = what i think negotiation is, or is some other kind of negotiation = imagined

Peace ..tom


On Fri, Jun 5, 2020 at 3:36 PM Dick = Hardt <dick.hardt@gmail.com> wrote:
Hi = Tom

The charter is = here https://datatracker..ietf.org/wg/txauth/about/

As I understand it, one = of the items we are standardizing is negotiation protocol = between the client and the server. How the server gathers consent from = the user is currently not in scope, and it is not clear to me what could = be standardized in the experience between the user and the server that = would be in scope for the IETF. Similarly for consent revocation. = Additionally, a user may not be involved in the negotiation process = at all.



3D""=E1=90=A7

On Fri, Jun = 5, 2020 at 1:59 PM Tom Jones <thomasclinganjones@gmail.com> wrote:
Before we = settle on this name, I must ask if the work group is prepared for the = creation of a negotiation protocol, which as I understand it will = include the client asking for grants, the user responding with their = intent (potentially either can start the flow) and the grant jwt (jose, = whatever). Presumably to complete the lifecycle some means for the user = to revoke the grants and query the grants would also be = provided.

That seems = like more of an integrated solution than prior work efforts have = involved.
What is the current status of the = charter?
Peace = ..tom


On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Thank you to all who participated in = the two rounds of name selection. This process has been longer than we = ever expected, and I=E2=80=99m glad we can declare consensus now and = move forward.

Based on the last two weeks=E2=80=99 worth of discussion, we have rough = consensus on a name for the proposed working group:

        GNAP: Grant Negotiation and Authorization = Protocol

This decision will now enable our AD to put our charter [1] on the = IESG's table, where I hope we will be approved as a working group.

Heads up: we intend to meet in the upcoming all-virtual IETF 108 in late = July, either as a BoF or as a newly chartered WG.

Thanks,
        Yaron


[1] https://datatracker.ietf.org/doc/charter-ietf-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
=
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_979F3466-7BCB-4674-9D1E-2D3AE0FC2F57-- From nobody Sun Jun 7 08:53:45 2020 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 598223A0988 for ; Sun, 7 Jun 2020 08:53:43 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 vKWcREdH_38Y for ; Sun, 7 Jun 2020 08:53:41 -0700 (PDT) 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 03DFC3A0984 for ; Sun, 7 Jun 2020 08:53:40 -0700 (PDT) Received: from [192.168.1.14] (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 057Frc1w032740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 7 Jun 2020 11:53:38 -0400 From: Justin Richer Message-Id: <6999853B-5A30-4CE9-B17C-1C8E7D9002B3@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_3B02E780-F867-4B1F-85F2-AC85F3CE09AE" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 7 Jun 2020 11:53:38 -0400 In-Reply-To: Cc: txauth@ietf.org To: Fabien Imbault References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] GNAP it is 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, 07 Jun 2020 15:53:44 -0000 --Apple-Mail=_3B02E780-F867-4B1F-85F2-AC85F3CE09AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ultimately, we can only suggest how to pronounce it. The world at large = will eventually decide how it=E2=80=99s said, and one of the downsides = of this name is that there are multiple possible and reasonable readings = of it. So I think that as a community we should just get used to = answering to all of them. As much as =E2=80=9Cjwt" is supposed to be = pronounced like =E2=80=9Cjot=E2=80=9D I=E2=80=99ve long had to work with = engineers that say =E2=80=9Cjay double yoo tee=E2=80=9D and =E2=80=9Cjay = wat=E2=80=9D, among others, and no amount of =E2=80=9Ccorrection=E2=80=9D = will make that kind of thing go away for good, especially since many = people will see this first in text and second, if ever, hear it out = loud. At least we avoided the Zed vs. Zee confusion, which would have been a = worse mess. =E2=80=94 Justin > On Jun 6, 2020, at 4:34 AM, Fabien Imbault = wrote: >=20 > So, let's adopt a GNAP! We can even come with a little mascot (a bit = like go gopher) as imagined by = http://elisegravel.com/blog/adopte-un-gnap/ = , loved by little Canadians = :-)=20 >=20 > Just to be sure, how do you recommand we pronounce it?=20 >=20 > Looking forward to the next steps too..=20 >=20 > Thxs > Fabien > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_3B02E780-F867-4B1F-85F2-AC85F3CE09AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ultimately, we can only suggest how to = pronounce it. The world at large will eventually decide how it=E2=80=99s = said, and one of the downsides of this name is that there are multiple = possible and reasonable readings of it. So I think that as a community = we should just get used to answering to all of them. As much as =E2=80=9Cj= wt" is supposed to be pronounced like =E2=80=9Cjot=E2=80=9D I=E2=80=99ve = long had to work with engineers that say =E2=80=9Cjay double yoo tee=E2=80= =9D and =E2=80=9Cjay wat=E2=80=9D, among others, and no amount of = =E2=80=9Ccorrection=E2=80=9D will make that kind of thing go away for = good, especially since many people will see this first in text and = second, if ever, hear it out loud.

At least we avoided the Zed vs. Zee = confusion, which would have been a worse mess.

 =E2=80=94 Justin

On Jun 6, 2020, at 4:34 AM, Fabien Imbault <fabien.imbault@gmail.com> wrote:

So, = let's adopt a GNAP! We can even come with a little mascot (a bit like go = gopher) as imagined by http://elisegravel.com/blog/adopte-un-gnap/, loved by = little Canadians :-) 

Just to be sure, how do = you recommand we pronounce it? 
Looking forward to the = next steps too.. 

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

= --Apple-Mail=_3B02E780-F867-4B1F-85F2-AC85F3CE09AE-- From nobody Sun Jun 7 09:52:55 2020 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 D28733A09F8 for ; Sun, 7 Jun 2020 09:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 XQSm1rjSVqQW for ; Sun, 7 Jun 2020 09:52:49 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0: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 5DBFD3A09F6 for ; Sun, 7 Jun 2020 09:52:49 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id a3so1140264oid.4 for ; Sun, 07 Jun 2020 09:52:49 -0700 (PDT) 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=UnAi8XgFJdEysmcda8n8aAgh7/2Gv6/CxSov2lV0vzE=; b=EwnzCmd7VINpeTeqb0h/qb8FQBK93pPgmJe3A8UeqctgozG/GZDGVScUcA9aEBU/SJ XFtzOeNYIVLC8VmlcmkgNVpMvZcnwzdKnc/Jjz2VV5G4KsNrMov/h60re0YKbLVoZ8QT Gp7EGjithWENEl44pUwhOmcOKVPGlTXlXs03IiYReInDOlkleTDFn9Ab5y78+30hFFwi FzPmTARxRRgxRZSlMwKqrtIexafW8VnKdPJcL+K78Td0iil4TbIqVkSwM62DXDFSPo+7 T2gy6AerPmGvIRJ+o2A8NnbONcq92JDMvBGVdt6u62kfk5a9NWzbdVZ55pP6+RYgLkKP cKOw== 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=UnAi8XgFJdEysmcda8n8aAgh7/2Gv6/CxSov2lV0vzE=; b=GM5u3ZHBW+MgqBu0AngCPmf+F6gjcaTprcBHl0mdDxrfu96u0Ym2O2ywTGDm/AVhxB ZidwctSLnIJZLefBt26HHhym3QgXamKNTZmsz5jGcgoW9qMux6epp0WLJjCEWFUprT8Q og2pFCeqg6HF4L7KFTJiJN0UYSAZ/P0zKSKdQxYUUBH0ZZfLRnsr+DeEsLaNEeLR8x8A RVPbVntsFMNOvav54rQAJX9ywhDlvKjhOH0YOW11xNteZdTJtA75Nm8UpiFEYJUInrcH c+KwFsi0W2G6ZBXLtx5sjsI/MwjHKt9KBp9rMVhNyvwTTKZEDvFcQad6cVWqNBeViIgf mH4A== X-Gm-Message-State: AOAM532KRZxJBBpMilt612zzGhAMKHLIaHlqDCWtU0Urq7d45zRZiMQ8 j+ZeqUQ0PUGLccRGxNdANfchWE12CC+WpaCYtnU= X-Google-Smtp-Source: ABdhPJxUi6dB7GDmwAg33K6NF8DSG9fXfdlTcFUAPTUG6bG/1aAc6jjAvikIP287SylKRy5Q1g9uZdgKvy0vTDVQ28E= X-Received: by 2002:aca:b309:: with SMTP id c9mr7990854oif.63.1591548767254; Sun, 07 Jun 2020 09:52:47 -0700 (PDT) MIME-Version: 1.0 References: <2626827D-194C-4BA7-A62C-22387942B571@gmail.com> <9690012E-5B57-4C1D-BF26-13E30B3DA23C@mit.edu> In-Reply-To: <9690012E-5B57-4C1D-BF26-13E30B3DA23C@mit.edu> From: Tom Jones Date: Sun, 7 Jun 2020 09:52:34 -0700 Message-ID: To: Justin Richer Cc: Dick Hardt , Yaron Sheffer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ea3d8505a7815207" Archived-At: Subject: Re: [Txauth] Working group name 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, 07 Jun 2020 16:52:53 -0000 --000000000000ea3d8505a7815207 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe what you say is reflectively true. It is, however, now, or soon to be, illegal. I prefer to be ready for the future, rather than be surprised by it. What I have been looking for is something like scope, or purpose, that can be requested by the client for approval by the user. I suspect that will only work in constrained federations, like healthcare, where a taxonomy of purposes can be created. My needs appear to be out of scope of this committee, so I have left it. thx ..Tom (mobile) On Sun, Jun 7, 2020, 8:48 AM Justin Richer wrote: > Hi Tom, > > The word =E2=80=9Cnegotiation=E2=80=9D in the new name is a synonym of = =E2=80=9Ctransaction=E2=80=9D[1] in > the sense that we=E2=80=99re using it. The negotiation isn=E2=80=99t quit= e what you=E2=80=99re > outlining below, but it does start between the client and the AS. What is > really happening is the client is requesting something, and the AS is > telling the client what it needs to provide, either directly or through t= he > user, to fulfill that request. So the items below would really go somethi= ng > like: > > > 1: cl to as - give me a, b, c > 2: as to cl - to get that, give me x, y, or z (and one or more of these > can be =E2=80=9Cinteract with the user=E2=80=9D in some way) > 3: user to as - I approve a and b but not c > 4: as to cl - here=E2=80=99s a token for a and b > 5: cl to user - we didn=E2=80=99t get =E2=80=9Cc=E2=80=9D and I can=E2=80= =99t do anything for you if you > don=E2=80=99t let me have =E2=80=9Cc=E2=80=99, do you want to try that ag= ain? > 6: cl to as - give me a, b, c (but I can give you proof that I already go= t > a and b)[2] > > > So if the client didn=E2=80=99t get =E2=80=9Cc=E2=80=9D but really really= needs =E2=80=9Cc=E2=80=9D, that=E2=80=99s an > error from the client=E2=80=99s perspective but I don=E2=80=99t see it as= an error from the > protocol perspective. One of the reasons that the client can=E2=80=99t ju= st mark > =E2=80=9Cc=E2=80=9D as =E2=80=9Cessential=E2=80=9D to solve this problem = is that the client can=E2=80=99t always > know :why: it didn=E2=80=99t get =E2=80=9Cc=E2=80=9D in its ultimate toke= n, and in many cases it > can=E2=80=99t do much about it. It could have been the user didn=E2=80=99= t approve that > specific one. It could have been that the AS didn=E2=80=99t allow this pa= rticular > client to even ask for it. It could have been that the client didn=E2=80= =99t > provide the right set of information upfront (device posture or > organization affiliation credentials come to mind, which are quite separa= te > from client authentication and one big reason to get away from a =E2=80= =9Cclient > ID=E2=80=9D model, but that=E2=80=99s another point). > > Historically, when we=E2=80=99ve had protocols where the client can mark = some > claims as =E2=80=9Coptional=E2=80=9D or =E2=80=9Cessential=E2=80=9D, we p= retty much always end up with all > clients marking things as =E2=80=9Cessential=E2=80=9D when they may or ma= y not be in > reality. This makes the protocol break unnecessarily at runtime. OAuth 2= =E2=80=99s > pattern of the client asking for what it needs and getting what it gets h= as > been shown to be very robust, and I think it=E2=80=99ll be even more impo= rtant when > we=E2=80=99ve got multiple dimensions of access being specified (as per o= ur > charter). There=E2=80=99s also a whole other discussion about slitting an= d > directing tokens that this group needs to have. > > So that=E2=80=99s why my stance is that we should let the client ask for = what it > wants, deal with what it gets, and decide if it needs to bug the user and > try again or not. After all, the protocol path needs to account for :erro= r: > conditions and not just the happy path, and that is what I think is missi= ng > below. I think that (4) in the list below is really unlikely if it=E2=80= =99s just > the client being able to have some sort of =E2=80=9Cno really I insist=E2= =80=9D flag. Why > would that flag make the AS change its mind about its auth decision made = in > (2) in the list below? That decision was made in some other context, and > it=E2=80=99s not because the client didn=E2=80=99t ask hard enough. > > Additionally, I think it gets really messy really quickly when we start > letting the client specify some level of desired-ness or required-ness fo= r > the things it=E2=80=99s asking for. We end up with states like =E2=80=9CI= really want this > but I can continue without it by doing something different=E2=80=9D or = =E2=80=9CI=E2=80=99m only > asking for this ahead of time but I might not need it until later if at > all=E2=80=9D or any number of other fuzzy bits in between the =E2=80=9Ces= sential/optional=E2=80=9D > false binary. Therefore I think this protocol should allow exactly one > class of resource request :and: make the behavior consistent and > predictable across it. The means the ideas of what returns an error, what > returns with less than what is asked for, or what other options are at th= e > AS=E2=80=99s disposal and what the client can do with them. I think by ha= ving a > consistent behavior :and: having the ability to do step-up requests (crea= te > a new token request built on an existing one) are going to be key for > solving this in a real and interoperable fashion, without making things > needlessly complicated in ways that don=E2=80=99t solve our problems. > > =E2=80=94 Justin > > [1] https://www.thesaurus.com/browse/negotiation?s=3Dt > > [2] At least, this is a design feature of the XYZ protocol, and I think > it=E2=80=99s important to be able to build requests on top of each other. > > On Jun 5, 2020, at 6:55 PM, Tom Jones > wrote: > > if it is to be a negotiation - irrespective of the user's direct > involvement, then then I see this sort of flow > 1 cl to as - give me a, b c > 2 as to cl - here is a grant to a > 3 cl to as - no, i really need b or i can't let you in > 4 as to cl - here is a grant to a, b > of course an alternate is that might be > 1 cl to as i want a, b, c and b is essential (I know justin hates that - > but california law requires it) > > That is what i think negotiation is, or is some other kind of negotiation > imagined > > Peace ..tom > > > On Fri, Jun 5, 2020 at 3:36 PM Dick Hardt wrote: > >> Hi Tom >> >> The charter is here https://datatracker..ietf.org/wg/txauth/about/ >> >> >> As I understand it, one of the items we are standardizing >> is negotiation protocol between the client and the server. How the serve= r >> gathers consent from the user is currently not in scope, and it is not >> clear to me what could be standardized in the experience between the use= r >> and the server that would be in scope for the IETF. Similarly for consen= t >> revocation. Additionally, a user may not be involved in the >> negotiation process at all. >> >> >> >> =E1=90=A7 >> >> On Fri, Jun 5, 2020 at 1:59 PM Tom Jones >> wrote: >> >>> Before we settle on this name, I must ask if the work group is prepared >>> for the creation of a negotiation protocol, which as I understand it wi= ll >>> include the client asking for grants, the user responding with their in= tent >>> (potentially either can start the flow) and the grant jwt (jose, whatev= er). >>> Presumably to complete the lifecycle some means for the user to revoke = the >>> grants and query the grants would also be provided. >>> >>> That seems like more of an integrated solution than prior work efforts >>> have involved. >>> What is the current status of the charter? >>> Peace ..tom >>> >>> >>> On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer >>> wrote: >>> >>>> Thank you to all who participated in the two rounds of name selection. >>>> This process has been longer than we ever expected, and I=E2=80=99m gl= ad we can >>>> declare consensus now and move forward. >>>> >>>> Based on the last two weeks=E2=80=99 worth of discussion, we have roug= h >>>> consensus on a name for the proposed working group: >>>> >>>> GNAP: Grant Negotiation and Authorization Protocol >>>> >>>> This decision will now enable our AD to put our charter [1] on the >>>> IESG's table, where I hope we will be approved as a working group. >>>> >>>> Heads up: we intend to meet in the upcoming all-virtual IETF 108 in >>>> late July, either as a BoF or as a newly chartered WG. >>>> >>>> Thanks, >>>> Yaron >>>> >>>> >>>> [1] https://datatracker.ietf.org/doc/charter-ietf-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 >>> >> -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000ea3d8505a7815207 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe what you say is reflectively true. It is, howev= er, now, or soon to be, illegal. I prefer to be ready for the future, rathe= r than be surprised by it.

Wha= t I have been looking for is something like scope, or purpose, that can be = requested by the client for approval by the user. I suspect that will only = work in constrained federations, like healthcare, where a taxonomy of purpo= ses can be created.

My n= eeds appear to be out of scope of this committee, so I have left it.
thx ..Tom (mobile)

On Sun, Jun 7, 2020, 8:48 AM Justin Richer <jricher@mit.edu> wrote:
Hi Tom,

The word =E2=80=9Cnegotiation=E2=80=9D in th= e new name is a synonym of =E2=80=9Ctransaction=E2=80=9D[1] in the sense th= at we=E2=80=99re using it. The negotiation isn=E2=80=99t quite what you=E2= =80=99re outlining below, but it does start between the client and the AS. = What is really happening is the client is requesting something, and the AS = is telling the client what it needs to provide, either directly or through = the user, to fulfill that request. So the items below would really go somet= hing like:


1: cl to as - give me a,= b, c
2: as to cl - to get that, give me x, y, or z (and one or m= ore of these can be =E2=80=9Cinteract with the user=E2=80=9D in some way)
3: user to as - I approve a and b but not c
4: as to cl = - here=E2=80=99s a token for a and b
5: cl to user - we didn=E2= =80=99t get =E2=80=9Cc=E2=80=9D and I can=E2=80=99t do anything for you if = you don=E2=80=99t let me have =E2=80=9Cc=E2=80=99, do you want to try that = again?
6: cl to as - give me a, b, c (but I can give you proof th= at I already got a and b)[2]


So if = the client didn=E2=80=99t get =E2=80=9Cc=E2=80=9D but really really needs = =E2=80=9Cc=E2=80=9D, that=E2=80=99s an error from the client=E2=80=99s pers= pective but I don=E2=80=99t see it as an error from the protocol perspectiv= e. One of the reasons that the client can=E2=80=99t just mark =E2=80=9Cc=E2= =80=9D as =E2=80=9Cessential=E2=80=9D to solve this problem is that the cli= ent can=E2=80=99t always know :why: it didn=E2=80=99t get =E2=80=9Cc=E2=80= =9D in its ultimate token, and in many cases it can=E2=80=99t do much about= it. It could have been the user didn=E2=80=99t approve that specific one. = It could have been that the AS didn=E2=80=99t allow this particular client = to even ask for it. It could have been that the client didn=E2=80=99t provi= de the right set of information upfront (device posture or organization aff= iliation credentials come to mind, which are quite separate from client aut= hentication and one big reason to get away from a =E2=80=9Cclient ID=E2=80= =9D model, but that=E2=80=99s another point).=C2=A0

Historically, when we=E2=80=99ve had protocols where the client can mark = some claims as =E2=80=9Coptional=E2=80=9D or =E2=80=9Cessential=E2=80=9D, w= e pretty much always end up with all clients marking things as =E2=80=9Cess= ential=E2=80=9D when they may or may not be in reality. This makes the prot= ocol break unnecessarily at runtime. OAuth 2=E2=80=99s pattern of the clien= t asking for what it needs and getting what it gets has been shown to be ve= ry robust, and I think it=E2=80=99ll be even more important when we=E2=80= =99ve got multiple dimensions of access being specified (as per our charter= ). There=E2=80=99s also a whole other discussion about slitting and directi= ng tokens that this group needs to have.=C2=A0

So = that=E2=80=99s why my stance is that we should let the client ask for what = it wants, deal with what it gets, and decide if it needs to bug the user an= d try again or not. After all, the protocol path needs to account for :erro= r: conditions and not just the happy path, and that is what I think is miss= ing below. I think that (4) in the list below is really unlikely if it=E2= =80=99s just the client being able to have some sort of =E2=80=9Cno really = I insist=E2=80=9D flag. Why would that flag make the AS change its mind abo= ut its auth decision made in (2) in the list below? That decision was made = in some other context, and it=E2=80=99s not because the client didn=E2=80= =99t ask hard enough.

Additionally, I think it get= s really messy really quickly when we start letting the client specify some= level of desired-ness or required-ness for the things it=E2=80=99s asking = for. We end up with states like =E2=80=9CI really want this but I can conti= nue without it by doing something different=E2=80=9D or =E2=80=9CI=E2=80=99= m only asking for this ahead of time but I might not need it until later if= at all=E2=80=9D or any number of other fuzzy bits in between the =E2=80=9C= essential/optional=E2=80=9D false binary. Therefore I think this protocol s= hould allow exactly one class of resource request :and: make the behavior c= onsistent and predictable across it. The means the ideas of what returns an= error, what returns with less than what is asked for, or what other option= s are at the AS=E2=80=99s disposal and what the client can do with them. I = think by having a consistent behavior :and: having the ability to do step-u= p requests (create a new token request built on an existing one) are going = to be key for solving this in a real and interoperable fashion, without mak= ing things needlessly complicated in ways that don=E2=80=99t solve our prob= lems.

=C2=A0=E2=80=94 Justin

<= div>[1]=C2=A0https://www.thesaurus.com/browse/nego= tiation?s=3Dt

[2] At least, this is a design f= eature of the XYZ protocol, and I think it=E2=80=99s important to be able t= o build requests on top of each other.

On Jun 5, 2020, at 6:55 PM, Tom Jones <thomasclinganjon= es@gmail.com> wrote:

if it is to be a= negotiation - irrespective of the user's direct involvement, then then= I see this sort of flow
1 cl to as - give me a, b c
2 as to = cl - here is a grant to a
3 cl to as - no, i really need b or i c= an't let you in
4 as to cl - here is a grant to a, b
of course an alternate is that might be
1 cl to as i want a, b,= c and b is essential (I know justin hates that - but california law requir= es it)

That is what=C2=A0i think negotiation is, o= r is some other kind of negotiation imagined

Peace ..tom


On Fri, Jun 5, 2020 at 3:36 = PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Tom


As I understand it, one of the items = we are standardizing is=C2=A0negotiation=C2=A0protocol between the client a= nd the server. How the server gathers consent from the user is currently no= t in scope, and it is not clear to me what could be standardized in the exp= erience between the user and the server that would be in scope for the IETF= . Similarly for consent revocation. Additionally, a user may not be involve= d in the negotiation=C2=A0process at all.



3D""=E1=90=A7

On Fri, Jun 5, 2020 at 1:59= PM Tom Jones <thomasclinganjones@gmail.com> wrote:
=
Be= fore we settle on this name, I must ask if the work group is prepared for t= he creation of a negotiation protocol, which as I understand it will includ= e the client asking for grants, the user responding with their intent (pote= ntially either can start the flow) and the grant jwt (jose, whatever). Pres= umably to complete the lifecycle some means for the user to revoke the gran= ts and query=C2=A0the grants would also be provided.

Tha= t seems like more of an integrated solution than prior work efforts have in= volved.
What is the current status of the charter?
Peace ..tom


On Fri, Jun 5, 2020 at 1:35 PM Yaron Sheffer <yaro= nf.ietf@gmail.com> wrote:
Thank you to all who participated in the two rounds of nam= e selection. This process has been longer than we ever expected, and I=E2= =80=99m glad we can declare consensus now and move forward.

Based on the last two weeks=E2=80=99 worth of discussion, we have rough con= sensus on a name for the proposed working group:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 GNAP: Grant Negotiation and Authorization Proto= col

This decision will now enable our AD to put our charter [1] on the IESG'= ;s table, where I hope we will be approved as a working group.

Heads up: we intend to meet in the upcoming all-virtual IETF 108 in late Ju= ly, either as a BoF or as a newly chartered WG.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


[1] https://datatracker.ietf.org/d= oc/charter-ietf-txauth/


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

= --000000000000ea3d8505a7815207-- From nobody Sun Jun 7 12:28:11 2020 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 33AE33A0854 for ; Sun, 7 Jun 2020 12:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 S8PLT5tKV7ai for ; Sun, 7 Jun 2020 12:28:08 -0700 (PDT) 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 E9A093A0853 for ; Sun, 7 Jun 2020 12:28:07 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id d7so8883132lfi.12 for ; Sun, 07 Jun 2020 12:28:07 -0700 (PDT) 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=kCk3SXftkBLihIOoskYM4va5cXf5S8uUaHALe3v+WrM=; b=H598OxEE0LoB96rk6IhBL31Cbw6Hi4pnnruko2nStR4XH80uOntxtcLzwNahT8Wsh+ ug7FH9Rk5AH0wZKJLFlLzCRLE+G0Kuy3lpKIUMcgdT/ujadGuxR14KelcenbnQOxwNTb 37AeVqu8mUfHMOdsC3raKey9tQgrGCxwHcB3F/GSU7/cFG7MrL/Zj1WyBlHEkiW3maUG m/Hbax1lKCw5OAB9A4aT0fKJ3/BADXxZ5AWL0PZj55bPuqwnLFpMMGJ5SRbKCuOQMP3Q 3uLCeTwlAVTkgxQwhWS5+CPMJa6+Og3tGgHLHLb16iJ/S2BTuenet9DxTB4rxSNB0ptn vx+w== 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=kCk3SXftkBLihIOoskYM4va5cXf5S8uUaHALe3v+WrM=; b=fY9Bz210Ceqjkg/IK1dK2BSvteoJS+3DeuplixZo4fyH+bemKiV9/U4mdVuOvz1Db3 ftTpRCzE1R95F1kIQhVJKjdndTvnxBwUGuhEvdjKo4PU3IwT8KoD4kLtQGj0cBY80PYs UYPCAPAjoFXggeRTzjH5Ii1Pnk8KPv5Fr5963BDHL74Vz3qr7DZZaHc4VzI2dv2sSbpl aAMg9uAKnjaCt4NMAUgrPYViZiwFReiR6MpNtFUZzTRAdbAU2vBh4YkO2SyGJW+LV7CR leSdXaPwUfZy5VFtyN+o4hd7cUcFZWdwy0hcLYFEoKx6t3ScsI3b47B/RY8CNdwEY2RN h4BQ== X-Gm-Message-State: AOAM533UQOHouPr61JvEvM3+OkOMZpxIlW+MQWGDE0iHPJvw/darp6Ar clw0Etbno8In7LhHYT/NKWTQDUU+peHjufV65IZ8zVk/rxo= X-Google-Smtp-Source: ABdhPJw6rMiToWf5+mlWDtPbtpL8VcDvB81C7qaS4DDAA1QxZTD68F3f3H6E+28HVhT+JdzoWa8zBNCrGo2dzUGEUzg= X-Received: by 2002:a19:8453:: with SMTP id g80mr10888737lfd.167.1591558085544; Sun, 07 Jun 2020 12:28:05 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Sun, 7 Jun 2020 12:27:39 -0700 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000540dc505a7837ec3" Archived-At: Subject: [Txauth] XYZ-08 vs XAuth-08 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, 07 Jun 2020 19:28:10 -0000 --000000000000540dc505a7837ec3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello I have just posed some updates on the XAuth draft: In -07 I added the XYZ features of interaction negotiation, and a Client Handle for dynamic clients. I also updated the name to GNAP, but preserved the draft-hardt-xauth-protocol filename for ease of tracking changes. In -08 I split the doc into: core protocol, advanced features, and JOSE authentication. https://www.ietf.org/id/draft-hardt-xauth-protocol-08.html https://www.ietf.org/id/draft-hardt-gnap-advanced-00.html https://www.ietf.org/id/draft-hardt-gnap-jose-00.html IMHO, the main doc is much more readable. :) *XYZ vs XAuth* The remaining major differences between XYZ and XAuth are areas I have concerns about. (I will continue to use XYZ and XAuth refer to each draft). The concerns are: *1) API in JSON vs URI and HTTP Verb* In XYZ, all calls are to the same endpoint as an HTTP POST. The AS must parse the JSON to determine what to do. XAuth has a RESTful interface. A Grant Request starts at the GS URI, and Grants and Authorizations are returned as URI resources. Creating a Grant is done with a POST, reading a Grant is done with a GET. With URIs and HTTP verbs, A large scale GS can easily implement independent services for each functionality as routing of requests can be done at the HTTP layer based on the URI and HTTP verb. This allows a separation of concerns, independent deployment, and resiliency. *2) Handles for all Clients vs Client ID and Client Handle* In XYZ, both pre-registered clients and dynamic clients use a handle. In XAuth, the Client ID refers to a pre-registered client, and the Client Handle is specific to an instance of a dynamic client. Using separate terms clearly differentiates which identifier is being presented to the GS. This allows a GS to use separate mechanisms for managing pre-registered clients and dynamic clients, an important consideration as there can easily be millions of instances of a single dynamic client. Additionally, developers are already familiar with what a Client ID is for pre-registered clients. *3) Transaction Handles are One Time Use* In XYZ, transaction handles are one time use [1]. In the OAuth WG discussion on one time use refresh tokens, clients are often distributed across components, which complicates one time use references. One time use transaction handles also makes them inconsistent with the display, resource, user, and key handles. *4) New User Identifier* XYZ introduces a new identifier for the user, a User Handle. Unclear why a new type of user identifier is needed, except for the desire to have a handle for everything. *5) Interaction Capabilities vs Modes* In XYZ, the capabilities are expressed by the client, and the GS states which capabilities it will accept. This can make it difficult for the GS to enforce the interaction choices as the client can mix and match which capabilities are returned. For example, a GS may not want to support a redirect without a callback to protect itself from session fixation attacks. In XAuth, the interaction modes provide clarity on the mode of interaction and the security properties. For example the GS may support both user_code and redirect modes, but not the indirect mode which is subject to session fixation attacks. *6) Claims at Top Level vs Namespaced * In XYZ, there is one schema for claims, and they are requested as: "claims": { "subject": true, "email": true } Whereas in XAuth, claims are in their own namespace: "claims": { "oidc": { "id_token" : { "email" : { "essential" : true }, "email_verified" : { "essential" : true } }, "userinfo" : { "name" : { "essential" : true }, "picture" : null } } In this example, the client is requesting OIDC defined claims, the email to be in an ID Token, and the name and picture to be as text. While the XYZ schema may be extended, there are already numerous schemas being used. The XAuth approach is to support existing and new schemas, rather than pick one and/or create another one, and allows a Grant Request to contain claims from multiple schemas at the same time. *7) No Authorization Type* Similar to (6), XYZ has a single schema for how to request access to a resource. While that schema is extensible, it requires adaption from any system with an existing schema. XAuth has a type for each authorization request (oauth2, rar), allowing existing schemas and new schemas to be supported. *Summary* While concerns (3-7) can be addressed in XYZ, (1-2) look fundamental to the XYZ architecture. [1] https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-7 [2] https://w3c.github.io/vc-data-model/ =E1=90=A7 --000000000000540dc505a7837ec3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello

I have just posed some= updates on the XAuth draft:

In -07 I added the XY= Z features of interaction negotiation, and a Client Handle for dynamic clie= nts. I also updated the name to GNAP, but preserved the draft-hardt-xauth-p= rotocol filename for ease of tracking changes.=C2=A0

In -08 I split the doc into: core protocol, advanced features, and JOSE = authentication.=C2=A0


IMHO, the main doc is much more= readable. :)


XYZ vs = XAuth

The remaining major differences between = XYZ and XAuth are areas I have concerns about. (I will continue to use XYZ = and XAuth refer to each draft). The concerns are:

= 1) API in JSON vs URI and HTTP Verb

= In XYZ, all calls are to the same endpoint=C2=A0as an HTTP POST. The AS mus= t parse the JSON to determine what to do.=C2=A0

XA= uth has a RESTful interface. A Grant=C2=A0Request starts at the GS URI, and= Grants and Authorizations are returned as URI resources. Creating a Grant = is done with a POST, reading a Grant is done with a GET.=C2=A0

With URIs and HTTP verbs, A large scale GS can easily implement indep= endent services for=C2=A0each=C2=A0 functionality as routing of requests ca= n be done at the HTTP layer based on the URI and HTTP verb. This allows a s= eparation of concerns, independent deployment, and resiliency.
2) Handles for all Clients vs Client ID and Client Handle

In XYZ, both pre-registered clients and dynamic cli= ents use a handle.=C2=A0

In XAuth, the Client ID r= efers to a pre-registered client, and the Client Handle is specific to an i= nstance of a dynamic client. Using separate terms clearly differentiates wh= ich identifier is being presented to the GS.=C2=A0

This allows a GS to use separate mechanisms for managing pre-registered cl= ients and dynamic clients, an important consideration as there can easily b= e millions of instances of a single dynamic client.

Additionally, developers are already familiar=C2=A0with what a Client= ID is for pre-registered clients.

3) Transact= ion Handles are One Time Use

In XYZ, tr= ansaction handles are one time use [1]. In the OAuth WG discussion on one t= ime use refresh tokens, clients are often distributed across components, wh= ich complicates one time use references.=C2=A0

One= time use transaction handles also makes them inconsistent with the display= , resource, user, and key handles.

4) New User = Identifier

XYZ introduces a new identifier for= the user, a User Handle. Unclear why a new type of user identifier is need= ed, except for the desire to have a handle for everything.

5) Interaction Capabilities vs Modes

In XYZ, the capabilities are expressed by the client, a= nd the GS states which capabilities it will accept. This can make it diffic= ult for the GS to enforce the interaction choices as the client can mix and= match which capabilities are returned. For example, a GS may not want to s= upport a redirect without a callback to protect itself from session fixatio= n attacks. In XAuth, the interaction modes provide clarity on the mode of i= nteraction and the security properties. For example the GS may support both= user_code and redirect modes, but not the indirect mode which is subject t= o session fixation attacks.

6) Claims at= Top Level vs Namespaced=C2=A0

In X= YZ, there is one schema for claims, and they are requested as:
=C2=A0 =C2=A0"claims": {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0"subject": true,
=C2=A0 =C2=A0 =C2=A0 =C2=A0"email&quo= t;: true
=C2=A0 =C2=A0}

Whereas in XAuth, c= laims are in their own namespace:

=C2=A0 =C2=A0 &q= uot;claims": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "oidc": {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id_token" : {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "email" =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "essential" : true },
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "email_verified&q= uot; : { "essential" : true }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "userinfo&q= uot; : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "n= ame" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : { "essential" : tr= ue },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "pict= ure" =C2=A0 =C2=A0 =C2=A0 =C2=A0: null
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

<= /div>
In this example, the client is requesting OIDC defined claims, th= e email to be in an ID Token, and the name and picture to be as text. While= the XYZ schema may be extended, there are already numerous schemas being u= sed. The XAuth approach is to support existing and new schemas,=C2=A0rather= than pick one and/or create another one, and allows a Grant Request to con= tain claims from multiple schemas at the same time.

7) No Authorization Type

Similar to (= 6), XYZ has a single schema for how to request access to a resource. While = that schema is extensible, it requires adaption=C2=A0from any system with a= n existing schema. XAuth has a type for each authorization request (oauth2,= rar), allowing existing schemas and new schemas to be supported.

Summary

While concerns (3-7= ) can be addressed in XYZ, (1-2)=C2=A0look fundamental to the XYZ architect= ure.


[2]=C2=A0https://w3c.gi= thub.io/vc-data-model/

3D""=E1=90=A7
--000000000000540dc505a7837ec3-- From nobody Sun Jun 7 12:40:16 2020 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 1C3143A0872 for ; Sun, 7 Jun 2020 12:40:15 -0700 (PDT) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 AL9jziZI6JXZ for ; Sun, 7 Jun 2020 12:40:13 -0700 (PDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDFAD3A086E for ; Sun, 7 Jun 2020 12:40:12 -0700 (PDT) Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-1.mit.edu (8.14.7/8.12.4) with ESMTP id 057JdO6J023491; Sun, 7 Jun 2020 15:39:29 -0400 Received: from w92expo18.exchange.mit.edu (18.7.74.72) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 7 Jun 2020 15:39:23 -0400 Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo18.exchange.mit.edu (18.7.74.72) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sun, 7 Jun 2020 15:40:07 -0400 Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Sun, 7 Jun 2020 15:40:07 -0400 From: Justin Richer To: Tom Jones CC: Dick Hardt , Yaron Sheffer , "txauth@ietf.org" Thread-Topic: [Txauth] Working group name Thread-Index: AQHWO3jYuGz9oT4Qi0+Th4Tw4yMNqqjKxHwAgAAbEwCAAAU+AIACakwAgABVGAD//+okpg== Date: Sun, 7 Jun 2020 19:40:07 +0000 Message-ID: References: <2626827D-194C-4BA7-A62C-22387942B571@gmail.com> <9690012E-5B57-4C1D-BF26-13E30B3DA23C@mit.edu>, 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 x-originating-ip: [172.58.221.144] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Working group name 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, 07 Jun 2020 19:40:15 -0000 DQpUb20sIA0KDQpJIHRoaW5rIHRoYXQgYSBsb3Qgb2YgdGhlIGNvbnN0cmFpbnRzIHRoYXQgeW91 J3JlIGRlc2NyaWJpbmcgYXJlIGdvaW5nIHRvIGJlIHNwZWNpZmljIHRvIHRoZSBBUEliZWluZyBw cm90ZWN0ZWQsIG9yIGF0IGxlYXN0IHRoZSB2ZXJ0aWNhbCB0aGF0IHRoZXkgZXhpc3QgaW4uIEl0 J3MgaW1wb3J0YW50IHRoYXQgYSBnZW5lcmFsIHB1cnBvc2UgcHJvdG9jb2wgbGlrZSB0aGlzIGFs bG93IGFuZCBlbmFibGUgdGhhdCBraW5kIG9mIGNvbnN0cmFpbnQgd2l0aG91dCBuZWNlc3Nhcmls eSBpbXBvc2luZyBpdCBvbiBvdGhlciBjYXNlcyB3aGVyZSBpdCBkb2Vzbid0IG1ha2Ugc2Vuc2Uu IFRoZSBraW5kIG9mIGVzc2VudGlhbCBwb2xpY3kgaXMgcHJvYmFibHkga25vd24gdG8gdGhlIEFT IGFuZCBpdCBzaG91bGQgYmUgYWJsZSB0byBhcHBseSBpdCB0byB0aGUgcmVxdWVzdCBhcyBuZWVk ZWQuIFRoZSBjbGllbnQgc2hvdWxkIGFsc28gYmUgYWJsZSB0byBleHBlY3QgcHJlZGljdGFibGUg YmVoYXZpb3IgaW4gdGhpcyBjYXNlLiBTbyB0byBtZSwgaXQgbWFrZXMgbW9yZSBzZW5zZSB0aGF0 IHRoaXMgYmUgaW4gYSBwcm9maWxlIGZyb20gYSBncm91cCBsaWtlIEhFQVJULiANCg0KSGVhbHRo Y2FyZSBpcyBhIHZpdGFsbHkgaW1wb3J0YW50IGFyZWEgdGhhdCB0aGlzIHdvcmsgd2lsbCBiZSB1 c2VkIGluLCBhbmQgc28gSSBob3BlIHRoYXQgeW91IHdpbGwgY29udGludWUgdG8gam9pbiB0aGlz IGNvbnZlcnNhdGlvbiBhbmQgY29udHJpYnV0ZSB5b3VyIGV4cGVydGlzZS4gDQoNCi0gSnVzdGlu DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBUb20gSm9u ZXMgW3Rob21hc2NsaW5nYW5qb25lc0BnbWFpbC5jb21dDQpTZW50OiBTdW5kYXksIEp1bmUgNywg MjAyMCAxMjo1MiBQTQ0KVG86IEp1c3RpbiBSaWNoZXINCkNjOiBEaWNrIEhhcmR0OyBZYXJvbiBT aGVmZmVyOyB0eGF1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBXb3JraW5nIGdy b3VwIG5hbWUNCg0KSSBiZWxpZXZlIHdoYXQgeW91IHNheSBpcyByZWZsZWN0aXZlbHkgdHJ1ZS4g SXQgaXMsIGhvd2V2ZXIsIG5vdywgb3Igc29vbiB0byBiZSwgaWxsZWdhbC4gSSBwcmVmZXIgdG8g YmUgcmVhZHkgZm9yIHRoZSBmdXR1cmUsIHJhdGhlciB0aGFuIGJlIHN1cnByaXNlZCBieSBpdC4N Cg0KV2hhdCBJIGhhdmUgYmVlbiBsb29raW5nIGZvciBpcyBzb21ldGhpbmcgbGlrZSBzY29wZSwg b3IgcHVycG9zZSwgdGhhdCBjYW4gYmUgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQgZm9yIGFwcHJv dmFsIGJ5IHRoZSB1c2VyLiBJIHN1c3BlY3QgdGhhdCB3aWxsIG9ubHkgd29yayBpbiBjb25zdHJh aW5lZCBmZWRlcmF0aW9ucywgbGlrZSBoZWFsdGhjYXJlLCB3aGVyZSBhIHRheG9ub215IG9mIHB1 cnBvc2VzIGNhbiBiZSBjcmVhdGVkLg0KDQpNeSBuZWVkcyBhcHBlYXIgdG8gYmUgb3V0IG9mIHNj b3BlIG9mIHRoaXMgY29tbWl0dGVlLCBzbyBJIGhhdmUgbGVmdCBpdC4NCg0KdGh4IC4uVG9tICht b2JpbGUpDQoNCk9uIFN1biwgSnVuIDcsIDIwMjAsIDg6NDggQU0gSnVzdGluIFJpY2hlciA8anJp Y2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCkhpIFRvbSwNCg0K VGhlIHdvcmQg4oCcbmVnb3RpYXRpb27igJ0gaW4gdGhlIG5ldyBuYW1lIGlzIGEgc3lub255bSBv ZiDigJx0cmFuc2FjdGlvbuKAnVsxXSBpbiB0aGUgc2Vuc2UgdGhhdCB3ZeKAmXJlIHVzaW5nIGl0 LiBUaGUgbmVnb3RpYXRpb24gaXNu4oCZdCBxdWl0ZSB3aGF0IHlvdeKAmXJlIG91dGxpbmluZyBi ZWxvdywgYnV0IGl0IGRvZXMgc3RhcnQgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgQVMuIFdo YXQgaXMgcmVhbGx5IGhhcHBlbmluZyBpcyB0aGUgY2xpZW50IGlzIHJlcXVlc3Rpbmcgc29tZXRo aW5nLCBhbmQgdGhlIEFTIGlzIHRlbGxpbmcgdGhlIGNsaWVudCB3aGF0IGl0IG5lZWRzIHRvIHBy b3ZpZGUsIGVpdGhlciBkaXJlY3RseSBvciB0aHJvdWdoIHRoZSB1c2VyLCB0byBmdWxmaWxsIHRo YXQgcmVxdWVzdC4gU28gdGhlIGl0ZW1zIGJlbG93IHdvdWxkIHJlYWxseSBnbyBzb21ldGhpbmcg bGlrZToNCg0KDQoxOiBjbCB0byBhcyAtIGdpdmUgbWUgYSwgYiwgYw0KMjogYXMgdG8gY2wgLSB0 byBnZXQgdGhhdCwgZ2l2ZSBtZSB4LCB5LCBvciB6IChhbmQgb25lIG9yIG1vcmUgb2YgdGhlc2Ug Y2FuIGJlIOKAnGludGVyYWN0IHdpdGggdGhlIHVzZXLigJ0gaW4gc29tZSB3YXkpDQozOiB1c2Vy IHRvIGFzIC0gSSBhcHByb3ZlIGEgYW5kIGIgYnV0IG5vdCBjDQo0OiBhcyB0byBjbCAtIGhlcmXi gJlzIGEgdG9rZW4gZm9yIGEgYW5kIGINCjU6IGNsIHRvIHVzZXIgLSB3ZSBkaWRu4oCZdCBnZXQg 4oCcY+KAnSBhbmQgSSBjYW7igJl0IGRvIGFueXRoaW5nIGZvciB5b3UgaWYgeW91IGRvbuKAmXQg bGV0IG1lIGhhdmUg4oCcY+KAmSwgZG8geW91IHdhbnQgdG8gdHJ5IHRoYXQgYWdhaW4/DQo2OiBj bCB0byBhcyAtIGdpdmUgbWUgYSwgYiwgYyAoYnV0IEkgY2FuIGdpdmUgeW91IHByb29mIHRoYXQg SSBhbHJlYWR5IGdvdCBhIGFuZCBiKVsyXQ0KDQoNClNvIGlmIHRoZSBjbGllbnQgZGlkbuKAmXQg Z2V0IOKAnGPigJ0gYnV0IHJlYWxseSByZWFsbHkgbmVlZHMg4oCcY+KAnSwgdGhhdOKAmXMgYW4g ZXJyb3IgZnJvbSB0aGUgY2xpZW504oCZcyBwZXJzcGVjdGl2ZSBidXQgSSBkb27igJl0IHNlZSBp dCBhcyBhbiBlcnJvciBmcm9tIHRoZSBwcm90b2NvbCBwZXJzcGVjdGl2ZS4gT25lIG9mIHRoZSBy ZWFzb25zIHRoYXQgdGhlIGNsaWVudCBjYW7igJl0IGp1c3QgbWFyayDigJxj4oCdIGFzIOKAnGVz c2VudGlhbOKAnSB0byBzb2x2ZSB0aGlzIHByb2JsZW0gaXMgdGhhdCB0aGUgY2xpZW50IGNhbuKA mXQgYWx3YXlzIGtub3cgOndoeTogaXQgZGlkbuKAmXQgZ2V0IOKAnGPigJ0gaW4gaXRzIHVsdGlt YXRlIHRva2VuLCBhbmQgaW4gbWFueSBjYXNlcyBpdCBjYW7igJl0IGRvIG11Y2ggYWJvdXQgaXQu IEl0IGNvdWxkIGhhdmUgYmVlbiB0aGUgdXNlciBkaWRu4oCZdCBhcHByb3ZlIHRoYXQgc3BlY2lm aWMgb25lLiBJdCBjb3VsZCBoYXZlIGJlZW4gdGhhdCB0aGUgQVMgZGlkbuKAmXQgYWxsb3cgdGhp cyBwYXJ0aWN1bGFyIGNsaWVudCB0byBldmVuIGFzayBmb3IgaXQuIEl0IGNvdWxkIGhhdmUgYmVl biB0aGF0IHRoZSBjbGllbnQgZGlkbuKAmXQgcHJvdmlkZSB0aGUgcmlnaHQgc2V0IG9mIGluZm9y bWF0aW9uIHVwZnJvbnQgKGRldmljZSBwb3N0dXJlIG9yIG9yZ2FuaXphdGlvbiBhZmZpbGlhdGlv biBjcmVkZW50aWFscyBjb21lIHRvIG1pbmQsIHdoaWNoIGFyZSBxdWl0ZSBzZXBhcmF0ZSBmcm9t IGNsaWVudCBhdXRoZW50aWNhdGlvbiBhbmQgb25lIGJpZyByZWFzb24gdG8gZ2V0IGF3YXkgZnJv bSBhIOKAnGNsaWVudCBJROKAnSBtb2RlbCwgYnV0IHRoYXTigJlzIGFub3RoZXIgcG9pbnQpLg0K DQpIaXN0b3JpY2FsbHksIHdoZW4gd2XigJl2ZSBoYWQgcHJvdG9jb2xzIHdoZXJlIHRoZSBjbGll bnQgY2FuIG1hcmsgc29tZSBjbGFpbXMgYXMg4oCcb3B0aW9uYWzigJ0gb3Ig4oCcZXNzZW50aWFs 4oCdLCB3ZSBwcmV0dHkgbXVjaCBhbHdheXMgZW5kIHVwIHdpdGggYWxsIGNsaWVudHMgbWFya2lu ZyB0aGluZ3MgYXMg4oCcZXNzZW50aWFs4oCdIHdoZW4gdGhleSBtYXkgb3IgbWF5IG5vdCBiZSBp biByZWFsaXR5LiBUaGlzIG1ha2VzIHRoZSBwcm90b2NvbCBicmVhayB1bm5lY2Vzc2FyaWx5IGF0 IHJ1bnRpbWUuIE9BdXRoIDLigJlzIHBhdHRlcm4gb2YgdGhlIGNsaWVudCBhc2tpbmcgZm9yIHdo YXQgaXQgbmVlZHMgYW5kIGdldHRpbmcgd2hhdCBpdCBnZXRzIGhhcyBiZWVuIHNob3duIHRvIGJl IHZlcnkgcm9idXN0LCBhbmQgSSB0aGluayBpdOKAmWxsIGJlIGV2ZW4gbW9yZSBpbXBvcnRhbnQg d2hlbiB3ZeKAmXZlIGdvdCBtdWx0aXBsZSBkaW1lbnNpb25zIG9mIGFjY2VzcyBiZWluZyBzcGVj aWZpZWQgKGFzIHBlciBvdXIgY2hhcnRlcikuIFRoZXJl4oCZcyBhbHNvIGEgd2hvbGUgb3RoZXIg ZGlzY3Vzc2lvbiBhYm91dCBzbGl0dGluZyBhbmQgZGlyZWN0aW5nIHRva2VucyB0aGF0IHRoaXMg Z3JvdXAgbmVlZHMgdG8gaGF2ZS4NCg0KU28gdGhhdOKAmXMgd2h5IG15IHN0YW5jZSBpcyB0aGF0 IHdlIHNob3VsZCBsZXQgdGhlIGNsaWVudCBhc2sgZm9yIHdoYXQgaXQgd2FudHMsIGRlYWwgd2l0 aCB3aGF0IGl0IGdldHMsIGFuZCBkZWNpZGUgaWYgaXQgbmVlZHMgdG8gYnVnIHRoZSB1c2VyIGFu ZCB0cnkgYWdhaW4gb3Igbm90LiBBZnRlciBhbGwsIHRoZSBwcm90b2NvbCBwYXRoIG5lZWRzIHRv IGFjY291bnQgZm9yIDplcnJvcjogY29uZGl0aW9ucyBhbmQgbm90IGp1c3QgdGhlIGhhcHB5IHBh dGgsIGFuZCB0aGF0IGlzIHdoYXQgSSB0aGluayBpcyBtaXNzaW5nIGJlbG93LiBJIHRoaW5rIHRo YXQgKDQpIGluIHRoZSBsaXN0IGJlbG93IGlzIHJlYWxseSB1bmxpa2VseSBpZiBpdOKAmXMganVz dCB0aGUgY2xpZW50IGJlaW5nIGFibGUgdG8gaGF2ZSBzb21lIHNvcnQgb2Yg4oCcbm8gcmVhbGx5 IEkgaW5zaXN04oCdIGZsYWcuIFdoeSB3b3VsZCB0aGF0IGZsYWcgbWFrZSB0aGUgQVMgY2hhbmdl IGl0cyBtaW5kIGFib3V0IGl0cyBhdXRoIGRlY2lzaW9uIG1hZGUgaW4gKDIpIGluIHRoZSBsaXN0 IGJlbG93PyBUaGF0IGRlY2lzaW9uIHdhcyBtYWRlIGluIHNvbWUgb3RoZXIgY29udGV4dCwgYW5k IGl04oCZcyBub3QgYmVjYXVzZSB0aGUgY2xpZW50IGRpZG7igJl0IGFzayBoYXJkIGVub3VnaC4N Cg0KQWRkaXRpb25hbGx5LCBJIHRoaW5rIGl0IGdldHMgcmVhbGx5IG1lc3N5IHJlYWxseSBxdWlj a2x5IHdoZW4gd2Ugc3RhcnQgbGV0dGluZyB0aGUgY2xpZW50IHNwZWNpZnkgc29tZSBsZXZlbCBv ZiBkZXNpcmVkLW5lc3Mgb3IgcmVxdWlyZWQtbmVzcyBmb3IgdGhlIHRoaW5ncyBpdOKAmXMgYXNr aW5nIGZvci4gV2UgZW5kIHVwIHdpdGggc3RhdGVzIGxpa2Ug4oCcSSByZWFsbHkgd2FudCB0aGlz IGJ1dCBJIGNhbiBjb250aW51ZSB3aXRob3V0IGl0IGJ5IGRvaW5nIHNvbWV0aGluZyBkaWZmZXJl bnTigJ0gb3Ig4oCcSeKAmW0gb25seSBhc2tpbmcgZm9yIHRoaXMgYWhlYWQgb2YgdGltZSBidXQg SSBtaWdodCBub3QgbmVlZCBpdCB1bnRpbCBsYXRlciBpZiBhdCBhbGzigJ0gb3IgYW55IG51bWJl ciBvZiBvdGhlciBmdXp6eSBiaXRzIGluIGJldHdlZW4gdGhlIOKAnGVzc2VudGlhbC9vcHRpb25h bOKAnSBmYWxzZSBiaW5hcnkuIFRoZXJlZm9yZSBJIHRoaW5rIHRoaXMgcHJvdG9jb2wgc2hvdWxk IGFsbG93IGV4YWN0bHkgb25lIGNsYXNzIG9mIHJlc291cmNlIHJlcXVlc3QgOmFuZDogbWFrZSB0 aGUgYmVoYXZpb3IgY29uc2lzdGVudCBhbmQgcHJlZGljdGFibGUgYWNyb3NzIGl0LiBUaGUgbWVh bnMgdGhlIGlkZWFzIG9mIHdoYXQgcmV0dXJucyBhbiBlcnJvciwgd2hhdCByZXR1cm5zIHdpdGgg bGVzcyB0aGFuIHdoYXQgaXMgYXNrZWQgZm9yLCBvciB3aGF0IG90aGVyIG9wdGlvbnMgYXJlIGF0 IHRoZSBBU+KAmXMgZGlzcG9zYWwgYW5kIHdoYXQgdGhlIGNsaWVudCBjYW4gZG8gd2l0aCB0aGVt LiBJIHRoaW5rIGJ5IGhhdmluZyBhIGNvbnNpc3RlbnQgYmVoYXZpb3IgOmFuZDogaGF2aW5nIHRo ZSBhYmlsaXR5IHRvIGRvIHN0ZXAtdXAgcmVxdWVzdHMgKGNyZWF0ZSBhIG5ldyB0b2tlbiByZXF1 ZXN0IGJ1aWx0IG9uIGFuIGV4aXN0aW5nIG9uZSkgYXJlIGdvaW5nIHRvIGJlIGtleSBmb3Igc29s dmluZyB0aGlzIGluIGEgcmVhbCBhbmQgaW50ZXJvcGVyYWJsZSBmYXNoaW9uLCB3aXRob3V0IG1h a2luZyB0aGluZ3MgbmVlZGxlc3NseSBjb21wbGljYXRlZCBpbiB3YXlzIHRoYXQgZG9u4oCZdCBz b2x2ZSBvdXIgcHJvYmxlbXMuDQoNCiDigJQgSnVzdGluDQoNClsxXSBodHRwczovL3d3dy50aGVz YXVydXMuY29tL2Jyb3dzZS9uZWdvdGlhdGlvbj9zPXQNCg0KWzJdIEF0IGxlYXN0LCB0aGlzIGlz IGEgZGVzaWduIGZlYXR1cmUgb2YgdGhlIFhZWiBwcm90b2NvbCwgYW5kIEkgdGhpbmsgaXTigJlz IGltcG9ydGFudCB0byBiZSBhYmxlIHRvIGJ1aWxkIHJlcXVlc3RzIG9uIHRvcCBvZiBlYWNoIG90 aGVyLg0KDQpPbiBKdW4gNSwgMjAyMCwgYXQgNjo1NSBQTSwgVG9tIEpvbmVzIDx0aG9tYXNjbGlu Z2Fuam9uZXNAZ21haWwuY29tPG1haWx0bzp0aG9tYXNjbGluZ2Fuam9uZXNAZ21haWwuY29tPj4g d3JvdGU6DQoNCmlmIGl0IGlzIHRvIGJlIGEgbmVnb3RpYXRpb24gLSBpcnJlc3BlY3RpdmUgb2Yg dGhlIHVzZXIncyBkaXJlY3QgaW52b2x2ZW1lbnQsIHRoZW4gdGhlbiBJIHNlZSB0aGlzIHNvcnQg b2YgZmxvdw0KMSBjbCB0byBhcyAtIGdpdmUgbWUgYSwgYiBjDQoyIGFzIHRvIGNsIC0gaGVyZSBp cyBhIGdyYW50IHRvIGENCjMgY2wgdG8gYXMgLSBubywgaSByZWFsbHkgbmVlZCBiIG9yIGkgY2Fu J3QgbGV0IHlvdSBpbg0KNCBhcyB0byBjbCAtIGhlcmUgaXMgYSBncmFudCB0byBhLCBiDQpvZiBj b3Vyc2UgYW4gYWx0ZXJuYXRlIGlzIHRoYXQgbWlnaHQgYmUNCjEgY2wgdG8gYXMgaSB3YW50IGEs IGIsIGMgYW5kIGIgaXMgZXNzZW50aWFsIChJIGtub3cganVzdGluIGhhdGVzIHRoYXQgLSBidXQg Y2FsaWZvcm5pYSBsYXcgcmVxdWlyZXMgaXQpDQoNClRoYXQgaXMgd2hhdCBpIHRoaW5rIG5lZ290 aWF0aW9uIGlzLCBvciBpcyBzb21lIG90aGVyIGtpbmQgb2YgbmVnb3RpYXRpb24gaW1hZ2luZWQN Cg0KUGVhY2UgLi50b20NCg0KDQpPbiBGcmksIEp1biA1LCAyMDIwIGF0IDM6MzYgUE0gRGljayBI YXJkdCA8ZGljay5oYXJkdEBnbWFpbC5jb208bWFpbHRvOmRpY2suaGFyZHRAZ21haWwuY29tPj4g d3JvdGU6DQpIaSBUb20NCg0KVGhlIGNoYXJ0ZXIgaXMgaGVyZSBodHRwczovL2RhdGF0cmFja2Vy Li5pZXRmLm9yZy93Zy90eGF1dGgvYWJvdXQvPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv d2cvdHhhdXRoL2Fib3V0Lz4NCg0KQXMgSSB1bmRlcnN0YW5kIGl0LCBvbmUgb2YgdGhlIGl0ZW1z IHdlIGFyZSBzdGFuZGFyZGl6aW5nIGlzIG5lZ290aWF0aW9uIHByb3RvY29sIGJldHdlZW4gdGhl IGNsaWVudCBhbmQgdGhlIHNlcnZlci4gSG93IHRoZSBzZXJ2ZXIgZ2F0aGVycyBjb25zZW50IGZy b20gdGhlIHVzZXIgaXMgY3VycmVudGx5IG5vdCBpbiBzY29wZSwgYW5kIGl0IGlzIG5vdCBjbGVh ciB0byBtZSB3aGF0IGNvdWxkIGJlIHN0YW5kYXJkaXplZCBpbiB0aGUgZXhwZXJpZW5jZSBiZXR3 ZWVuIHRoZSB1c2VyIGFuZCB0aGUgc2VydmVyIHRoYXQgd291bGQgYmUgaW4gc2NvcGUgZm9yIHRo ZSBJRVRGLiBTaW1pbGFybHkgZm9yIGNvbnNlbnQgcmV2b2NhdGlvbi4gQWRkaXRpb25hbGx5LCBh IHVzZXIgbWF5IG5vdCBiZSBpbnZvbHZlZCBpbiB0aGUgbmVnb3RpYXRpb24gcHJvY2VzcyBhdCBh bGwuDQoNCg0KDQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xq YXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPTdmYWM3Y2Y2 LWRiYmEtNDFiOS05NWVmLWYzMmQxZjlkNmUyZF3hkKcNCg0KT24gRnJpLCBKdW4gNSwgMjAyMCBh dCAxOjU5IFBNIFRvbSBKb25lcyA8dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbTxtYWlsdG86 dGhvbWFzY2xpbmdhbmpvbmVzQGdtYWlsLmNvbT4+IHdyb3RlOg0KQmVmb3JlIHdlIHNldHRsZSBv biB0aGlzIG5hbWUsIEkgbXVzdCBhc2sgaWYgdGhlIHdvcmsgZ3JvdXAgaXMgcHJlcGFyZWQgZm9y IHRoZSBjcmVhdGlvbiBvZiBhIG5lZ290aWF0aW9uIHByb3RvY29sLCB3aGljaCBhcyBJIHVuZGVy c3RhbmQgaXQgd2lsbCBpbmNsdWRlIHRoZSBjbGllbnQgYXNraW5nIGZvciBncmFudHMsIHRoZSB1 c2VyIHJlc3BvbmRpbmcgd2l0aCB0aGVpciBpbnRlbnQgKHBvdGVudGlhbGx5IGVpdGhlciBjYW4g c3RhcnQgdGhlIGZsb3cpIGFuZCB0aGUgZ3JhbnQgand0IChqb3NlLCB3aGF0ZXZlcikuIFByZXN1 bWFibHkgdG8gY29tcGxldGUgdGhlIGxpZmVjeWNsZSBzb21lIG1lYW5zIGZvciB0aGUgdXNlciB0 byByZXZva2UgdGhlIGdyYW50cyBhbmQgcXVlcnkgdGhlIGdyYW50cyB3b3VsZCBhbHNvIGJlIHBy b3ZpZGVkLg0KDQpUaGF0IHNlZW1zIGxpa2UgbW9yZSBvZiBhbiBpbnRlZ3JhdGVkIHNvbHV0aW9u IHRoYW4gcHJpb3Igd29yayBlZmZvcnRzIGhhdmUgaW52b2x2ZWQuDQpXaGF0IGlzIHRoZSBjdXJy ZW50IHN0YXR1cyBvZiB0aGUgY2hhcnRlcj8NClBlYWNlIC4udG9tDQoNCk9uIEZyaSwgSnVuIDUs IDIwMjAgYXQgMTozNSBQTSBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0ZkBnbWFpbC5jb208bWFp bHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhhbmsgeW91IHRvIGFsbCB3aG8g cGFydGljaXBhdGVkIGluIHRoZSB0d28gcm91bmRzIG9mIG5hbWUgc2VsZWN0aW9uLiBUaGlzIHBy b2Nlc3MgaGFzIGJlZW4gbG9uZ2VyIHRoYW4gd2UgZXZlciBleHBlY3RlZCwgYW5kIEnigJltIGds YWQgd2UgY2FuIGRlY2xhcmUgY29uc2Vuc3VzIG5vdyBhbmQgbW92ZSBmb3J3YXJkLg0KDQpCYXNl ZCBvbiB0aGUgbGFzdCB0d28gd2Vla3PigJkgd29ydGggb2YgZGlzY3Vzc2lvbiwgd2UgaGF2ZSBy b3VnaCBjb25zZW5zdXMgb24gYSBuYW1lIGZvciB0aGUgcHJvcG9zZWQgd29ya2luZyBncm91cDoN Cg0KICAgICAgICBHTkFQOiBHcmFudCBOZWdvdGlhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBQcm90 b2NvbA0KDQpUaGlzIGRlY2lzaW9uIHdpbGwgbm93IGVuYWJsZSBvdXIgQUQgdG8gcHV0IG91ciBj aGFydGVyIFsxXSBvbiB0aGUgSUVTRydzIHRhYmxlLCB3aGVyZSBJIGhvcGUgd2Ugd2lsbCBiZSBh cHByb3ZlZCBhcyBhIHdvcmtpbmcgZ3JvdXAuDQoNCkhlYWRzIHVwOiB3ZSBpbnRlbmQgdG8gbWVl dCBpbiB0aGUgdXBjb21pbmcgYWxsLXZpcnR1YWwgSUVURiAxMDggaW4gbGF0ZSBKdWx5LCBlaXRo ZXIgYXMgYSBCb0Ygb3IgYXMgYSBuZXdseSBjaGFydGVyZWQgV0cuDQoNClRoYW5rcywNCiAgICAg ICAgWWFyb24NCg0KDQpbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRl ci1pZXRmLXR4YXV0aC8NCg0KDQotLQ0KVHhhdXRoIG1haWxpbmcgbGlzdA0KVHhhdXRoQGlldGYu b3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3R4YXV0aA0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4YXV0aEBpZXRmLm9y ZzxtYWlsdG86VHhhdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90eGF1dGgNCi0tDQpUeGF1dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8 bWFpbHRvOlR4YXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHhhdXRoDQoNCg== From nobody Sun Jun 7 12:45:25 2020 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 895A13A089C for ; Sun, 7 Jun 2020 12:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 qIZkvAVkGgUi for ; Sun, 7 Jun 2020 12:45:22 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96C93A088E for ; Sun, 7 Jun 2020 12:45:21 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id n24so17820223lji.10 for ; Sun, 07 Jun 2020 12:45:21 -0700 (PDT) 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=iTiPbcW1S+rsSHD8c0gvwQqg9cXZDQSFlLsKTzQaZAs=; b=Nxff5sYwZTozPk96/hm+8+CxkehGDGw5OUFgXxABBTcoQc1QZUIwNYbFRFrAR+U3Xc QDc/EzTkA/puhTqpymytlj8Blz87euAHv3/GSV4QsLa+LNS1iyWxZSBzCyPFlEdOGekc MINsYRvbJmlnoyy5Vr7Ns5nz20/cyYJ6cJxOrKHWBiOH/fYyrheddGC9oBqf5qhjySic FPQwIRTvud+/IzT9r3RKupXSlTsVx/vPz25nUGKXWCJNqGukSogSqUb31U3n457f0/WJ 93YeZWfeYBH4hx/+MHl0Roc83weZR1VIXq/5xvDW/kCnlIUA/zkOa1vm+HCXFJHgBgoK ZLRg== 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=iTiPbcW1S+rsSHD8c0gvwQqg9cXZDQSFlLsKTzQaZAs=; b=ka9s8lVthwkpUwA9FAuGS0M1rjxl/r/rZXPcj2JhBgqq6GAOMZeWPGuv4agIAQERSf 5vkBbLUArKVuoWAVknnC90n3GVPgy2Cwe5I7iIIpaqHMMOp6EFwOAKDveO2aAcB0sUG1 3VgYy9M/ZRQI3ZhvAeBoPpldmFcEWVam5RfEaInLgVvRgkEU7NQyrSJ5KPSYCS88Uesi ZTdm1fmdpu3mErZbOsNg4JCC4JICLkv5oFQEuj/De5YftAnOyuL6shgjd1ecBQtO5AqJ Q3qfXKITOsNT5diOj1ymyc+WiWcUnT34ke3rd/30bA6HEugiQe8siP4TiWkMS0XKsRkM Dovw== X-Gm-Message-State: AOAM531s/gugs4PwwlmWUmC3OJct7nEr0PbsAEo9CAqaP2iYq7p2CeLu 6qBJ2fbLZW6F/5w6HiSPye6+Aolm+JtBRtTwViw= X-Google-Smtp-Source: ABdhPJzIyRvG/BUmgX9HWgUsee/1LAi/bAXXWpeSVZoSaLqt1pGF3vURlskfHQA4V28LYOFtD30WAYmhjQHO2DcRAqg= X-Received: by 2002:a2e:8e78:: with SMTP id t24mr2096987ljk.314.1591559119723; Sun, 07 Jun 2020 12:45:19 -0700 (PDT) MIME-Version: 1.0 References: <399d74e9-96d8-4f61-b01e-df9a8ee972d2@www.fastmail.com> In-Reply-To: <399d74e9-96d8-4f61-b01e-df9a8ee972d2@www.fastmail.com> From: Dick Hardt Date: Sun, 7 Jun 2020 12:44:53 -0700 Message-ID: To: Amanjeev Sethi Cc: Jared Jennings , Fabien Imbault , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000f8624605a783bb91" Archived-At: Subject: Re: [Txauth] GNAP it is 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, 07 Jun 2020 19:45:24 -0000 --000000000000f8624605a783bb91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Anyone have objection to the recommended pronunciation being the English word "nap", as in "gnaw"? If not, then we could add a pronunciation recommendation to the Charter. =E1=90=A7 On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi wrote: > Vote for 'G' silent, as in 'lagnappe' ;) > > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote: > > I vote for G silent. For the reason it's most common to pronounce, > especially for those not familiar with open source usages. > > On Sat, Jun 6, 2020, 08:45 Dick Hardt wrote: > > The obvious pronunciation choices are: > > nap (silent g as in gnaw) > > guh-nap (as in the GNU OS - https://www.gnu.org/gnu/pronunciation.en..htm= l > ) > > gee-nap (as in G-man - government man - > https://en.wikipedia.org/wiki/G-man) > > > > =E1=90=A7 > > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault > wrote: > > So, let's adopt a GNAP! We can even come with a little mascot (a bit like > go gopher) as imagined by http://elisegravel.com/blog/adopte-un-gnap/, > loved by little Canadians :-) > > Just to be sure, how do you recommand we pronounce it? > > Looking forward to the next steps too.. > > Thxs > Fabien > -- > 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 > > > --000000000000f8624605a783bb91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Anyone have objection to the recommended pronunciation=C2= =A0being the English word "nap", as in "gnaw"?

=
If not, then we could add a pronunciation=C2=A0recommendation to= the Charter.

3D""=E1=90=A7

=
On Sat, Ju= n 6, 2020 at 8:03 AM Amanjeev Sethi <= aj@amanjeev.com> wrote:
Vote for 'G' silent, as in 'lag= nappe' ;)

On Sat, Jun 6, 2020, at 10:52 AM= , Jared Jennings wrote:
I vote for G silent. For the reason= it's most common to pronounce, especially for those not familiar with = open source usages.

On Sat, J= un 6, 2020, 08:45 Dick Hardt <dick.hardt@gmail.com> wrote:
The obvious pronunciation choices are:=

nap (silent g as in gnaw)

<= /div>
guh-nap (as in the GNU OS -=C2=A0https://www.= gnu.org/gnu/pronunciation.en..html)

gee-na= p (as in G-man - government man -=C2=A0https://en.wikipedia.org/w= iki/G-man)



=
3D""=E1=90=A7

On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault <= fabien.imbault@gmail.com> wrote:
So, let's adopt a GNAP! We can ev= en come with a little mascot (a bit like go gopher) as imagined by=C2=A0http://elisegravel.com/blog/adopte-un-gnap/, = loved by little Canadians :-)=C2=A0

Just to be sure, how do you recommand we pronounce it?=C2= =A0

Looking forward = to the next steps too..=C2=A0

Thxs
Fabien
--
=
Txauth mailing list
https://www.ietf.org/mailman/listinfo/txa= uth
--
Txauth mailing l= ist
--=C2=A0
Txauth mailing list
--000000000000f8624605a783bb91-- From nobody Sun Jun 7 12:51:46 2020 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 1DD323A08AF for ; Sun, 7 Jun 2020 12:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnwWO28oWn7m for ; Sun, 7 Jun 2020 12:51:42 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650092.outbound.protection.outlook.com [40.107.65.92]) (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 0EEDB3A08AC for ; Sun, 7 Jun 2020 12:51:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nxgQaGkID950708eEsv/QZv2eMUMUHjmi4zc30zr9gwjAnIxov8RVnL+M3Ppn+FpFJbjHagid6fvPexvZVva7iQjZx+SwTiH/fZFPzhMbWVM1PW2lFrd3hdzVFJCLznPdED1B5gBah5dyZACI8bBu8sGQgY9xyIEVO3nvLgdPRQn1WDS9ipTGU2iSstKqh+zMbH1mFxLaw6TBY3GHiR++dQ3X7Tlaf6lXkBsH5aWDEM0X27HhzQFCTrSXjPbsLsDg6UI08GlQhj6h5L2G8EwcjOFWqWhZZ2/UdtQdR9EkZQVG1iMGvSedgC9iuxKX6LmHuddiE4uEYXl+YKnb3fSgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9okDivvxrCTztk0PQgArqiAqqnRSe2jinNWMU1InY2E=; b=Lwrq/CNO2ugmPHJSyoal2TaaTyXFkyuTQv6fLaMNOaIb/kvOI7LdowafjzSL7B6HBh/ui2cuawd7hv9/0VBz1IwPf7AMld7cNLPPB9RwY9pJuyhmLc8TGb+kxjQiSFEEbYgsCtp11OwDlrCH7P9N6esfErge97qcQs2e6ZXdNkcMnvQzs1dhJKv1HN/CWp2gt4MSc75RvzwXtw55zyT1T5yQMvBl+BsYbK4Z4H5NsLNYZVmeUwbo9X5JQWkAy9NsQA6hfOJK+FyASZ3UZgzjroC8wLC9hA6P13XHtt1nbUbsi/xiGosgeY7IdRXUq/zn/LpqvD9C+/9u0uqxJcSvxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9okDivvxrCTztk0PQgArqiAqqnRSe2jinNWMU1InY2E=; b=VxpspzG/F3kZlRtSgkWCn66Ix4lJNx4Qoa3gzlz3CPuzQ+qxfoBySHHQGe+DBuvJDpUiJqY0i/4eg2esDubOkWig213bdclrK5o0SLk3JCpqjZdoskGzAvaHSDw2TayB5ClGDfDhF6VM/qbAKenykRCF85Niq6qRgg/du49lRM4= Received: from MN2PR00MB0686.namprd00.prod.outlook.com (2603:10b6:208:15f::13) by MN2PR00MB0576.namprd00.prod.outlook.com (2603:10b6:208:fe::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3114.0; Sun, 7 Jun 2020 19:51:35 +0000 Received: from MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::b816:9dfb:f80d:3b9f]) by MN2PR00MB0686.namprd00.prod.outlook.com ([fe80::b816:9dfb:f80d:3b9f%8]) with mapi id 15.20.3114.000; Sun, 7 Jun 2020 19:51:35 +0000 From: Mike Jones To: Dick Hardt , Amanjeev Sethi CC: Fabien Imbault , Jared Jennings , "txauth@ietf.org" Thread-Topic: [Txauth] GNAP it is Thread-Index: AdY9BQk3wt+6aEMjSYqRT7VfW0RaHA== Date: Sun, 7 Jun 2020 19:51:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a989d841-069a-4016-9b04-0000dbd6962d; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-07T19:49:52Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b45d85ea-36e9-486c-2d3b-08d80b1c2f5d x-ms-traffictypediagnostic: MN2PR00MB0576: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1284; x-forefront-prvs: 04270EF89C x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lD27HJ1zGCx3KbYD3meSB3dT7Pw+ib/8yhek0JLUephQaqILE7p17oqULAuDoFmDLYg99gM3s14SHeXRSToYPVGaxpMOr2LdKz3V7Y/0+b7XiZaKe3zvwYueHT2hWsxOrziyQ8sPGwYOZ2CYXZngw2SmNbNIQ3avvJlRln3mLU2Jb4AiePAzuSzmyIvOain3n1CEysjH5QuCwNIM8RapET3jTtEan588TwMwo+kIPsPXGi07allyajCrbGchccpowQ2jHdQGtL79OpDo6/YOlaJCkMb76fhn1UCjMcMt1YJCusjRVf0sAMpTH9BqpQL+4Gn3VlVimHvOK+kaRR8eICigZoPCVifHaMGOnOA/gpRFqM4n+fDPsCjwfs4VBg2uv6MDjbKES4+K3jb8QYaodr4c1/rNkh/24PkLhlWczOCjbx2JniLAOVgLXG8HyAiUAdIhca9YUvqdWAi+HU2hhg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0686.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(136003)(366004)(346002)(376002)(71200400001)(55016002)(9686003)(66946007)(64756008)(33656002)(186003)(166002)(8676002)(66556008)(52536014)(26005)(76116006)(66476007)(7696005)(8936002)(66446008)(82950400001)(82960400001)(5660300002)(10290500003)(2906002)(8990500004)(4326008)(86362001)(54906003)(110136005)(6506007)(76236002)(53546011)(478600001)(21615005)(966005)(316002)(99710200001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: CWrKh+sOM2JFN9oIwt4uvw6mgD9BxXWPjIAgrQLA+GBUoUbBS8JaBHp2erHEvEBwBvtzFc+e2TTozP89axWE8rzx7pPnXEmVMYaiwK+h9mfFUjORKHcn5/4eVu0HZOaTDzk1W0H0lHrDPQWM+O7KfOZJAR2bicY5JhVR79ZRwO764KQVkH7B1TcCLRAopM7bFuY8afZYJkoAdmuUY61Hgr38WwS09nxuXznJlDZINBWzzVtuhG3JX0QENnuCixivXB68gHpVkaQA4cCA0/50U/kH7bUHYXKQhbJ0WgNnnyInjR9bto/WFoMwV/v2np1HCo47aLK7ulTnRGVAJbCtXwzlKu9LAscUY8OI5O/od9bZFhR15lh7DXQ/4c5oFbgU39UX7c6DCziLcErc52BXL5blCRYtX6u1GqC7t/hqa1wPlghpQaa+2Eg5Hghj2rPTeub2i4NtLRMDdl48GyFjtmpH8kz+S9hj3cCGks3bSdk= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0686AB650F5A99659BB6FFC0F5840MN2PR00MB0686namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b45d85ea-36e9-486c-2d3b-08d80b1c2f5d X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2020 19:51:35.3335 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: k5++wHGGfllT1lco1wZcwoYaHn0n+EnggPl/d7D2InEipr99WLDpb1X514uVokNqbGr4AcsbMbbUE+AIgNJ+9w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0576 Archived-At: Subject: Re: [Txauth] GNAP it is 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, 07 Jun 2020 19:51:44 -0000 --_000_MN2PR00MB0686AB650F5A99659BB6FFC0F5840MN2PR00MB0686namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYWQgYXNzdW1lZCBHdWgtTmFwIOKAkyBwYXJhbGxlbCB0byB0aGUgcHJvbnVuY2lhdGlvbiBv ZiBHTlUuICBJIHRoaW5rIHRoYXTigJlzIHRoZSBtb3N0IG5hdHVyYWwgd2F5IHRvIHJlYWQgaXQu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAtLSBNaWtlDQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBEaWNrIEhhcmR0DQpTZW50OiBTdW5kYXksIEp1bmUgNywgMjAyMCAxMjo0NSBQTQ0K VG86IEFtYW5qZWV2IFNldGhpIDxhakBhbWFuamVldi5jb20+DQpDYzogRmFiaWVuIEltYmF1bHQg PGZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbT47IEphcmVkIEplbm5pbmdzIDxqYXJlZGxqZW5uaW5n c0BnbWFpbC5jb20+OyB0eGF1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBHTkFQ IGl0IGlzDQoNCkFueW9uZSBoYXZlIG9iamVjdGlvbiB0byB0aGUgcmVjb21tZW5kZWQgcHJvbnVu Y2lhdGlvbiBiZWluZyB0aGUgRW5nbGlzaCB3b3JkICJuYXAiLCBhcyBpbiAiZ25hdyI/DQoNCklm IG5vdCwgdGhlbiB3ZSBjb3VsZCBhZGQgYSBwcm9udW5jaWF0aW9uIHJlY29tbWVuZGF0aW9uIHRv IHRoZSBDaGFydGVyLg0KDQrhkKcNCg0KT24gU2F0LCBKdW4gNiwgMjAyMCBhdCA4OjAzIEFNIEFt YW5qZWV2IFNldGhpIDxhakBhbWFuamVldi5jb208bWFpbHRvOmFqQGFtYW5qZWV2LmNvbT4+IHdy b3RlOg0KVm90ZSBmb3IgJ0cnIHNpbGVudCwgYXMgaW4gJ2xhZ25hcHBlJyA7KQ0KDQpPbiBTYXQs IEp1biA2LCAyMDIwLCBhdCAxMDo1MiBBTSwgSmFyZWQgSmVubmluZ3Mgd3JvdGU6DQpJIHZvdGUg Zm9yIEcgc2lsZW50LiBGb3IgdGhlIHJlYXNvbiBpdCdzIG1vc3QgY29tbW9uIHRvIHByb25vdW5j ZSwgZXNwZWNpYWxseSBmb3IgdGhvc2Ugbm90IGZhbWlsaWFyIHdpdGggb3BlbiBzb3VyY2UgdXNh Z2VzLg0KDQpPbiBTYXQsIEp1biA2LCAyMDIwLCAwODo0NSBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0 QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNClRoZSBvYnZp b3VzIHByb251bmNpYXRpb24gY2hvaWNlcyBhcmU6DQoNCm5hcCAoc2lsZW50IGcgYXMgaW4gZ25h dykNCg0KZ3VoLW5hcCAoYXMgaW4gdGhlIEdOVSBPUyAtIGh0dHBzOi8vd3d3LmdudS5vcmcvZ251 L3Byb251bmNpYXRpb24uZW4uLmh0bWw8aHR0cHM6Ly93d3cuZ251Lm9yZy9nbnUvcHJvbnVuY2lh dGlvbi5lbi5odG1sPikNCg0KZ2VlLW5hcCAoYXMgaW4gRy1tYW4gLSBnb3Zlcm5tZW50IG1hbiAt IGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0ctbWFuKQ0KDQoNCg0K4ZCnDQoNCk9uIFNh dCwgSnVuIDYsIDIwMjAgYXQgMTozNCBBTSBGYWJpZW4gSW1iYXVsdCA8ZmFiaWVuLmltYmF1bHRA Z21haWwuY29tPG1haWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20+PiB3cm90ZToNClNvLCBs ZXQncyBhZG9wdCBhIEdOQVAhIFdlIGNhbiBldmVuIGNvbWUgd2l0aCBhIGxpdHRsZSBtYXNjb3Qg KGEgYml0IGxpa2UgZ28gZ29waGVyKSBhcyBpbWFnaW5lZCBieSBodHRwOi8vZWxpc2VncmF2ZWwu Y29tL2Jsb2cvYWRvcHRlLXVuLWduYXAvLCBsb3ZlZCBieSBsaXR0bGUgQ2FuYWRpYW5zIDotKQ0K DQpKdXN0IHRvIGJlIHN1cmUsIGhvdyBkbyB5b3UgcmVjb21tYW5kIHdlIHByb25vdW5jZSBpdD8N Cg0KTG9va2luZyBmb3J3YXJkIHRvIHRoZSBuZXh0IHN0ZXBzIHRvby4uDQoNClRoeHMNCkZhYmll bg0KLS0NClR4YXV0aCBtYWlsaW5nIGxpc3QNClR4YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgN Ci0tDQpUeGF1dGggbWFpbGluZyBsaXN0DQpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoDQot LQ0KVHhhdXRoIG1haWxpbmcgbGlzdA0KVHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aA0KDQoN Cg== --_000_MN2PR00MB0686AB650F5A99659BB6FFC0F5840MN2PR00MB0686namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ SSBoYWQgYXNzdW1lZCBHdWgtTmFwIOKAkyBwYXJhbGxlbCB0byB0aGUgcHJvbnVuY2lhdGlvbiBv ZiBHTlUuJm5ic3A7IEkgdGhpbmsgdGhhdOKAmXMgdGhlIG1vc3QgbmF0dXJhbCB3YXkgdG8gcmVh ZCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBUeGF1dGggJmx0O3R4YXV0aC1ib3VuY2VzQGlldGYu b3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5EaWNrIEhhcmR0PGJyPg0KPGI+U2VudDo8L2I+ IFN1bmRheSwgSnVuZSA3LCAyMDIwIDEyOjQ1IFBNPGJyPg0KPGI+VG86PC9iPiBBbWFuamVldiBT ZXRoaSAmbHQ7YWpAYW1hbmplZXYuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gRmFiaWVuIEltYmF1 bHQgJmx0O2ZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbSZndDs7IEphcmVkIEplbm5pbmdzICZsdDtq YXJlZGxqZW5uaW5nc0BnbWFpbC5jb20mZ3Q7OyB0eGF1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtUeGF1dGhdIEdOQVAgaXQgaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW55b25lIGhhdmUgb2JqZWN0aW9uIHRvIHRoZSByZWNvbW1lbmRlZCBw cm9udW5jaWF0aW9uJm5ic3A7YmVpbmcgdGhlIEVuZ2xpc2ggd29yZCAmcXVvdDtuYXAmcXVvdDss IGFzIGluICZxdW90O2duYXcmcXVvdDs/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JZiBub3QsIHRoZW4gd2UgY291bGQgYWRkIGEgcHJvbnVuY2lhdGlvbiZu YnNwO3JlY29tbWVuZGF0aW9uIHRvIHRoZSBDaGFydGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpbWcgd2lkdGg9IjEiIGhl aWdodD0iMSIgc3R5bGU9IndpZHRoOi4wMTA0aW47aGVpZ2h0Oi4wMTA0aW4iIGlkPSJfeDAwMDBf aTEwMjYiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xq YXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9 OGI3Mjc1NWUtMjRlYy00YzA4LTlmMmItMTNhZTExYWY0MzA0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBTYXQsIEp1biA2LCAyMDIwIGF0IDg6MDMgQU0gQW1hbmplZXYgU2V0aGkgJmx0 OzxhIGhyZWY9Im1haWx0bzphakBhbWFuamVldi5jb20iPmFqQGFtYW5qZWV2LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Wb3RlIGZvciAnRycgc2lsZW50LCBhcyBpbiAnbGFnbmFw cGUnIDspPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFNhdCwgSnVuIDYsIDIwMjAsIGF0IDEwOjUyIEFNLCBKYXJlZCBKZW5uaW5ncyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCIgaWQ9ImdtYWlsLW1fLTU2ODgyODI0NTc4ODQ5Nzk0 OTBxdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB2b3RlIGZvciBHIHNpbGVudC4g Rm9yIHRoZSByZWFzb24gaXQncyBtb3N0IGNvbW1vbiB0byBwcm9ub3VuY2UsIGVzcGVjaWFsbHkg Zm9yIHRob3NlIG5vdCBmYW1pbGlhciB3aXRoIG9wZW4gc291cmNlIHVzYWdlcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNh dCwgSnVuIDYsIDIwMjAsIDA4OjQ1IERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBvYnZpb3VzIHByb251bmNpYXRpb24gY2hv aWNlcyBhcmU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPm5hcCAoc2lsZW50IGcgYXMgaW4gZ25hdyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Z3VoLW5hcCAoYXMgaW4gdGhlIEdOVSBPUyAt Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuZ251Lm9yZy9nbnUvcHJvbnVuY2lhdGlvbi5lbi5o dG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuZ251Lm9yZy9nbnUvcHJvbnVuY2lhdGlv bi5lbi4uaHRtbDwvYT4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmdlZS1uYXAgKGFzIGluIEctbWFuIC0gZ292ZXJubWVudCBtYW4gLSZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0ctbWFuIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvRy1tYW48L2E+KTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjEiIGhlaWdodD0iMSIgc3R5bGU9IndpZHRoOi4wMTA0aW47 aGVpZ2h0Oi4wMTA0aW4iIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2Fl LmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldGcGJDNWpiMjAlM0QmYW1w O3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9YmNiOGFhOTktZTM4OC00NGIyLTk5YzktMTYwYTFh OTBmMzhlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dh ZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQs IEp1biA2LCAyMDIwIGF0IDE6MzQgQU0gRmFiaWVuIEltYmF1bHQgJmx0OzxhIGhyZWY9Im1haWx0 bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5mYWJpZW4uaW1iYXVs dEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIGxldCdzIGFkb3B0 IGEgR05BUCEgV2UgY2FuIGV2ZW4gY29tZSB3aXRoIGEgbGl0dGxlIG1hc2NvdCAoYSBiaXQgbGlr ZSBnbyBnb3BoZXIpIGFzIGltYWdpbmVkIGJ5Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2VsaXNlZ3Jh dmVsLmNvbS9ibG9nL2Fkb3B0ZS11bi1nbmFwLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9lbGlz ZWdyYXZlbC5jb20vYmxvZy9hZG9wdGUtdW4tZ25hcC88L2E+LCBsb3ZlZCBieSBsaXR0bGUgQ2Fu YWRpYW5zDQogOi0pJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkp1c3QgdG8gYmUgc3VyZSwgaG93IGRvIHlvdSByZWNvbW1hbmQgd2Ug cHJvbm91bmNlIGl0PyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Mb29raW5nIGZvcndhcmQgdG8gdGhlIG5leHQgc3RlcHMgdG9vLi4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGh4czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RmFiaWVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UeGF1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86VHhhdXRoQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+VHhhdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90eGF1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlR4 YXV0aCBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5UeGF1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3R4YXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHhhdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VHhhdXRoIG1h aWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgaHJlZj0ibWFpbHRvOlR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlR4 YXV0aEBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdHhhdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90eGF1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_MN2PR00MB0686AB650F5A99659BB6FFC0F5840MN2PR00MB0686namp_-- From nobody Sun Jun 7 13:09:40 2020 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 29B123A08C7 for ; Sun, 7 Jun 2020 13:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 G8hV-SEBHqOo for ; Sun, 7 Jun 2020 13:09:37 -0700 (PDT) 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 F2D013A08C1 for ; Sun, 7 Jun 2020 13:09:36 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id s1so17910639ljo.0 for ; Sun, 07 Jun 2020 13:09:36 -0700 (PDT) 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=+Jbt62xRrB8XTLAgNOqzN7TOeP9j3xC2W7Vz5PicRQs=; b=YP2gVDzbLhs8cfhQFpmPsimQZIbGaltVnDvNdFbzlehT+3/ioVCp84d8SKWSzvzozZ NkjTABMAB3GV4HJArLf8aV1L3C0aikWhIlC+zfNY9+Ppszt+nvwTj/oLlcNmZAVuVHYJ mofIXjAl+LOmupew/ZcVzOmodICnu1UjFKO7Jlkar9yK5L380KL4WB0N9y2eJdmuc64Q R2FeWsCUIv8pWeDl/R0dmhfWIZPhPYcnzvM34x7Zdg08nfBJZHUOjfZW8cKEHE0QYfPo euxes9fVElXEvmY3SBdjpxgOyZ0mWh7Wf7/v09UqCLfougosRZBfwTq9kMFU+aQNYXcX dnTg== 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=+Jbt62xRrB8XTLAgNOqzN7TOeP9j3xC2W7Vz5PicRQs=; b=MGurjLDkUahEKDRjYlXnioGuvTw518GoGi8nVhVMv50E5HF85cdrgeT/npfCctcqf/ YBQOysTspXaVO+qRd4XeN6/ulktvXMRaC279mejszsKqf+O6szeDXFmOIrgGc/lAojY1 Oe5ANsZSxloG868Ne8Rk6KluMldy4GRLErzYJe0HAnUUrvRqhFxYwIcr1r/qw5Mu4aDT NP3+K+KPctNeGTUEgjziZ0lHo6D0JShq4euNbQW1M8s3sPpyld1hEM0DTol/AqhcpJ60 yQLDPwmnhcyponmCmgOd8QsnaOt7bHkxouRElw+O3uH6Ow9bqeMmZviJOXJCazjSDKlp vFdQ== X-Gm-Message-State: AOAM532IZ4rbtKhqIttVdp22gGo6w04m21b94UPJ9L2kn/rX8vqYh5ZZ G20n6eRNkoXsf8pUPv9VHp8HZhqZCv9ddcCOMYk= X-Google-Smtp-Source: ABdhPJx98aGmEAzLlHujVcw6CGmXsNSSXhs+RAXjep8ORTM10vhfM11Q9fdGgVmYavKsoPSGttrueyo2dPepzPNfgHo= X-Received: by 2002:a2e:3a19:: with SMTP id h25mr9675258lja.213.1591560571508; Sun, 07 Jun 2020 13:09:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Sun, 7 Jun 2020 13:09:05 -0700 Message-ID: To: Mike Jones Cc: Amanjeev Sethi , Fabien Imbault , Jared Jennings , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="00000000000080db8b05a78412c9" Archived-At: Subject: Re: [Txauth] GNAP it is 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, 07 Jun 2020 20:09:39 -0000 --00000000000080db8b05a78412c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It is if you are familiar with any of the GNU projects. https://www.gnu.org/gnu/pronunciation.en.html A quick search on the internet has the "normal" pronunciation of "gnu" to have a silent 'g'. https://www.howtopronounce.com/gnu https://dictionary.cambridge.org/us/pronunciation/english/gnu =E1=90=A7 On Sun, Jun 7, 2020 at 12:51 PM Mike Jones wrote: > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of GNU. I = think > that=E2=80=99s the most natural way to read it. > > > > -- Mike > > > > *From:* Txauth *On Behalf Of *Dick Hardt > *Sent:* Sunday, June 7, 2020 12:45 PM > *To:* Amanjeev Sethi > *Cc:* Fabien Imbault ; Jared Jennings < > jaredljennings@gmail.com>; txauth@ietf.org > *Subject:* Re: [Txauth] GNAP it is > > > > Anyone have objection to the recommended pronunciation being the English > word "nap", as in "gnaw"? > > > > If not, then we could add a pronunciation recommendation to the Charter. > > > > =E1=90=A7 > > > > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi wrote: > > Vote for 'G' silent, as in 'lagnappe' ;) > > > > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote: > > I vote for G silent. For the reason it's most common to pronounce, > especially for those not familiar with open source usages. > > > > On Sat, Jun 6, 2020, 08:45 Dick Hardt wrote: > > The obvious pronunciation choices are: > > > > nap (silent g as in gnaw) > > > > guh-nap (as in the GNU OS - https://www.gnu.org/gnu/pronunciation.en..htm= l > ) > > > > gee-nap (as in G-man - government man - > https://en.wikipedia.org/wiki/G-man) > > > > > > > > =E1=90=A7 > > > > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault > wrote: > > So, let's adopt a GNAP! We can even come with a little mascot (a bit like > go gopher) as imagined by http://elisegravel.com/blog/adopte-un-gnap/, > loved by little Canadians :-) > > > > Just to be sure, how do you recommand we pronounce it? > > > > Looking forward to the next steps too.. > > > > Thxs > > Fabien > > -- > > 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 > > > > > > --00000000000080db8b05a78412c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It is if you are familiar with any of the GNU projects.
= https://www.gnu.org/gnu/pronunciation.en.html

A = quick search on the internet has the "normal" pronunciation of &q= uot;gnu" to have a silent 'g'.



3D""=E1=90= =A7

On Sun, Jun 7, 2020 at 12:51 PM Mike Jones <Michael.Jones@microsoft.com> wrote:
=

I had assumed Guh= -Nap =E2=80=93 parallel to the pronunciation of GNU.=C2=A0 I think that=E2= =80=99s the most natural way to read it.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: Txauth <txauth-bounces@ietf.org> On Beha= lf Of Dick Hardt
Sent: Sunday, June 7, 2020 12:45 PM
To: Amanjeev Sethi <aj@amanjeev.com>
Cc: Fabien Imbault <fabien.imbault@gmail.com>; Jared Jennings <jaredljennings@gma= il.com>; txauth= @ietf.org
Subject: Re: [Txauth] GNAP it is

=C2=A0

Anyone have objection to the recommended pronunciati= on=C2=A0being the English word "nap", as in "gnaw"?<= /u>

=C2=A0

If not, then we could add a pronunciation=C2=A0recom= mendation to the Charter.

=C2=A0

= = =E1=90=A7

=C2=A0

On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi <aj@amanjeev.com> = wrote:

Vote for 'G' silent, as in 'lagnappe'= ; ;)

=C2=A0

On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wro= te:

I vote for G silent. For the reason it's most co= mmon to pronounce, especially for those not familiar with open source usage= s.

=C2=A0

On Sat, Jun 6, 2020, 08:45 Dick Hardt <dick.hardt@gmail.com>= ; wrote:

The obvious pronunciation choices are:=

=C2=A0

nap (silent g as in gnaw)

=C2=A0

guh-nap (as in the GNU OS -=C2=A0https://www.gnu.or= g/gnu/pronunciation.en..html)

=C2=A0

gee-nap (as in G-man - government man -=C2=A0https://en.wikip= edia.org/wiki/G-man)

=C2=A0

=C2=A0

=C2=A0

=E1=90=A7

=C2=A0

On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault <fabien.imbault@= gmail.com> wrote:

So, let's adopt a GNAP! We can even come with a = little mascot (a bit like go gopher) as imagined by=C2=A0http://elisegravel.= com/blog/adopte-un-gnap/, loved by little Canadians :-)=C2=A0

=C2=A0

Just to be sure, how do you recommand we pronounce i= t?=C2=A0

=C2=A0

Looking forward to the next steps too..=C2=A0=

=C2=A0

Thxs

Fabien

--

Txauth mailing list

--

Txauth mailing list

--=C2=A0

Txauth mailing list

=C2=A0

=C2=A0

--00000000000080db8b05a78412c9-- From nobody Sun Jun 7 13:23:25 2020 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 BD26B3A08F8 for ; Sun, 7 Jun 2020 13:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=mozilla.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 A_sqA-por_DL for ; Sun, 7 Jun 2020 13:23:21 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0: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 C47603A08F0 for ; Sun, 7 Jun 2020 13:23:21 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id a137so13444892oii.3 for ; Sun, 07 Jun 2020 13:23:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=htYhPAZ9r5lSlLYXBDahQc5yruaLbLxxMF+dM6szcGg=; b=MguUD2naXLly7PtKxLZf92tmlLtRWX2Y7KNOnhPCDK6HYTkU/FRk3P/W0wiw2w1vv6 ov2Dx0FesmhbmfF6rUiQVjkM4JqQCuhCZVzdkJIXyHsm1tdDMfugmnSgUERRcPKzHO1H d5Ux1tL5qpIxI8umXCQn9x9OBEFA0igTafA9Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=htYhPAZ9r5lSlLYXBDahQc5yruaLbLxxMF+dM6szcGg=; b=ud7393anIiG+CXYQ6Hs1+vVfnZSPsFQ3fIjowgk5RUSNgC/Il9bUbQn3o8Lm1VnQhy /EE80Ba8ufSR9rZBVOjxgoiAugAjQuSd8anhPizPqm/9EEM+bwZhad3NSN+LxFZRRXCr HGZnVWdD31IWGVc30MEEYrgT7MU3O3dy7KN4ACzRfmFsEGzC4XUg7c7g8pYMpTe2Sy/O xVmg84wTwOTXtA9kWrdntJgfP69JnvnD3cQZ/2FdcdrejJY363xKb8jcV3fgiatum30w HOkZPz92A+F2JRmNCn2zcSC1XOPm/J04XKPENxfIcKu/pgi4BTP9h3mpWbO1b+ArmZUx wPmQ== X-Gm-Message-State: AOAM5337sIM+SKRo50uIkMKbOk6f85BDUIULiGwKBDDv3tOj893B2ADY wakFLcoxagxxvnCWhbsRy2OSRg== X-Google-Smtp-Source: ABdhPJzONHVfFouysYAXV1jFwQFif8iPBEK3p0y3EVxuRFIQM0cYoUFzl2PjC0jpPGtlpVX0AbIOBQ== X-Received: by 2002:aca:ea46:: with SMTP id i67mr8082749oih.152.1591561400641; Sun, 07 Jun 2020 13:23:20 -0700 (PDT) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id h189sm1959778oif.10.2020.06.07.13.23.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Jun 2020 13:23:19 -0700 (PDT) To: Dick Hardt , Mike Jones Cc: Fabien Imbault , Jared Jennings , Amanjeev Sethi , "txauth@ietf.org" References: From: Peter Saint-Andre Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= mQINBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABtCdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT6JAlQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekLkCDQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAYkCPAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <8db677bd-d054-136f-fbad-cae55237f7a8@mozilla.com> Date: Sun, 7 Jun 2020 14:23:18 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Txauth] GNAP it is 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, 07 Jun 2020 20:23:24 -0000 Looks like we were caught gnapping. ;-) OK, that's the last of my snarky comments, let's get to work! Peter On 6/7/20 2:09 PM, Dick Hardt wrote: > It is if you are familiar with any of the GNU projects. > > https://www.gnu.org/gnu/pronunciation.en.html > > A quick search on the internet has the "normal" pronunciation of "gnu" > to have a silent 'g'. > > https://www.howtopronounce.com/gnu > https://dictionary.cambridge.org/us/pronunciation/english/gnu > > > ᐧ > > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones > wrote: > > I had assumed Guh-Nap – parallel to the pronunciation of GNU.  I > think that’s the most natural way to read it.____ > > __ __ > >                                                        -- Mike____ > > __ __ > > *From:* Txauth > *On Behalf Of *Dick Hardt > *Sent:* Sunday, June 7, 2020 12:45 PM > *To:* Amanjeev Sethi > > *Cc:* Fabien Imbault >; Jared Jennings > >; > txauth@ietf.org > *Subject:* Re: [Txauth] GNAP it is____ > > __ __ > > Anyone have objection to the recommended pronunciation being the > English word "nap", as in "gnaw"?____ > > __ __ > > If not, then we could add a pronunciation recommendation to the > Charter.____ > > __ __ > > ᐧ____ > > __ __ > > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi > wrote:____ > > Vote for 'G' silent, as in 'lagnappe' ;)____ > > __ __ > > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____ > > I vote for G silent. For the reason it's most common to > pronounce, especially for those not familiar with open > source usages.____ > > __ __ > > On Sat, Jun 6, 2020, 08:45 Dick Hardt > wrote:____ > > The obvious pronunciation choices are:____ > > __ __ > > nap (silent g as in gnaw)____ > > __ __ > > guh-nap (as in the GNU OS > - https://www.gnu.org/gnu/pronunciation.en..html > )____ > > __ __ > > gee-nap (as in G-man - government man > - https://en.wikipedia.org/wiki/G-man)____ > > __ __ > > __ __ > > __ __ > > ᐧ____ > > __ __ > > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault > > wrote:____ > > So, let's adopt a GNAP! We can even come with a > little mascot (a bit like go gopher) as imagined > by http://elisegravel.com/blog/adopte-un-gnap/, > loved by little Canadians :-) ____ > > __ __ > > Just to be sure, how do you recommand we pronounce > it? ____ > > __ __ > > Looking forward to the next steps too.. ____ > > __ __ > > Thxs____ > > Fabien____ > > --____ > > 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____ > > __ __ > > __ __ > > From nobody Sun Jun 7 13:41:09 2020 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 22BF43A092F for ; Sun, 7 Jun 2020 13:41:07 -0700 (PDT) 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 LE9K0By4N1RZ for ; Sun, 7 Jun 2020 13:41:04 -0700 (PDT) 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 230493A092E for ; Sun, 7 Jun 2020 13:41:03 -0700 (PDT) Received: from [192.168.1.14] (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 057Kf0YU002644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 7 Jun 2020 16:41:00 -0400 From: Justin Richer Message-Id: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_37BC341D-08EA-42F7-A140-FDBED50FFB8C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 7 Jun 2020 16:41:00 -0400 In-Reply-To: Cc: txauth@ietf.org To: Dick Hardt References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 07 Jun 2020 20:41:07 -0000 --Apple-Mail=_37BC341D-08EA-42F7-A140-FDBED50FFB8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Dick, responses inline. > On Jun 7, 2020, at 3:27 PM, Dick Hardt wrote: >=20 > Hello >=20 > I have just posed some updates on the XAuth draft: >=20 > In -07 I added the XYZ features of interaction negotiation, and a = Client Handle for dynamic clients. I also updated the name to GNAP, but = preserved the draft-hardt-xauth-protocol filename for ease of tracking = changes.=20 >=20 > In -08 I split the doc into: core protocol, advanced features, and = JOSE authentication.=20 >=20 > https://www.ietf.org/id/draft-hardt-xauth-protocol-08.html = > https://www.ietf.org/id/draft-hardt-gnap-advanced-00.html = > https://www.ietf.org/id/draft-hardt-gnap-jose-00.html = >=20 > IMHO, the main doc is much more readable. :) >=20 I think that renaming your individual draft is premature and = presumptive, as the WG has not yet decided on an approach for the WG = base draft and renaming one of the input drafts like this is going to = simply add to confusion when trying to discuss and compare different = approaches. I would recommend undoing this name change in order to = facilitate discussion going forward, to allow people to refer to one = project with a single name and know what it means. As you and I have discussed offline, and as you yourself suggested, it = might be beneficial for the working group to start from a new draft = document incorporating the most important features. Until we reach that = point, renaming any of the input drafts into what the group=E2=80=99s = target draft will be is going to cause problems. >=20 > XYZ vs XAuth >=20 > The remaining major differences between XYZ and XAuth are areas I have = concerns about. (I will continue to use XYZ and XAuth refer to each = draft). The concerns are: >=20 > 1) API in JSON vs URI and HTTP Verb >=20 > In XYZ, all calls are to the same endpoint as an HTTP POST. The AS = must parse the JSON to determine what to do.=20 >=20 > XAuth has a RESTful interface. A Grant Request starts at the GS URI, = and Grants and Authorizations are returned as URI resources. Creating a = Grant is done with a POST, reading a Grant is done with a GET.=20 >=20 > With URIs and HTTP verbs, A large scale GS can easily implement = independent services for each functionality as routing of requests can = be done at the HTTP layer based on the URI and HTTP verb. This allows a = separation of concerns, independent deployment, and resiliency. As I have said many, many times, both on the list and in the = documentation for XYZ, this is an area that is worth discussing within = the working group. It=E2=80=99s been tagged a potential direction in XYZ = from early days, but not something that we=E2=80=99ve pursued because it = hasn=E2=80=99t been needed in the spaces we=E2=80=99ve used it. So saying this is a fundamental aspect of XYZ and implying that it=E2=80=99= s a non-starter for it to not be built that way is misdirection. I hope = that the conversation here in this group can continue without you = ignoring or dismissing previous statements like this as we discuss = things.=20 Additionally, I find XAuth=E2=80=99s restrictions on the structure of = the Grant URI potentially problematic, namely that it has to start with = the server=E2=80=99s URL. This will lead to deployments needing to bend = their setups with proxies or redirectors to make things fit, which you = yourself have said is going to be an issue for things like supporting a = short redirect URL vs. a long redirect URL. Your complaint there was one = of latency and complexity, why does that not apply here? But most = fundamentally, I do not see what value this restriction brings to the = system. If the value is coming back from the GS endpoint, and the client = is getting all of its pointers from there, what=E2=80=99s the point of = dictating how that has to look? >=20 > 2) Handles for all Clients vs Client ID and Client Handle >=20 > In XYZ, both pre-registered clients and dynamic clients use a handle.=20= >=20 > In XAuth, the Client ID refers to a pre-registered client, and the = Client Handle is specific to an instance of a dynamic client. Using = separate terms clearly differentiates which identifier is being = presented to the GS.=20 >=20 > This allows a GS to use separate mechanisms for managing = pre-registered clients and dynamic clients, an important consideration = as there can easily be millions of instances of a single dynamic client. >=20 > Additionally, developers are already familiar with what a Client ID is = for pre-registered clients. I see the inconsistency in the XAuth draft to be problematic. Under this = proposed model, I now need to be able to track clients using different = kinds of identifiers depending on what kind of registration they used? = Why build in this dichotomy? One of the design goals of XYZ was to bring consistency to the haphazard = world of OAuth 2, where a client ID could mean a class of client = software or an individual client or a cluster of servers or any number = of other things.=20 And as I=E2=80=99ve demonstrated with an implementation on top of the = MITREid Connect OAuth 2 server, it=E2=80=99s completely possible and = well within-protocol to pass in a static client ID within the XYZ=E2=80=99= s =E2=80=9Ckey handle=E2=80=9D field and have things work as expected. = Yes, it=E2=80=99s called something different =E2=80=94 but if that=E2=80=99= s a problem, then XAuth=E2=80=99s renaming of the Authorization Server = to a Grant Server is going to be significantly more confusing for = developers, don=E2=80=99t you think? >=20 > 3) Transaction Handles are One Time Use >=20 > In XYZ, transaction handles are one time use [1]. In the OAuth WG = discussion on one time use refresh tokens, clients are often distributed = across components, which complicates one time use references.=20 >=20 > One time use transaction handles also makes them inconsistent with the = display, resource, user, and key handles. Transaction handles being one-time-use is based on experience with a = session fixation attack against UMA (now patched): = https://kantarainitiative.org/confluence/display/uma/Understanding+the+Ses= sion+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+Mitigation = = Clients with distributed components are going to have to be considered = in our core model, and so there are considerations and tradeoffs in = terms of security and deployability that we need to address here. These = are the same kinds of discussions that we=E2=80=99re having in OAuth 2, = as you point out, and so we can not only apply that experience and = knowledge to this, but we can build something that behaves better than a = refresh token for this purpose. >=20 > 4) New User Identifier >=20 > XYZ introduces a new identifier for the user, a User Handle. Unclear = why a new type of user identifier is needed, except for the desire to = have a handle for everything. >=20 This is based directly on the Persisted Claims Token concept from UMA2, = where a client (that is trusted to make such a statement) can say that = it reasonably believes that the current user interacting with this = client is the same user that it=E2=80=99s been interacting with before, = for use with a future request. An AS can take this signal into = consideration when processing the request, potentially avoiding = unnecessary interaction and friction. I=E2=80=99m not surprised that you see this as =E2=80=9Cjust applying a = handle for everything=E2=80=9D considering you=E2=80=99ve previously = objected to the use of the pass-by-reference construct for other aspects = of the protocol in the past as well. Each component in XYZ that has a = separate handle has one for specific and documented reasons, and it=E2=80=99= s a core feature that these are handled (pun intended) in a consistent = and predictable manner. > 5) Interaction Capabilities vs Modes >=20 > In XYZ, the capabilities are expressed by the client, and the GS = states which capabilities it will accept. This can make it difficult for = the GS to enforce the interaction choices as the client can mix and = match which capabilities are returned. For example, a GS may not want to = support a redirect without a callback to protect itself from session = fixation attacks. In XAuth, the interaction modes provide clarity on the = mode of interaction and the security properties. For example the GS may = support both user_code and redirect modes, but not the indirect mode = which is subject to session fixation attacks. >=20 If the GS doesn=E2=80=99t want to accept a redirect without a callback, = it can because the request will have a redirect, but not a callback, and = it can reject the request. What makes you believe that this is not = detectable or not possible in XYZ?=20 The modes in XAuth are much more limiting, as the mixing of different = interaction methods is already something that we need to start figuring = out. Let=E2=80=99s say, for example, a client can do a redirect, accept = a CIBA-style ping, or do a direct app2app communication. There=E2=80=99s = a natural preference the client will have here: if it can talk to = another app directly, it=E2=80=99ll try that first. If that doesn=E2=80=99= t work, it can get a push notification sent, and if all that fails, it = can pop open a browser. If I have to pick just one of those modes when I = make the request, then the client needs to make three different requests = to the AS before I get anything that works.=20 This kind of mixing is important to allow for different modalities of = client. In fact, the return callback could be tied to the entry of a = user code, not just an outbound redirect. How the client gets the user = to the AS and how the user gets back are separate questions, and we need = flexibility in both. XAuth ties them together in the same way that OAuth = 2 does, and this is an unnecessary restriction that does not add = security or simplicity. > 6) Claims at Top Level vs Namespaced=20 >=20 > In XYZ, there is one schema for claims, and they are requested as: >=20 > "claims": { > "subject": true, > "email": true > } >=20 > Whereas in XAuth, claims are in their own namespace: >=20 > "claims": { > "oidc": { > "id_token" : { > "email" : { "essential" : true }, > "email_verified" : { "essential" : true } > }, > "userinfo" : { > "name" : { "essential" : true }, > "picture" : null > } > } >=20 > In this example, the client is requesting OIDC defined claims, the = email to be in an ID Token, and the name and picture to be as text. = While the XYZ schema may be extended, there are already numerous schemas = being used. The XAuth approach is to support existing and new schemas, = rather than pick one and/or create another one, and allows a Grant = Request to contain claims from multiple schemas at the same time. Again, as I have said many times, this part of the request (as is the = rest of the request) is extensible. The goal of the =E2=80=9Cclaims=E2=80=9D= object in XYZ was to propose a simple, common core. Is this the best = set? Probably not, but that=E2=80=99s why nothing is final yet, right?=20= If we wanted to allow for OIDC style claims objects, we have space to do = exactly that, either as a sub-component of the existing claims object or = as a new top-level object in the request. This flexibility is important, = as there are other schemas and other query languages that people might = want to support, including things like JWM: https://tools.ietf.org/id/draft-looker-jwm-01.html = And at Mike Jones=E2=80=99s request, I=E2=80=99ve added notes in the = current draft of XYZ to the places that will be extensible via registry = or some other mechanism =E2=80=94 but the goal was to have everything in = there be extensible by reasonable mechanisms in ways that will allow = innovation to flourish without breaking core and common functionality.=20= I do not understand why you insist on painting XYZ as a static, = inflexible, and unbending model when it is exactly the opposite. You = don=E2=80=99t have to externalize every piece of flexibility in order to = have it, and I really hope that these myths don=E2=80=99t keep getting = repeated in the group. >=20 > 7) No Authorization Type >=20 > Similar to (6), XYZ has a single schema for how to request access to a = resource. While that schema is extensible, it requires adaption from any = system with an existing schema. XAuth has a type for each authorization = request (oauth2, rar), allowing existing schemas and new schemas to be = supported. This is a ridiculous claim because the RAR format is a back port of the = XYZ format to an OAuth 2 architecture. If you consider that RAR is = extensible, then XYZ is extensible by your same definitions. In = addition, if there are other resource query languages out there beyond = these, and we can support them just like we would support additional = claims query languages.=20 Furthermore, as I=E2=80=99ve said before, XAuth doesn=E2=80=99t allow a = clean way to define the use of both OAuth 2 scopes and rich requests. = XYZ does this by allowing scope-style strings and full JSON objects to = be specified at the same level in the same data structure, so there=E2=80=99= s no confusion over how they=E2=80=99re grouped or applied. XAuth makes = me choose ahead of time to use one or the other, effectively at the API = level. So I can no longer easily call for, say, =E2=80=9Clogin = information=E2=80=9D (a general scope) along with =E2=80=9Ctransaction = history for a specific bank account=E2=80=9D (a rich data object) in the = same request. Even RAR handles this better than XAuth by simply letting = the =E2=80=9Cscope=E2=80=9D parameter also be passed along side the = authorization_details object, but there are significant complexity = issues with this as there isn=E2=80=99t a clear way to combine these = concepts in the OAuth 2 world. I think we can do so much better here, = and XYZ proposes one such consistent way to do that by defining the = scope-equivalent to be a pass-by-reference version of the rich object = that is passed-by-value. If clients have a shortcut (a scope), they can = use that; if they need the expressiveness of the resources structure, = they can do that.=20 >=20 > Summary >=20 > While concerns (3-7) can be addressed in XYZ, (1-2) look fundamental = to the XYZ architecture. >=20 > [1] = https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-7 = >=20 > [2] https://w3c.github.io/vc-data-model/ = I=E2=80=99m not sure what you intended to bring up about VC=E2=80=99s in = your email, because I didn=E2=80=99t see a back-reference to this, but = I=E2=80=99m glad you did mention it. This is an example of a query, = assertion, and proofing data model for users that uses a structure and = language that is outside of the OIDC world, but existing parallel to it. = I believe our protocol needs to be flexible enough to allow this kind of = thing on input (the client presenting information about who the user is, = as well as requesting specific information about the user) and output = (the AS claiming information about the user), in addition to the client = being given something that it can then in turn use with another service = down the line to present user information. The world is moving away from = an IdP-driven identity model, and we need to keep moving with it and = enable it here. Thanks, =E2=80=94 Justin >=20 > =E1=90=A7 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_37BC341D-08EA-42F7-A140-FDBED50FFB8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Dick, responses inline.

On Jun 7, 2020, at 3:27 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

Hello

I have just posed some = updates on the XAuth draft:

In -07 I added the XYZ features of interaction negotiation, = and a Client Handle for dynamic clients. I also updated the name to = GNAP, but preserved the draft-hardt-xauth-protocol filename for ease of = tracking changes. 

In -08 I split the doc into: core protocol, advanced = features, and JOSE authentication. 

https://www.ietf.org/id/draft-hardt-xauth-protocol-08.html<= br class=3D"">
https://www.ietf.org/id/draft-hardt-gnap-advanced-00.html
https://www.ietf.org/id/draft-hardt-gnap-jose-00.html

IMHO, the main doc is much more readable. :)


I think that renaming your individual draft is = premature and presumptive, as the WG has not yet decided on an approach = for the WG base draft and renaming one of the input drafts like this is = going to simply add to confusion when trying to discuss and compare = different approaches. I would recommend undoing this name change in = order to facilitate discussion going forward, to allow people to refer = to one project with a single name and know what it means.

As you and I have discussed offline, and as you = yourself suggested, it might be beneficial for the working group to = start from a new draft document incorporating the most important = features. Until we reach that point, renaming any of the input drafts = into what the group=E2=80=99s target draft will be is going to cause = problems.


XYZ vs XAuth

The remaining major differences between XYZ and XAuth are = areas I have concerns about. (I will continue to use XYZ and XAuth refer = to each draft). The concerns are:

1) API in JSON vs URI and = HTTP Verb

In XYZ, all calls are to the same = endpoint as an HTTP POST. The AS must parse the JSON to determine = what to do. 

XAuth has a RESTful interface. A Grant Request starts at = the GS URI, and Grants and Authorizations are returned as URI resources. = Creating a Grant is done with a POST, reading a Grant is done with a = GET. 

With URIs = and HTTP verbs, A large scale GS can easily implement independent = services for each  functionality as routing of requests can be = done at the HTTP layer based on the URI and HTTP verb. This allows a = separation of concerns, independent deployment, and = resiliency.

As I have said many, many times, both on the list = and in the documentation for XYZ, this is an area that is worth = discussing within the working group. It=E2=80=99s been tagged a = potential direction in XYZ from early days, but not something that = we=E2=80=99ve pursued because it hasn=E2=80=99t been needed in the = spaces we=E2=80=99ve used it.

So = saying this is a fundamental aspect of XYZ and implying that it=E2=80=99s = a non-starter for it to not be built that way is misdirection. I hope = that the conversation here in this group can continue without you = ignoring or dismissing previous statements like this as we discuss = things. 

Additionally, I find = XAuth=E2=80=99s restrictions on the structure of the Grant URI = potentially problematic, namely that it has to start with the server=E2=80= =99s URL. This will lead to deployments needing to bend their setups = with proxies or redirectors to make things fit, which you yourself have = said is going to be an issue for things like supporting a short redirect = URL vs. a long redirect URL. Your complaint there was one of latency and = complexity, why does that not apply here? But most fundamentally, I do = not see what value this restriction brings to the system. If the value = is coming back from the GS endpoint, and the client is getting all of = its pointers from there, what=E2=80=99s the point of dictating how that = has to look?


2) Handles for all Clients vs Client ID and Client = Handle

In XYZ, both pre-registered clients = and dynamic clients use a handle. 

In XAuth, the Client ID refers to a = pre-registered client, and the Client Handle is specific to an instance = of a dynamic client. Using separate terms clearly differentiates which = identifier is being presented to the GS. 

This allows a GS to use separate = mechanisms for managing pre-registered clients and dynamic clients, an = important consideration as there can easily be millions of instances of = a single dynamic client.

Additionally, developers are already = familiar with what a Client ID is for pre-registered = clients.

I = see the inconsistency in the XAuth draft to be problematic. Under this = proposed model, I now need to be able to track clients using different = kinds of identifiers depending on what kind of registration they used? = Why build in this dichotomy?

One of = the design goals of XYZ was to bring consistency to the haphazard world = of OAuth 2, where a client ID could mean a class of client software or = an individual client or a cluster of servers or any number of other = things. 

And as I=E2=80=99ve = demonstrated with an implementation on top of the MITREid Connect OAuth = 2 server, it=E2=80=99s completely possible and well within-protocol to = pass in a static client ID within the XYZ=E2=80=99s =E2=80=9Ckey = handle=E2=80=9D field and have things work as expected. Yes, it=E2=80=99s = called something different =E2=80=94 but if that=E2=80=99s a problem, = then XAuth=E2=80=99s renaming of the Authorization Server to a Grant = Server is going to be significantly more confusing for developers, = don=E2=80=99t you think?


3) = Transaction Handles are One Time Use

In XYZ, transaction = handles are one time use [1]. In the OAuth WG discussion on one time use = refresh tokens, clients are often distributed across components, which = complicates one time use references. 

One time use transaction handles also = makes them inconsistent with the display, resource, user, and key = handles.

Transaction handles being one-time-use is based on = experience with a session fixation attack against UMA (now = patched):


Clients with = distributed components are going to have to be considered in our core = model, and so there are considerations and tradeoffs in terms of = security and deployability that we need to address here. These are the = same kinds of discussions that we=E2=80=99re having in OAuth 2, as you = point out, and so we can not only apply that experience and knowledge to = this, but we can build something that behaves better than a refresh = token for this purpose.


4) New User Identifier

XYZ introduces a new identifier for the = user, a User Handle. Unclear why a new type of user identifier is = needed, except for the desire to have a handle for everything.


This is based directly on the Persisted Claims = Token concept from UMA2, where a client (that is trusted to make such a = statement) can say that it reasonably believes that the current user = interacting with this client is the same user that it=E2=80=99s been = interacting with before, for use with a future request. An AS can take = this signal into consideration when processing the request, potentially = avoiding unnecessary interaction and friction.

I=E2=80=99m not surprised that you see this as = =E2=80=9Cjust applying a handle for everything=E2=80=9D considering = you=E2=80=99ve previously objected to the use of the pass-by-reference = construct for other aspects of the protocol in the past as well. Each = component in XYZ that has a separate handle has one for specific and = documented reasons, and it=E2=80=99s a core feature that these are = handled (pun intended) in a consistent and predictable manner.

5) Interaction Capabilities vs Modes

In XYZ, the capabilities are = expressed by the client, and the GS states which capabilities it will = accept. This can make it difficult for the GS to enforce the interaction = choices as the client can mix and match which capabilities are returned. = For example, a GS may not want to support a redirect without a callback = to protect itself from session fixation attacks. In XAuth, the = interaction modes provide clarity on the mode of interaction and the = security properties. For example the GS may support both user_code and = redirect modes, but not the indirect mode which is subject to session = fixation attacks.


If the GS doesn=E2=80=99t want to accept a = redirect without a callback, it can because the request will have a = redirect, but not a callback, and it can reject the request. What makes = you believe that this is not detectable or not possible in = XYZ? 

The modes in XAuth are = much more limiting, as the mixing of different interaction methods is = already something that we need to start figuring out. Let=E2=80=99s say, = for example, a client can do a redirect, accept a CIBA-style ping, or do = a direct app2app communication. There=E2=80=99s a natural preference the = client will have here: if it can talk to another app directly, it=E2=80=99= ll try that first. If that doesn=E2=80=99t work, it can get a push = notification sent, and if all that fails, it can pop open a browser. If = I have to pick just one of those modes when I make the request, then the = client needs to make three different requests to the AS before I get = anything that works. 

This kind = of mixing is important to allow for different modalities of client. In = fact, the return callback could be tied to the entry of a user code, not = just an outbound redirect. How the client gets the user to the AS and = how the user gets back are separate questions, and we need flexibility = in both. XAuth ties them together in the same way that OAuth 2 does, and = this is an unnecessary restriction that does not add security or = simplicity.

6) = Claims at Top Level vs Namespaced 

In = XYZ, there is one schema for claims, and they are requested = as:

  =  "claims": {
       "subject": = true,
       "email": true
   }

Whereas in XAuth, claims are in their = own namespace:

    "claims": {
      =   "oidc": {
            = "id_token" : {
            =     "email"          : { "essential" = : true },
              =   "email_verified" : { "essential" : true }
  =           },
      =       "userinfo" : {
      =           "name"         =   : { "essential" : true },
      =           "picture"       =  : null
            = }
        }

In = this example, the client is requesting OIDC defined claims, the email to = be in an ID Token, and the name and picture to be as text. While the XYZ = schema may be extended, there are already numerous schemas being used. = The XAuth approach is to support existing and new schemas, rather = than pick one and/or create another one, and allows a Grant Request to = contain claims from multiple schemas at the same = time.

Again, = as I have said many times, this part of the request (as is the rest of = the request) is extensible. The goal of the =E2=80=9Cclaims=E2=80=9D = object in XYZ was to propose a simple, common core. Is this the best = set? Probably not, but that=E2=80=99s why nothing is final yet, = right? 

If we wanted to allow = for OIDC style claims objects, we have space to do exactly that, either = as a sub-component of the existing claims object or as a new top-level = object in the request. This flexibility is important, as there are other = schemas and other query languages that people might want to support, = including things like JWM:


And at Mike Jones=E2=80=99s request, I=E2=80=99= ve added notes in the current draft of XYZ to the places that will be = extensible via registry or some other mechanism =E2=80=94 but the goal = was to have everything in there be extensible by reasonable mechanisms = in ways that will allow innovation to flourish without breaking core and = common functionality. 

I do not = understand why you insist on painting XYZ as a static, inflexible, and = unbending model when it is exactly the opposite. You don=E2=80=99t have = to externalize every piece of flexibility in order to have it, and I = really hope that these myths don=E2=80=99t keep getting repeated in the = group.


7) No Authorization = Type

Similar to (6), XYZ has a single schema for how to request = access to a resource. While that schema is extensible, it requires = adaption from any system with an existing schema. XAuth has a type = for each authorization request (oauth2, rar), allowing existing schemas = and new schemas to be supported.

This is a ridiculous claim because the RAR format = is a back port of the XYZ format to an OAuth 2 architecture. If you = consider that RAR is extensible, then XYZ is extensible by your same = definitions. In addition, if there are other resource query languages = out there beyond these, and we can support them just like we would = support additional claims query languages. 

Furthermore, as I=E2=80=99ve said before, XAuth = doesn=E2=80=99t allow a clean way to define the use of both OAuth 2 = scopes and rich requests. XYZ does this by allowing scope-style strings = and full JSON objects to be specified at the same level in the same data = structure, so there=E2=80=99s no confusion over how they=E2=80=99re = grouped or applied. XAuth makes me choose ahead of time to use one or = the other, effectively at the API level. So I can no longer easily call = for, say, =E2=80=9Clogin information=E2=80=9D (a general scope) along = with =E2=80=9Ctransaction history for a specific bank account=E2=80=9D = (a rich data object) in the same request. Even RAR handles this better = than XAuth by simply letting the =E2=80=9Cscope=E2=80=9D parameter also = be passed along side the authorization_details object, but there are = significant complexity issues with this as there isn=E2=80=99t a clear = way to combine these concepts in the OAuth 2 world. I think we can do so = much better here, and XYZ proposes one such consistent way to do that by = defining the scope-equivalent to be a pass-by-reference version of the = rich object that is passed-by-value. If clients have a shortcut (a = scope), they can use that; if they need the expressiveness of the = resources structure, they can do that. 


Summary

While concerns (3-7) can be addressed = in XYZ, (1-2) look fundamental to the XYZ architecture.

[1] https://tools.ietf.org/html/draft-richer-transactional-authz-08= #section-7

[2] https://w3c.github.io/vc-data-model/

I=E2=80=99m not sure what you = intended to bring up about VC=E2=80=99s in your email, because I = didn=E2=80=99t see a back-reference to this, but I=E2=80=99m glad you = did mention it. This is an example of a query, assertion, and proofing = data model for users that uses a structure and language that is outside = of the OIDC world, but existing parallel to it. I believe our protocol = needs to be flexible enough to allow this kind of thing on input (the = client presenting information about who the user is, as well as = requesting specific information about the user) and output (the AS = claiming information about the user), in addition to the client being = given something that it can then in turn use with another service down = the line to present user information. The world is moving away from an = IdP-driven identity model, and we need to keep moving with it and enable = it here.


Thanks,
 =E2=80=94 Justin


3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_37BC341D-08EA-42F7-A140-FDBED50FFB8C-- From nobody Sun Jun 7 13:48:05 2020 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 08A993A094D for ; Sun, 7 Jun 2020 13:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.fm header.b=RLEb9V1G; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D0O1/WFZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5DyfuFCqqGV for ; Sun, 7 Jun 2020 13:48:01 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ADE33A094C for ; Sun, 7 Jun 2020 13:48:01 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 710E75C006C; Sun, 7 Jun 2020 16:47:59 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Sun, 07 Jun 2020 16:47:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm3; bh=jYAVZ Ht3JAEsF1QKoOk5Y3YzL2zcWuJ7uaZDLdvjLKQ=; b=RLEb9V1GvoxEwhOPl1BfD MjVUTENJQg32ce9thuA1O+qazEomrnfrbqawWMDW4jjI+OHx4KbmdUFREUcJ2/Wr bSvntB5znyRnt/yhqFYxMdywC9qigxUiRHSv1f/WWEAuS4eUiR41fN3RwJXjaCRM QjwnJgAM9qjyCdb8O4mQBqaSwgWkw8FSLtF70y7hLG0xdStHXqa8Rs16eTap8nB+ 5iBvFHqRdrgYgIbw23IzIS8P6Q4bfOJQsrPcQXB8lo1TfFt+DgoL/GZ6U8ZOJoij 154tMcfruF211FHO1AnBJcjpdJfl6uMNVw+FXwTot5iU27BUyT5f6Xh/W+3f3FxV Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=jYAVZHt3JAEsF1QKoOk5Y3YzL2zcWuJ7uaZDLdvjL KQ=; b=D0O1/WFZNMAA7yH/V0Q5eAAWf4QvrDbODm76fCUubByb/B2piEq0LSQTg plIUlA/MQzitoR1+UnT2zR2WsPdhw3bp3ponTFJ2TsV2PHsUR3bY9DUr99/TOPt6 yCud7gO7EnP3CiQTopXnij8k2DA5+r2xFzmOoHorf6Wphlsjz//XIHtmZSKWp6jV 7qmkWbET+hrrQuf6QnsbKjkcPQzy8IbItIBGm3mJEEOi+3CdVVfWYftHENTe7Xt1 lsIaKAQ1mamgRSv0Agp9emU9gwHRO5R4ehy7/zX6He9sSwi6NaWRI+DHpRPVk51T 2Pa3/YtClWmSbrFEcCs1DGbcAKPMA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegledgudehjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdgh rgihnhgvucevhhgrnhhgfdcuoeifhigtsehfrghsthhmrghilhdrfhhmqeenucggtffrrg htthgvrhhnpeehfeeivdeggeekieejleekueekkeefgfeggeelueeuheeitdeivddvvddu vefgteenucffohhmrghinhepghhnuhdrohhrghdphhhofihtohhprhhonhhouhhntggvrd gtohhmpdgtrghmsghrihgughgvrdhorhhgpdifihhkihhpvgguihgrrdhorhhgpdgvlhhi shgvghhrrghvvghlrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeifhigtsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 02CCEE00FB; Sun, 7 Jun 2020 16:47:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: In-Reply-To: <8db677bd-d054-136f-fbad-cae55237f7a8@mozilla.com> References: <8db677bd-d054-136f-fbad-cae55237f7a8@mozilla.com> Date: Sun, 07 Jun 2020 16:47:34 -0400 From: "Wayne Chang" To: "Peter Saint-Andre" , "Dick Hardt" , "Mike Jones" Cc: "Fabien Imbault" , "Jared Jennings" , "Amanjeev Sethi" , "txauth@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Txauth] GNAP it is 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, 07 Jun 2020 20:48:03 -0000 can we consider aligning around a canonical music sharing example called= gnapster? On Sun, Jun 7, 2020, at 4:23 PM, Peter Saint-Andre wrote: > Looks like we were caught gnapping. ;-) >=20 > OK, that's the last of my snarky comments, let's get to work! >=20 > Peter >=20 > On 6/7/20 2:09 PM, Dick Hardt wrote: > > It is if you are familiar with any of the GNU projects. > >=20 > > https://www.gnu.org/gnu/pronunciation.en.html > >=20 > > A quick search on the internet has the "normal" pronunciation of "gn= u" > > to have a silent 'g'. > >=20 > > https://www.howtopronounce.com/gnu > > https://dictionary.cambridge.org/us/pronunciation/english/gnu > >=20 > >=20 > > =E1=90=A7 > >=20 > > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones > > wrote: > >=20 > > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of= GNU.=C2=A0 I > > think that=E2=80=99s the most natural way to read it.____ > >=20 > > __=C2=A0__ > >=20 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike____ > >=20 > > __=C2=A0__ > >=20 > > *From:* Txauth > > *On Behalf Of *Dick Hardt > > *Sent:* Sunday, June 7, 2020 12:45 PM > > *To:* Amanjeev Sethi > > > *Cc:* Fabien Imbault > >; Jared Jennings > > >; > > txauth@ietf.org > > *Subject:* Re: [Txauth] GNAP it is____ > >=20 > > __=C2=A0__ > >=20 > > Anyone have objection to the recommended pronunciation=C2=A0bein= g the > > English word "nap", as in "gnaw"?____ > >=20 > > __=C2=A0__ > >=20 > > If not, then we could add a pronunciation=C2=A0recommendation to= the > > Charter.____ > >=20 > > __=C2=A0__ > >=20 > > =E1=90=A7____ > >=20 > > __=C2=A0__ > >=20 > > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi > > wrote:____ > >=20 > > Vote for 'G' silent, as in 'lagnappe' ;)____ > >=20 > > __=C2=A0__ > >=20 > > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____ > >=20 > > I vote for G silent. For the reason it's most common to > > pronounce, especially for those not familiar with open > > source usages.____ > >=20 > > __=C2=A0__ > >=20 > > On Sat, Jun 6, 2020, 08:45 Dick Hardt > > wrote:____ > >=20 > > The obvious pronunciation choices are:____ > >=20 > > __=C2=A0__ > >=20 > > nap (silent g as in gnaw)____ > >=20 > > __=C2=A0__ > >=20 > > guh-nap (as in the GNU OS > > -=C2=A0https://www.gnu.org/gnu/pronunciation.en..htm= l > > )____= > >=20 > > __=C2=A0__ > >=20 > > gee-nap (as in G-man - government man > > -=C2=A0https://en.wikipedia.org/wiki/G-man)____ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > > =E1=90=A7____ > >=20 > > __=C2=A0__ > >=20 > > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault > > > > wrote:____ > >=20 > > So, let's adopt a GNAP! We can even come with a > > little mascot (a bit like go gopher) as imagined= > > by=C2=A0http://elisegravel.com/blog/adopte-un-gn= ap/, > > loved by little Canadians :-)=C2=A0____ > >=20 > > __=C2=A0__ > >=20 > > Just to be sure, how do you recommand we pronoun= ce > > it?=C2=A0____ > >=20 > > __=C2=A0__ > >=20 > > Looking forward to the next steps too..=C2=A0___= _ > >=20 > > __=C2=A0__ > >=20 > > Thxs____ > >=20 > > Fabien____ > >=20 > > --____ > >=20 > > Txauth mailing list____ > >=20 > > Txauth@ietf.org ____ > >=20 > > https://www.ietf.org/mailman/listinfo/txauth____= > >=20 > > --____ > >=20 > > Txauth mailing list____ > >=20 > > Txauth@ietf.org ____ > >=20 > > https://www.ietf.org/mailman/listinfo/txauth____ > >=20 > > --=C2=A0____ > >=20 > > Txauth mailing list____ > >=20 > > Txauth@ietf.org ____ > >=20 > > https://www.ietf.org/mailman/listinfo/txauth____ > >=20 > > __=C2=A0__ > >=20 > > __=C2=A0__ > >=20 > >=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > From nobody Sun Jun 7 15:33:29 2020 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 189E53A0A5F for ; Sun, 7 Jun 2020 15:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 OCFvzYdsi16s for ; Sun, 7 Jun 2020 15:33:25 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983393A0A60 for ; Sun, 7 Jun 2020 15:33:24 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id x18so1643449lji.1 for ; Sun, 07 Jun 2020 15:33:24 -0700 (PDT) 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=T8//Bt7++lt47DuzZtTS/QQURJK89CnU2QTWpPYYcco=; b=qzQzzV7R9C2W7wZoC449m5HVnWXQdcRI+vDlTaTvtQOgnwS8L6sHp5DLAmLWQ7MJlp H6Dme+9jmBKdKou5OIwH5nbz9EaZUz8FaKSHP0dpZ+X1OxCY4BNWbU9Niq55n9E1Ih1W 5EAOGJi+4EmQgZeTuMoCTrkHhYCNkChksbvepZB4kC6B4dzUWbIh4doR3ASANJTHBmCB yyfM8PC2sNpb+s0Js+wmuSNFtiluBlM9PLA7vAq1s/+lsuS9U/ttU0VM14jruk1rxLpm 1jJcbP3oC8qA4k8A8etH0V7iuDjRUFphVLtUP85IxcgDgFx1qcMCwjQpfz80uUAQ1Y3D 0SdA== 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=T8//Bt7++lt47DuzZtTS/QQURJK89CnU2QTWpPYYcco=; b=bvIbO5Rs+WsLZEtErhb+81AVOLhgBK+U7dKiNz3vNJhHaVUwmCCvZA6+qV3ahMB0Sd kiUaSmHG9+hvOV0ksyN3AgFZn5SN4sNg0Kf/J09X+dsJJhbKP7B7+sHhuYAzAMk0aSiI jrgbhlv0zJ7Od4xtSga1mY1OfYd7gx32ZUy2wt+BernMet0s20dwnvMbbrFuOWnEfwiN tffNGN+4zH9c9LgQIgaFrbLIVvPaEUNaFRWchLstKbH3lsz6DGGmcongps1jzgV0ORgx DtSGETci30JPKGFwqfOPUy7KKwunpjcjvGlYOFPfYMCLbPMO+eWLPUr1FLjNq8WF8+YS k8aQ== X-Gm-Message-State: AOAM53225pfZGfI/iregJ+PTGgHtzywBdulBvEYYIeoY27Ol218jeTzs gf47FYz3dGwjZD9z1RDTIRsV8mZ1AHArHGodly8= X-Google-Smtp-Source: ABdhPJxXKhYXVA5zSwBDrZ0PAN7AF578IXKudWK6aGXT4Gm2lAbxiQ+GeuBB0q3aIPwCAATb8+Gm+4zFYaK86ofF0CU= X-Received: by 2002:a2e:3a19:: with SMTP id h25mr9848155lja.213.1591569202542; Sun, 07 Jun 2020 15:33:22 -0700 (PDT) MIME-Version: 1.0 References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> In-Reply-To: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> From: Dick Hardt Date: Sun, 7 Jun 2020 15:32:55 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000f3fdee05a7861441" Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 07 Jun 2020 22:33:28 -0000 --000000000000f3fdee05a7861441 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable comments inline ... On Sun, Jun 7, 2020 at 1:41 PM Justin Richer wrote: > Hi Dick, responses inline. > > On Jun 7, 2020, at 3:27 PM, Dick Hardt wrote: > > Hello > > I have just posed some updates on the XAuth draft: > > In -07 I added the XYZ features of interaction negotiation, and a Client > Handle for dynamic clients. I also updated the name to GNAP, but preserve= d > the draft-hardt-xauth-protocol filename for ease of tracking changes. > > In -08 I split the doc into: core protocol, advanced features, and JOSE > authentication. > > https://www.ietf.org/id/draft-hardt-xauth-protocol-08.html > https://www.ietf.org/id/draft-hardt-gnap-advanced-00.html > https://www.ietf.org/id/draft-hardt-gnap-jose-00.html > > IMHO, the main doc is much more readable. :) > > > I think that renaming your individual draft is premature and presumptive, > as the WG has not yet decided on an approach for the WG base draft and > renaming one of the input drafts like this is going to simply add to > confusion when trying to discuss and compare different approaches. I woul= d > recommend undoing this name change in order to facilitate discussion goin= g > forward, to allow people to refer to one project with a single name and > know what it means. > > As you and I have discussed offline, and as you yourself suggested, it > might be beneficial for the working group to start from a new draft > document incorporating the most important features. Until we reach that > point, renaming any of the input drafts into what the group=E2=80=99s tar= get draft > will be is going to cause problems. > My intent was to remove confusion, not create confusion. Per my comments below, I refer to my draft as XAuth, and your draft as XYZ. The filename still has -xauth- and not -gnap-. I have pushed a -09 that has additional text in the introduction to clarify it should be referred to as XAuth. https://www.ietf.org/id/draft-hardt-xauth-protocol-09.html I named the other files with draft-hardt-gnap to make it clear the document is related to the proposed GNAP WG. > > > *XYZ vs XAuth* > > The remaining major differences between XYZ and XAuth are areas I have > concerns about. (I will continue to use XYZ and XAuth refer to each draft= ). > The concerns are: > > *1) API in JSON vs URI and HTTP Verb* > > In XYZ, all calls are to the same endpoint as an HTTP POST. The AS must > parse the JSON to determine what to do. > > XAuth has a RESTful interface. A Grant Request starts at the GS URI, and > Grants and Authorizations are returned as URI resources. Creating a Grant > is done with a POST, reading a Grant is done with a GET. > > With URIs and HTTP verbs, A large scale GS can easily implement > independent services for each functionality as routing of requests can b= e > done at the HTTP layer based on the URI and HTTP verb. This allows a > separation of concerns, independent deployment, and resiliency. > > > As I have said many, many times, both on the list and in the documentatio= n > for XYZ, this is an area that is worth discussing within the working grou= p. > It=E2=80=99s been tagged a potential direction in XYZ from early days, bu= t not > something that we=E2=80=99ve pursued because it hasn=E2=80=99t been neede= d in the spaces > we=E2=80=99ve used it. > > So saying this is a fundamental aspect of XYZ and implying that it=E2=80= =99s a > non-starter for it to not be built that way is misdirection. I hope that > the conversation here in this group can continue without you ignoring or > dismissing previous statements like this as we discuss things. > I'm comparing the two drafts we have today, not what the drafts could be. You have consistently stated that there is just one end point in the XYZ model, and that handles represent the transaction rather than URIs -- as yo= u state again below in your response to point 4. I find it is much easier for people to understand a proposal to write it up. I could not see how to easily modify XYZ to support the models I envisioned, which is why I wrote XAuth. > > Additionally, I find XAuth=E2=80=99s restrictions on the structure of the= Grant > URI potentially problematic, namely that it has to start with the server= =E2=80=99s > URL. This will lead to deployments needing to bend their setups with > proxies or redirectors to make things fit, which you yourself have said i= s > going to be an issue for things like supporting a short redirect URL vs. = a > long redirect URL. Your complaint there was one of latency and complexity= , > why does that not apply here? But most fundamentally, I do not see what > value this restriction brings to the system. If the value is coming back > from the GS endpoint, and the client is getting all of its pointers from > there, what=E2=80=99s the point of dictating how that has to look? > Requiring the Grant URI to start with the GS URI is open to discussion. It is not clear to me why a deployment would need to have a redirector. Large scale deployments I have worked on have a router / proxy that routes requests to internal services. Having all the URIs start with the GS URI enables all GNAP operations to be routed in the same place. An advantage of starting with the GS URI is that any software on the Client side knows which GS it belongs to. A Grant URI passed to a Client in a GS initiated login allows the Client to know if it trusts the GS before operating on the Grant URI. If the Grant URI can be any URI, then a Client could be tricked into operating on a Grant URI it should not be operating on. > > > *2) Handles for all Clients vs Client ID and Client Handle* > > In XYZ, both pre-registered clients and dynamic clients use a handle. > > In XAuth, the Client ID refers to a pre-registered client, and the Client > Handle is specific to an instance of a dynamic client. Using separate ter= ms > clearly differentiates which identifier is being presented to the GS. > > This allows a GS to use separate mechanisms for managing pre-registered > clients and dynamic clients, an important consideration as there can easi= ly > be millions of instances of a single dynamic client. > > Additionally, developers are already familiar with what a Client ID is fo= r > pre-registered clients. > > > I see the inconsistency in the XAuth draft to be problematic. Under this > proposed model, I now need to be able to track clients using different > kinds of identifiers depending on what kind of registration they used? Wh= y > build in this dichotomy? > A GS implementation is free to use the same identifiers and storage system for Client IDs and Client Handles. > > One of the design goals of XYZ was to bring consistency to the haphazard > world of OAuth 2, where a client ID could mean a class of client software > or an individual client or a cluster of servers or any number of other > things. > In XYZ a client handle refers to both registered clients, and dynamic clients. That seems to continue to be haphazard. Dynamic Registration needed to use Client ID as the rest of OAuth only understood that identifier for a client. XAuth allows each type of client to have their own identifier. > > And as I=E2=80=99ve demonstrated with an implementation on top of the MIT= REid > Connect OAuth 2 server, it=E2=80=99s completely possible and well within-= protocol > to pass in a static client ID within the XYZ=E2=80=99s =E2=80=9Ckey handl= e=E2=80=9D field and have > things work as expected. Yes, it=E2=80=99s called something different =E2= =80=94 but if > that=E2=80=99s a problem, then XAuth=E2=80=99s renaming of the Authorizat= ion Server to a > Grant Server is going to be significantly more confusing for developers, > don=E2=80=99t you think? > Nope. > > > *3) Transaction Handles are One Time Use* > > In XYZ, transaction handles are one time use [1]. In the OAuth WG > discussion on one time use refresh tokens, clients are often distributed > across components, which complicates one time use references. > > One time use transaction handles also makes them inconsistent with the > display, resource, user, and key handles. > > > Transaction handles being one-time-use is based on experience with a > session fixation attack against UMA (now patched): > > > https://kantarainitiative.org/confluence/display/uma/Understanding+the+Se= ssion+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+Mitigation > > Clients with distributed components are going to have to be considered in > our core model, and so there are considerations and tradeoffs in terms of > security and deployability that we need to address here. These are the sa= me > kinds of discussions that we=E2=80=99re having in OAuth 2, as you point o= ut, and so > we can not only apply that experience and knowledge to this, but we can > build something that behaves better than a refresh token for this purpose= . > The XAuth proposal is to use a URI to represent the authorization. > > > *4) New User Identifier* > > XYZ introduces a new identifier for the user, a User Handle. Unclear why > a new type of user identifier is needed, except for the desire to have a > handle for everything. > > > This is based directly on the Persisted Claims Token concept from UMA2, > where a client (that is trusted to make such a statement) can say that it > reasonably believes that the current user interacting with this client is > the same user that it=E2=80=99s been interacting with before, for use wit= h a future > request. An AS can take this signal into consideration when processing th= e > request, potentially avoiding unnecessary interaction and friction. > My statement is that it was unclear why it was needed. Perhaps you can add a Rationale section to XYZ? > > I=E2=80=99m not surprised that you see this as =E2=80=9Cjust applying a h= andle for > everything=E2=80=9D considering you=E2=80=99ve previously objected to the= use of the > pass-by-reference construct for other aspects of the protocol in the past > as well. Each component in XYZ that has a separate handle has one for > specific and documented reasons, and it=E2=80=99s a core feature that the= se are > handled (pun intended) in a consistent and predictable manner. > This is why I state that it seems hard to change (1) above. > > *5) Interaction Capabilities vs Modes* > > In XYZ, the capabilities are expressed by the client, and the GS states > which capabilities it will accept. This can make it difficult for the GS = to > enforce the interaction choices as the client can mix and match which > capabilities are returned. For example, a GS may not want to support a > redirect without a callback to protect itself from session fixation > attacks. In XAuth, the interaction modes provide clarity on the mode of > interaction and the security properties. For example the GS may support > both user_code and redirect modes, but not the indirect mode which is > subject to session fixation attacks. > > > If the GS doesn=E2=80=99t want to accept a redirect without a callback, i= t can > because the request will have a redirect, but not a callback, and it can > reject the request. What makes you believe that this is not detectable or > not possible in XYZ? > I did not say it could not be done, I'm saying it is more difficult in XYZ than in XAuth > > The modes in XAuth are much more limiting, as the mixing of different > interaction methods is already something that we need to start figuring > out. Let=E2=80=99s say, for example, a client can do a redirect, accept a > CIBA-style ping, or do a direct app2app communication. There=E2=80=99s a = natural > preference the client will have here: if it can talk to another app > directly, it=E2=80=99ll try that first. If that doesn=E2=80=99t work, it = can get a push > notification sent, and if all that fails, it can pop open a browser. If I > have to pick just one of those modes when I make the request, then the > client needs to make three different requests to the AS before I get > anything that works. > Have you read the revised draft? As I noted above, I have added negotiation. The Client can state all the modes it wants, the GS can respond with the modes it will support, and the Client can offer the User any modes returned from the GS. > > This kind of mixing is important to allow for different modalities of > client. In fact, the return callback could be tied to the entry of a user > code, not just an outbound redirect. How the client gets the user to the = AS > and how the user gets back are separate questions, and we need flexibilit= y > in both. > Yes, we need flexibility. We also need the GS to be able to easily enforce what can happen. > XAuth ties them together in the same way that OAuth 2 does, and this is a= n > unnecessary restriction that does not add security or simplicity. > > *6) Claims at Top Level vs Namespaced * > > In XYZ, there is one schema for claims, and they are requested as: > > "claims": { > "subject": true, > "email": true > } > > Whereas in XAuth, claims are in their own namespace: > > "claims": { > "oidc": { > "id_token" : { > "email" : { "essential" : true }, > "email_verified" : { "essential" : true } > }, > "userinfo" : { > "name" : { "essential" : true }, > "picture" : null > } > } > > In this example, the client is requesting OIDC defined claims, the email > to be in an ID Token, and the name and picture to be as text. While the X= YZ > schema may be extended, there are already numerous schemas being used. Th= e > XAuth approach is to support existing and new schemas, rather than pick o= ne > and/or create another one, and allows a Grant Request to contain claims > from multiple schemas at the same time. > > > Again, as I have said many times, this part of the request (as is the res= t > of the request) is extensible. The goal of the =E2=80=9Cclaims=E2=80=9D o= bject in XYZ was > to propose a simple, common core. Is this the best set? Probably not, but > that=E2=80=99s why nothing is final yet, right? > Yes, XYZ is extensible. It is not namespaced as XAuth is. > > If we wanted to allow for OIDC style claims objects, we have space to do > exactly that, either as a sub-component of the existing claims object or = as > a new top-level object in the request. This flexibility is important, as > there are other schemas and other query languages that people might want = to > support, including things like JWM: > > https://tools.ietf.org/id/draft-looker-jwm-01.html > > And at Mike Jones=E2=80=99s request, I=E2=80=99ve added notes in the curr= ent draft of XYZ > to the places that will be extensible via registry or some other mechanis= m > =E2=80=94 but the goal was to have everything in there be extensible by r= easonable > mechanisms in ways that will allow innovation to flourish without breakin= g > core and common functionality. > > I do not understand why you insist on painting XYZ as a static, > inflexible, and unbending model when it is exactly the opposite. You don= =E2=80=99t > have to externalize every piece of flexibility in order to have it, and I > really hope that these myths don=E2=80=99t keep getting repeated in the g= roup. > All I am doing is comparing what is written. I'm not trying to paint XYZ anything. > > > *7) No Authorization Type* > > Similar to (6), XYZ has a single schema for how to request access to a > resource. While that schema is extensible, it requires adaption from any > system with an existing schema. XAuth has a type for each authorization > request (oauth2, rar), allowing existing schemas and new schemas to be > supported. > > > This is a ridiculous claim because the RAR format is a back port of the > XYZ format to an OAuth 2 architecture. If you consider that RAR is > extensible, then XYZ is extensible by your same definitions. In addition, > if there are other resource query languages out there beyond these, and w= e > can support them just like we would support additional claims query > languages. > > Furthermore, as I=E2=80=99ve said before, XAuth doesn=E2=80=99t allow a c= lean way to > define the use of both OAuth 2 scopes and rich requests. XYZ does this by > allowing scope-style strings and full JSON objects to be specified at the > same level in the same data structure, so there=E2=80=99s no confusion ov= er how > they=E2=80=99re grouped or applied. XAuth makes me choose ahead of time t= o use one > or the other, effectively at the API level. So I can no longer easily cal= l > for, say, =E2=80=9Clogin information=E2=80=9D (a general scope) along wit= h =E2=80=9Ctransaction > history for a specific bank account=E2=80=9D (a rich data object) in the = same > request. Even RAR handles this better than XAuth by simply letting the > =E2=80=9Cscope=E2=80=9D parameter also be passed along side the authoriza= tion_details > object, but there are significant complexity issues with this as there > isn=E2=80=99t a clear way to combine these concepts in the OAuth 2 world.= I think > we can do so much better here, and XYZ proposes one such consistent way t= o > do that by defining the scope-equivalent to be a pass-by-reference versio= n > of the rich object that is passed-by-value. If clients have a shortcut (a > scope), they can use that; if they need the expressiveness of the resourc= es > structure, they can do that. > Once again it does not seem that you have read the latest draft. XAuth allows existing OAuth 2 scopes, OR OAuth 2 scopes with RAR, OR a new type authorization type that works differently. > > > *Summary* > > While concerns (3-7) can be addressed in XYZ, (1-2) look fundamental to > the XYZ architecture. > > [1] > https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-7 > > [2] https://w3c.github.io/vc-data-model/ > > > I=E2=80=99m not sure what you intended to bring up about VC=E2=80=99s in = your email, > because I didn=E2=80=99t see a back-reference to this, but I=E2=80=99m gl= ad you did mention > it. This is an example of a query, assertion, and proofing data model for > users that uses a structure and language that is outside of the OIDC worl= d, > but existing parallel to it. > I meant to include [2] as another claim schema in point (6) above. In XAuth, you will see that "vc" is another object in the "claims" Object. > I believe our protocol needs to be flexible enough to allow this kind of > thing on input (the client presenting information about who the user is, = as > well as requesting specific information about the user) and output (the A= S > claiming information about the user), in addition to the client being giv= en > something that it can then in turn use with another service down the line > to present user information. The world is moving away from an IdP-driven > identity model, and we need to keep moving with it and enable it here. > We agree on the flexibility. The XAuth proposal is to namespace the schemas so that adopting existing schemas, or using a new one is straightforward. > > Thanks, > =E2=80=94 Justin > > > =E1=90=A7 > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > =E1=90=A7 --000000000000f3fdee05a7861441 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
comments inline ...

On Sun, Jun 7, 202= 0 at 1:41 PM Justin Richer <jricher@m= it.edu> wrote:
Hi Dick, responses inline.<= br>

On Jun 7, 2020, at 3:27 PM, Dick= Hardt <dick.h= ardt@gmail.com> wrote:

Hello

I have just posed some updates on the XAuth draft:

In -07 I added the XYZ features of interaction negot= iation, and a Client Handle for dynamic clients. I also updated the name to= GNAP, but preserved the draft-hardt-xauth-protocol filename for ease of tr= acking changes.=C2=A0

In -08 I split the doc into:= core protocol, advanced features, and JOSE authentication.=C2=A0


IMHO, th= e main doc is much more readable. :)


I think that renaming your individual draft is p= remature and presumptive, as the WG has not yet decided on an approach for = the WG base draft and renaming one of the input drafts like this is going t= o simply add to confusion when trying to discuss and compare different appr= oaches. I would recommend undoing this name change in order to facilitate d= iscussion going forward, to allow people to refer to one project with a sin= gle name and know what it means.

As you and I have= discussed offline, and as you yourself suggested, it might be beneficial f= or the working group to start from a new draft document incorporating the m= ost important features. Until we reach that point, renaming any of the inpu= t drafts into what the group=E2=80=99s target draft will be is going to cau= se problems.

My intent wa= s to remove confusion, not create confusion. Per my comments below, I refer= to my draft as XAuth, and your draft as XYZ. The filename still has -xauth= - and not -gnap-.=C2=A0

I have pushed a -09 that h= as additional text in the introduction to clarify it should be referred to = as XAuth.=C2=A0


I named the other fil= es with draft-hardt-gnap to make it clear the document is related to the pr= oposed GNAP WG.=C2=A0

=C2=A0

<= div>
XYZ vs XAuth

The r= emaining major differences between XYZ and XAuth are areas I have concerns = about. (I will continue to use XYZ and XAuth refer to each draft). The conc= erns are:

1) API in JSON vs URI and HTTP Verb

In XYZ, all calls are to the same endpoi= nt=C2=A0as an HTTP POST. The AS must parse the JSON to determine what to do= .=C2=A0

XAuth has a RESTful interface. A Grant=C2= =A0Request starts at the GS URI, and Grants and Authorizations are returned= as URI resources. Creating a Grant is done with a POST, reading a Grant is= done with a GET.=C2=A0

With URIs and HTTP verbs, A large= scale GS can easily implement independent services for=C2=A0each=C2=A0 fun= ctionality as routing of requests can be done at the HTTP layer based on th= e URI and HTTP verb. This allows a separation of concerns, independent depl= oyment, and resiliency.

A= s I have said many, many times, both on the list and in the documentation f= or XYZ, this is an area that is worth discussing within the working group. = It=E2=80=99s been tagged a potential direction in XYZ from early days, but = not something that we=E2=80=99ve pursued because it hasn=E2=80=99t been nee= ded in the spaces we=E2=80=99ve used it.

So saying= this is a fundamental aspect of XYZ and implying that it=E2=80=99s a non-s= tarter for it to not be built that way is misdirection. I hope that the con= versation here in this group can continue without you ignoring or dismissin= g previous statements like this as we discuss things.=C2=A0

I'm comparing the two drafts we=C2= =A0have today,=C2=A0not what the drafts could be. You have consistently sta= ted that there is just one end point in the XYZ model, and that handles rep= resent the transaction rather than URIs -- as you state again below in your response to point 4= .

I find it is much easier for people to understan= d a proposal to write it up. I could not see how to easily modify XYZ to su= pport the models I envisioned, which is why I wrote XAuth.
=C2=A0=

Additionally, I find XAuth= =E2=80=99s restrictions on the structure of the Grant URI potentially probl= ematic, namely that it has to start with the server=E2=80=99s URL. This wil= l lead to deployments needing to bend their setups with proxies or redirect= ors to make things fit, which you yourself have said is going to be an issu= e for things like supporting a short redirect URL vs. a long redirect URL. = Your complaint there was one of latency and complexity, why does that not a= pply here? But most fundamentally, I do not see what value this restriction= brings to the system. If the value is coming back from the GS endpoint, an= d the client is getting all of its pointers from there, what=E2=80=99s the = point of dictating how that has to look?

Requiring the Grant URI to start with the GS URI is open to= discussion. It is not clear to me why a deployment would need to have a re= director. Large scale deployments I have worked on have a router / proxy th= at routes requests to internal services. Having all the URIs start with the= GS URI enables all GNAP operations to be routed in the same place.

An advantage of starting with the GS URI is that any soft= ware on the Client side knows which GS it belongs to. A Grant URI passed to= a Client in a GS initiated=C2=A0login allows the Client to know if it trus= ts the GS before operating on the Grant URI.=C2=A0

If the Grant URI can be any URI, then a Client could be tricked into opera= ting on a Grant URI it should not be operating on.=C2=A0
=C2=A0


2) Handles for all Clients vs Client ID and Client Handle

In XYZ, both pre-registered clients and d= ynamic clients use a handle.=C2=A0

In XAuth, the C= lient ID refers to a pre-registered client, and the Client Handle is specif= ic to an instance of a dynamic client. Using separate terms clearly differe= ntiates which identifier is being presented to the GS.=C2=A0

=
This allows a GS to use separate mechanisms for managing pre-reg= istered clients and dynamic clients, an important consideration as there ca= n easily be millions of instances of a single dynamic client.

Additionally, developers are already familiar=C2=A0with wha= t a Client ID is for pre-registered clients.
=

I see the inconsistency in the XAuth draft to be proble= matic. Under this proposed model, I now need to be able to track clients us= ing different kinds of identifiers depending on what kind of registration t= hey used? Why build in this dichotomy?
<= br>
A GS implementation is free to use the same identifiers and s= torage system for Client IDs and Client Handles.=C2=A0
=C2=A0

One of the design goals of XYZ = was to bring consistency to the haphazard world of OAuth 2, where a client = ID could mean a class of client software or an individual client or a clust= er of servers or any number of other things.=C2=A0

In XYZ a client handle refers to both registered = clients, and dynamic clients. That seems to continue to be haphazard.=C2=A0=

Dynamic Registration needed to use Client ID as t= he rest of OAuth only understood that identifier for a client.
XAuth allows each type of client to have their own identifier.=
=C2=A0

And as I= =E2=80=99ve demonstrated with an implementation on top of the MITREid Conne= ct OAuth 2 server, it=E2=80=99s completely possible and well within-protoco= l to pass in a static client ID within the XYZ=E2=80=99s =E2=80=9Ckey handl= e=E2=80=9D field and have things work as expected. Yes, it=E2=80=99s called= something different =E2=80=94 but if that=E2=80=99s a problem, then XAuth= =E2=80=99s renaming of the Authorization Server to a Grant Server is going = to be significantly more confusing for developers, don=E2=80=99t you think?=

Nope.=C2=A0
= =C2=A0


3) Transaction Handles are One Time = Use

In XYZ, transaction handles are one= time use [1]. In the OAuth WG discussion on one time use refresh tokens, c= lients are often distributed across components, which complicates one time = use references.=C2=A0

One time use transaction han= dles also makes them inconsistent with the display, resource, user, and key= handles.

Transacti= on handles being one-time-use is based on experience with a session fixatio= n attack against UMA=C2=A0(now patched):


Clients with distributed comp= onents are going to have to be considered in our core model, and so there a= re considerations and tradeoffs in terms of security and deployability that= we need to address here. These are the same kinds of discussions that we= =E2=80=99re having in OAuth 2, as you point out, and so we can not only app= ly that experience and knowledge to this, but we can build something that b= ehaves better than a refresh token for this purpose.

The XAuth proposal is to use a URI to represent= the authorization.=C2=A0
=C2=A0

<= blockquote type=3D"cite">

= 4) New User Identifier

XYZ introduces a new id= entifier for the user, a User Handle. Unclear why a new type of user identifier is needed, except for th= e desire to have a handle for everything.

=

This is based directly on the = Persisted Claims Token concept from UMA2, where a client (that is trusted t= o make such a statement) can say that it reasonably believes that the curre= nt user interacting with this client is the same user that it=E2=80=99s bee= n interacting with before, for use with a future request. An AS can take th= is signal into consideration when processing the request, potentially avoid= ing unnecessary interaction and friction.

My statement= is that it was unclear why it was needed. Perhaps you can add a Rat= ionale section to XYZ?
=C2=A0
I=E2=80=99m not surprised that you see this as =E2=80=9Cjust ap= plying a handle for everything=E2=80=9D considering you=E2=80=99ve previous= ly objected to the use of the pass-by-reference construct for other aspects= of the protocol in the past as well. Each component in XYZ that has a sepa= rate handle has one for specific and documented reasons, and it=E2=80=99s a= core feature that these ar= e handled (pun intended) in a consistent and predictable manner.

This is why I state that it seems hard to change= (1) above.=C2=A0
=C2=A0

5) Interaction Ca= pabilities vs Modes

In XYZ, the cap= abilities are expressed by the client, and the GS states which capabilities= it will accept. This can make it difficult for the GS to enforce the inter= action choices as the client can mix and match which capabilities are retur= ned. For example, a GS may not want to support a redirect without a callbac= k to protect itself from session fixation attacks. In XAuth, the interactio= n modes provide clarity on the mode of interaction and the security propert= ies. For example the GS may support both user_code and redirect modes, but = not the indirect mode which is subject to session fixation attacks.


If the GS = doesn=E2=80=99t want to accept a redirect without a callback, it can becaus= e the request will have a redirect, but not a callback, and it can reject t= he request. What makes you believe that this is not detectable or not possi= ble in XYZ?=C2=A0

I did n= ot say it could not be done, I'm saying it is more difficult in XYZ tha= n in XAuth
=C2=A0

= The modes in XAuth are much more limiting, as the mixing of different inter= action methods is already something that we need to start figuring out. Let= =E2=80=99s say, for example, a client can do a redirect, accept a CIBA-styl= e ping, or do a direct app2app communication. There=E2=80=99s a natural pre= ference the client will have here: if it can talk to another app directly, = it=E2=80=99ll try that first. If that doesn=E2=80=99t work, it can get a pu= sh notification sent, and if all that fails, it can pop open a browser. If = I have to pick just one of those modes when I make the request, then the cl= ient needs to make three different requests to the AS before I get anything= that works.=C2=A0

Have y= ou read the revised draft? As I noted above, I have added negotiation. The = Client can state all the modes it wants, the GS can respond with the modes = it will support, and the Client can offer the User any modes returned from = the GS.
=C2=A0

Thi= s kind of mixing is important to allow for different modalities of client. = In fact, the return callback could be tied to the entry of a user code, not= just an outbound redirect. How the client gets the user to the AS and how = the user gets back are separate questions, and we need flexibility in both.=

Yes, we need flexibility= . We also need the GS to be able to easily enforce what can happen.
=C2=A0
XAuth ties them together in the = same way that OAuth 2 does, and this is an unnecessary restriction that doe= s not add security or simplicity.

<= div dir=3D"ltr">
6) Claims at Top Level vs Namespaced=C2=A0
<= /div>

In XYZ, there is one schema for claims, and= they are requested as:

=C2=A0 =C2=A0"claims&= quot;: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0"subject": true,
=C2=A0= =C2=A0 =C2=A0 =C2=A0"email": true
=C2=A0 =C2=A0}

Whereas in XAuth, claims are in their own namespace:
=

=C2=A0 =C2=A0 "claims": {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 "oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "id_token" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 "email" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "= ;essential" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "email_verified" : { "essential" : true }=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 "userinfo" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name" =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 : { "essential" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 "picture" =C2=A0 =C2=A0 =C2=A0 =C2=A0= : null
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 }

In this example, the clien= t is requesting OIDC defined claims, the email to be in an ID Token, and th= e name and picture to be as text. While the XYZ schema may be extended, the= re are already numerous schemas being used. The XAuth approach is to suppor= t existing and new schemas,=C2=A0rather than pick one and/or create another= one, and allows a Grant Request to contain claims from multiple schemas at= the same time.

Again, as= I have said many times, this part of the request (as is the rest of the re= quest) is extensible. The goal of the =E2=80=9Cclaims=E2=80=9D object in XY= Z was to propose a simple, common core. Is this the best set? Probably not,= but that=E2=80=99s why nothing is final yet, right?=C2=A0

Yes, XYZ is extensible. It is not namespa= ced as XAuth is.
=C2=A0

If we wanted to allow for OIDC style claims objects, we have space to= do exactly that, either as a sub-component of the existing claims object o= r as a new top-level object in the request. This flexibility is important, = as there are other schemas and other query languages that people might want= to support, including things like JWM:


And at Mike Jones=E2=80=99s request, I=E2=80=99ve added notes in the curre= nt draft of XYZ to the places that will be extensible via registry or some = other mechanism =E2=80=94 but the goal was to have everything in there be e= xtensible by reasonable mechanisms in ways that will allow innovation to fl= ourish without breaking core and common functionality.=C2=A0

=
I do not understand why you insist on painting XYZ as a static, = inflexible, and unbending model when it is exactly the opposite. You don=E2= =80=99t have to externalize every piece of flexibility in order to have it,= and I really hope that these myths don=E2=80=99t keep getting repeated in = the group.

All I am doing= is comparing what is written. I'm not trying to paint XYZ anything.=C2= =A0
=C2=A0


7) No Authorization Typ= e

Similar to (6), XYZ has a single schema = for how to request access to a resource. While that schema is extensible, i= t requires adaption=C2=A0from any system with an existing schema. XAuth has= a type for each authorization request (oauth2, rar), allowing existing sch= emas and new schemas to be supported.
This is a ridiculous claim because the RAR format is a back po= rt of the XYZ format to an OAuth 2 architecture. If you consider that RAR i= s extensible, then XYZ is extensible by your same definitions. In addition,= if there are other resource query languages out there beyond these, and we= can support them just like we would support additional claims query langua= ges.=C2=A0

Furthermore, as I=E2=80=99ve said befor= e, XAuth doesn=E2=80=99t allow a clean way to define the use of both OAuth = 2 scopes and rich requests. XYZ does this by allowing scope-style strings a= nd full JSON objects to be specified at the same level in the same data str= ucture, so there=E2=80=99s no confusion over how they=E2=80=99re grouped or= applied. XAuth makes me choose ahead of time to use one or the other, effe= ctively at the API level. So I can no longer easily call for, say, =E2=80= =9Clogin information=E2=80=9D (a general scope) along with =E2=80=9Ctransac= tion history for a specific bank account=E2=80=9D (a rich data object) in t= he same request. Even RAR handles this better than XAuth by simply letting = the =E2=80=9Cscope=E2=80=9D parameter also be passed along side the authori= zation_details object, but there are significant complexity issues with thi= s as there isn=E2=80=99t a clear way to combine these concepts in the OAuth= 2 world. I think we can do so much better here, and XYZ proposes one such = consistent way to do that by defining the scope-equivalent to be a pass-by-= reference version of the rich object that is passed-by-value. If clients ha= ve a shortcut (a scope), they can use that; if they need the expressiveness= of the resources structure, they can do that.=C2=A0

Once again it does not seem that you have read = the latest draft. XAuth allows existing OAuth 2 scopes, OR OAuth 2 scopes w= ith RAR, OR a new type authorization type that works differently.

=C2=A0


Summary
While concerns (3-7) can be addressed in XYZ, (1-2)=C2=A0look f= undamental to the XYZ architecture.



I=E2= =80=99m not sure what you intended to bring up about VC=E2=80=99s in your e= mail, because I didn=E2=80=99t see a back-reference to this, but I=E2=80=99= m glad you did mention it. This is an example of a query, assertion, and pr= oofing data model for users that uses a structure and language that is outs= ide of the OIDC world, but existing parallel to it.

I meant to include [2] as another claim schema = in point (6) above. In XAuth, you will see that "vc" is another o= bject in the "claims" Object.
=C2=A0
I believe our protocol needs to be flexible enough to allow t= his kind of thing on input (the client presenting information about who the= user is, as well as requesting specific information about the user) and ou= tput (the AS claiming information about the user), in addition to the clien= t being given something that it can then in turn use with another service d= own the line to present user information. The world is moving away from an = IdP-driven identity model, and we need to keep moving with it and enable it= here.

We agree on the fl= exibility. The XAuth proposal is to namespace the schemas so that adopting = existing schemas, or using a new one is straightforward.



Thanks,
=C2=A0=E2=80=94 Justin


3D""=E1=90=A7
--000000000000f3fdee05a7861441-- From nobody Sun Jun 7 18:09:30 2020 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 046703A089D for ; Sun, 7 Jun 2020 18:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 A_eC_lLKOBWB for ; Sun, 7 Jun 2020 18:09:25 -0700 (PDT) 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 B44063A089C for ; Sun, 7 Jun 2020 18:09:24 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id u16so9177854lfl.8 for ; Sun, 07 Jun 2020 18:09:24 -0700 (PDT) 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=wXp+4+FRAdlaxjAodODeaI1Y3/VqMoG3EcAUQBOdNfQ=; b=myGDyBLkWnM88+54gJ+6BjXtVRZ4piGuDFfkIwi+Tu0/Q8k1tdPWxddv16ASMlJdWS imeniS75Rku4jAKH53hdZRAy96tkT1VkTqKjOT5cjuEG/GbK+4kZebkxZtCEOGfI2D8Y apb+O2uE6+T9y8g9mlt87Gqvo6vPBtRVPj0NBa9os+zNGC3DeaBfanCZ7plNkeMJKF15 RIGvKCQ2DzGm5MHSomNqWUWUoyU6lJJ6kpwZlvehBAZn5qfhCmBly5MjIStCREY+Kg41 baOUNfcmE74vkNyGTdQP//CrhLzWgAfhH9cHSIVjOQh0z2J8LO6nehyBkp2vMVX3L+J4 xMjw== 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=wXp+4+FRAdlaxjAodODeaI1Y3/VqMoG3EcAUQBOdNfQ=; b=Iqco4gYNMGqVLFHWB0b77E0XNovkwj8AqNC/LdhFQaNNtUo7OxP6CMQ2rgrpgGpaQa JOvGtj416Yn9K3x8TuyFG+HpT+YOQHdIANOLcl6X7Ab3ThVD3GAgb8/kJqVHDI7Y6v5M FQBDLDTgw7nVCt9UAqZYoT2MpzQ88X2ZK4qqQCV7autenJj02LwZ4jwdumqMHyyD3oAH SdA/O4g5HheGtubbS4rvaKcaYXbF6D6xDN1TGERVELtOfhju6+Kbi78ndvn5kfGk/fJm Ehp3+y4eo8R/rsPaWkxqusUOYMPwXV1blSX6pLo37FlpDFTz71nKfOhNU4DFGr9r+MU5 j+NA== X-Gm-Message-State: AOAM5324kuUhNpMsL+0I02DeNlGF/sslufOUCnqrgoDV5ycishYg6KhZ Gfc1zo7KNIqzdN0j2C5gdS4us/7fVLkrq7GZAGcNdUGH X-Google-Smtp-Source: ABdhPJy4Y7jm+Dr2OWBAvjSOmVJR1svvndIAQQIM0L2tErkyMuwzG+PT0cWvrN3rX9kLsw8WYR1p3ARjlxafyNJQeik= X-Received: by 2002:a05:6512:2023:: with SMTP id s3mr11477536lfs.78.1591578561036; Sun, 07 Jun 2020 18:09:21 -0700 (PDT) MIME-Version: 1.0 References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> In-Reply-To: From: Dick Hardt Date: Sun, 7 Jun 2020 18:08:54 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000c3493a05a788422c" Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 08 Jun 2020 01:09:29 -0000 --000000000000c3493a05a788422c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd be interested to see how you address any of the concerns you think have merit with an update to XYZ. I think it would also be useful for the group to adopt the terms Grant and Negotiation rather than Transaction in your doc to reflect the terms the WG has settled on. /Dick =E1=90=A7 On Sun, Jun 7, 2020 at 3:32 PM Dick Hardt wrote: > comments inline ... > > On Sun, Jun 7, 2020 at 1:41 PM Justin Richer wrote: > >> Hi Dick, responses inline. >> >> On Jun 7, 2020, at 3:27 PM, Dick Hardt wrote: >> >> Hello >> >> I have just posed some updates on the XAuth draft: >> >> In -07 I added the XYZ features of interaction negotiation, and a Client >> Handle for dynamic clients. I also updated the name to GNAP, but preserv= ed >> the draft-hardt-xauth-protocol filename for ease of tracking changes. >> >> In -08 I split the doc into: core protocol, advanced features, and JOSE >> authentication. >> >> https://www.ietf.org/id/draft-hardt-xauth-protocol-08.html >> https://www.ietf.org/id/draft-hardt-gnap-advanced-00.html >> https://www.ietf.org/id/draft-hardt-gnap-jose-00.html >> >> IMHO, the main doc is much more readable. :) >> >> >> I think that renaming your individual draft is premature and presumptive= , >> as the WG has not yet decided on an approach for the WG base draft and >> renaming one of the input drafts like this is going to simply add to >> confusion when trying to discuss and compare different approaches. I wou= ld >> recommend undoing this name change in order to facilitate discussion goi= ng >> forward, to allow people to refer to one project with a single name and >> know what it means. >> >> As you and I have discussed offline, and as you yourself suggested, it >> might be beneficial for the working group to start from a new draft >> document incorporating the most important features. Until we reach that >> point, renaming any of the input drafts into what the group=E2=80=99s ta= rget draft >> will be is going to cause problems. >> > > My intent was to remove confusion, not create confusion. Per my comments > below, I refer to my draft as XAuth, and your draft as XYZ. The filename > still has -xauth- and not -gnap-. > > I have pushed a -09 that has additional text in the introduction to > clarify it should be referred to as XAuth. > > https://www.ietf.org/id/draft-hardt-xauth-protocol-09.html > > I named the other files with draft-hardt-gnap to make it clear the > document is related to the proposed GNAP WG. > > > >> >> >> *XYZ vs XAuth* >> >> The remaining major differences between XYZ and XAuth are areas I have >> concerns about. (I will continue to use XYZ and XAuth refer to each draf= t). >> The concerns are: >> >> *1) API in JSON vs URI and HTTP Verb* >> >> In XYZ, all calls are to the same endpoint as an HTTP POST. The AS must >> parse the JSON to determine what to do. >> >> XAuth has a RESTful interface. A Grant Request starts at the GS URI, and >> Grants and Authorizations are returned as URI resources. Creating a Gran= t >> is done with a POST, reading a Grant is done with a GET. >> >> With URIs and HTTP verbs, A large scale GS can easily implement >> independent services for each functionality as routing of requests can = be >> done at the HTTP layer based on the URI and HTTP verb. This allows a >> separation of concerns, independent deployment, and resiliency. >> >> >> As I have said many, many times, both on the list and in the >> documentation for XYZ, this is an area that is worth discussing within t= he >> working group. It=E2=80=99s been tagged a potential direction in XYZ fro= m early >> days, but not something that we=E2=80=99ve pursued because it hasn=E2=80= =99t been needed in >> the spaces we=E2=80=99ve used it. >> >> So saying this is a fundamental aspect of XYZ and implying that it=E2=80= =99s a >> non-starter for it to not be built that way is misdirection. I hope that >> the conversation here in this group can continue without you ignoring or >> dismissing previous statements like this as we discuss things. >> > > I'm comparing the two drafts we have today, not what the drafts could be. > You have consistently stated that there is just one end point in the XYZ > model, and that handles represent the transaction rather than URIs -- as = you > state again below in your response to point 4. > > I find it is much easier for people to understand a proposal to write it > up. I could not see how to easily modify XYZ to support the models I > envisioned, which is why I wrote XAuth. > > >> >> Additionally, I find XAuth=E2=80=99s restrictions on the structure of th= e Grant >> URI potentially problematic, namely that it has to start with the server= =E2=80=99s >> URL. This will lead to deployments needing to bend their setups with >> proxies or redirectors to make things fit, which you yourself have said = is >> going to be an issue for things like supporting a short redirect URL vs.= a >> long redirect URL. Your complaint there was one of latency and complexit= y, >> why does that not apply here? But most fundamentally, I do not see what >> value this restriction brings to the system. If the value is coming back >> from the GS endpoint, and the client is getting all of its pointers from >> there, what=E2=80=99s the point of dictating how that has to look? >> > > Requiring the Grant URI to start with the GS URI is open to discussion. I= t > is not clear to me why a deployment would need to have a redirector. Larg= e > scale deployments I have worked on have a router / proxy that routes > requests to internal services. Having all the URIs start with the GS URI > enables all GNAP operations to be routed in the same place. > > An advantage of starting with the GS URI is that any software on the > Client side knows which GS it belongs to. A Grant URI passed to a Client = in > a GS initiated login allows the Client to know if it trusts the GS before > operating on the Grant URI. > > If the Grant URI can be any URI, then a Client could be tricked into > operating on a Grant URI it should not be operating on. > > >> >> >> *2) Handles for all Clients vs Client ID and Client Handle* >> >> In XYZ, both pre-registered clients and dynamic clients use a handle. >> >> In XAuth, the Client ID refers to a pre-registered client, and the Clien= t >> Handle is specific to an instance of a dynamic client. Using separate te= rms >> clearly differentiates which identifier is being presented to the GS. >> >> This allows a GS to use separate mechanisms for managing pre-registered >> clients and dynamic clients, an important consideration as there can eas= ily >> be millions of instances of a single dynamic client. >> >> Additionally, developers are already familiar with what a Client ID is >> for pre-registered clients. >> >> >> I see the inconsistency in the XAuth draft to be problematic. Under this >> proposed model, I now need to be able to track clients using different >> kinds of identifiers depending on what kind of registration they used? W= hy >> build in this dichotomy? >> > > A GS implementation is free to use the same identifiers and storage syste= m > for Client IDs and Client Handles. > > >> >> One of the design goals of XYZ was to bring consistency to the haphazard >> world of OAuth 2, where a client ID could mean a class of client softwar= e >> or an individual client or a cluster of servers or any number of other >> things. >> > > In XYZ a client handle refers to both registered clients, and dynamic > clients. That seems to continue to be haphazard. > > Dynamic Registration needed to use Client ID as the rest of OAuth only > understood that identifier for a client. > > XAuth allows each type of client to have their own identifier. > > >> >> And as I=E2=80=99ve demonstrated with an implementation on top of the MI= TREid >> Connect OAuth 2 server, it=E2=80=99s completely possible and well within= -protocol >> to pass in a static client ID within the XYZ=E2=80=99s =E2=80=9Ckey hand= le=E2=80=9D field and have >> things work as expected. Yes, it=E2=80=99s called something different = =E2=80=94 but if >> that=E2=80=99s a problem, then XAuth=E2=80=99s renaming of the Authoriza= tion Server to a >> Grant Server is going to be significantly more confusing for developers, >> don=E2=80=99t you think? >> > > Nope. > > >> >> >> *3) Transaction Handles are One Time Use* >> >> In XYZ, transaction handles are one time use [1]. In the OAuth WG >> discussion on one time use refresh tokens, clients are often distributed >> across components, which complicates one time use references. >> >> One time use transaction handles also makes them inconsistent with the >> display, resource, user, and key handles. >> >> >> Transaction handles being one-time-use is based on experience with a >> session fixation attack against UMA (now patched): >> >> >> https://kantarainitiative.org/confluence/display/uma/Understanding+the+S= ession+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+Mitigation >> >> Clients with distributed components are going to have to be considered i= n >> our core model, and so there are considerations and tradeoffs in terms o= f >> security and deployability that we need to address here. These are the s= ame >> kinds of discussions that we=E2=80=99re having in OAuth 2, as you point = out, and so >> we can not only apply that experience and knowledge to this, but we can >> build something that behaves better than a refresh token for this purpos= e. >> > > The XAuth proposal is to use a URI to represent the authorization. > > >> >> >> *4) New User Identifier* >> >> XYZ introduces a new identifier for the user, a User Handle. Unclear why >> a new type of user identifier is needed, except for the desire to have a >> handle for everything. >> >> >> This is based directly on the Persisted Claims Token concept from UMA2, >> where a client (that is trusted to make such a statement) can say that i= t >> reasonably believes that the current user interacting with this client i= s >> the same user that it=E2=80=99s been interacting with before, for use wi= th a future >> request. An AS can take this signal into consideration when processing t= he >> request, potentially avoiding unnecessary interaction and friction. >> > > My statement is that it was unclear why it was needed. Perhaps you can > add a Rationale section to XYZ? > > >> >> I=E2=80=99m not surprised that you see this as =E2=80=9Cjust applying a = handle for >> everything=E2=80=9D considering you=E2=80=99ve previously objected to th= e use of the >> pass-by-reference construct for other aspects of the protocol in the pas= t >> as well. Each component in XYZ that has a separate handle has one for >> specific and documented reasons, and it=E2=80=99s a core feature that th= ese are >> handled (pun intended) in a consistent and predictable manner. >> > > This is why I state that it seems hard to change (1) above. > > >> >> *5) Interaction Capabilities vs Modes* >> >> In XYZ, the capabilities are expressed by the client, and the GS states >> which capabilities it will accept. This can make it difficult for the GS= to >> enforce the interaction choices as the client can mix and match which >> capabilities are returned. For example, a GS may not want to support a >> redirect without a callback to protect itself from session fixation >> attacks. In XAuth, the interaction modes provide clarity on the mode of >> interaction and the security properties. For example the GS may support >> both user_code and redirect modes, but not the indirect mode which is >> subject to session fixation attacks. >> >> >> If the GS doesn=E2=80=99t want to accept a redirect without a callback, = it can >> because the request will have a redirect, but not a callback, and it can >> reject the request. What makes you believe that this is not detectable o= r >> not possible in XYZ? >> > > I did not say it could not be done, I'm saying it is more difficult in XY= Z > than in XAuth > > >> >> The modes in XAuth are much more limiting, as the mixing of different >> interaction methods is already something that we need to start figuring >> out. Let=E2=80=99s say, for example, a client can do a redirect, accept = a >> CIBA-style ping, or do a direct app2app communication. There=E2=80=99s a= natural >> preference the client will have here: if it can talk to another app >> directly, it=E2=80=99ll try that first. If that doesn=E2=80=99t work, it= can get a push >> notification sent, and if all that fails, it can pop open a browser. If = I >> have to pick just one of those modes when I make the request, then the >> client needs to make three different requests to the AS before I get >> anything that works. >> > > Have you read the revised draft? As I noted above, I have added > negotiation. The Client can state all the modes it wants, the GS can > respond with the modes it will support, and the Client can offer the User > any modes returned from the GS. > > >> >> This kind of mixing is important to allow for different modalities of >> client. In fact, the return callback could be tied to the entry of a use= r >> code, not just an outbound redirect. How the client gets the user to the= AS >> and how the user gets back are separate questions, and we need flexibili= ty >> in both. >> > > Yes, we need flexibility. We also need the GS to be able to easily enforc= e > what can happen. > > >> XAuth ties them together in the same way that OAuth 2 does, and this is >> an unnecessary restriction that does not add security or simplicity. >> >> *6) Claims at Top Level vs Namespaced * >> >> In XYZ, there is one schema for claims, and they are requested as: >> >> "claims": { >> "subject": true, >> "email": true >> } >> >> Whereas in XAuth, claims are in their own namespace: >> >> "claims": { >> "oidc": { >> "id_token" : { >> "email" : { "essential" : true }, >> "email_verified" : { "essential" : true } >> }, >> "userinfo" : { >> "name" : { "essential" : true }, >> "picture" : null >> } >> } >> >> In this example, the client is requesting OIDC defined claims, the email >> to be in an ID Token, and the name and picture to be as text. While the = XYZ >> schema may be extended, there are already numerous schemas being used. T= he >> XAuth approach is to support existing and new schemas, rather than pick = one >> and/or create another one, and allows a Grant Request to contain claims >> from multiple schemas at the same time. >> >> >> Again, as I have said many times, this part of the request (as is the >> rest of the request) is extensible. The goal of the =E2=80=9Cclaims=E2= =80=9D object in XYZ >> was to propose a simple, common core. Is this the best set? Probably not= , >> but that=E2=80=99s why nothing is final yet, right? >> > > Yes, XYZ is extensible. It is not namespaced as XAuth is. > > >> >> If we wanted to allow for OIDC style claims objects, we have space to do >> exactly that, either as a sub-component of the existing claims object or= as >> a new top-level object in the request. This flexibility is important, as >> there are other schemas and other query languages that people might want= to >> support, including things like JWM: >> >> https://tools.ietf.org/id/draft-looker-jwm-01.html >> >> And at Mike Jones=E2=80=99s request, I=E2=80=99ve added notes in the cur= rent draft of XYZ >> to the places that will be extensible via registry or some other mechani= sm >> =E2=80=94 but the goal was to have everything in there be extensible by = reasonable >> mechanisms in ways that will allow innovation to flourish without breaki= ng >> core and common functionality. >> >> I do not understand why you insist on painting XYZ as a static, >> inflexible, and unbending model when it is exactly the opposite. You don= =E2=80=99t >> have to externalize every piece of flexibility in order to have it, and = I >> really hope that these myths don=E2=80=99t keep getting repeated in the = group. >> > > All I am doing is comparing what is written. I'm not trying to paint XYZ > anything. > > >> >> >> *7) No Authorization Type* >> >> Similar to (6), XYZ has a single schema for how to request access to a >> resource. While that schema is extensible, it requires adaption from any >> system with an existing schema. XAuth has a type for each authorization >> request (oauth2, rar), allowing existing schemas and new schemas to be >> supported. >> >> >> This is a ridiculous claim because the RAR format is a back port of the >> XYZ format to an OAuth 2 architecture. If you consider that RAR is >> extensible, then XYZ is extensible by your same definitions. In addition= , >> if there are other resource query languages out there beyond these, and = we >> can support them just like we would support additional claims query >> languages. >> >> Furthermore, as I=E2=80=99ve said before, XAuth doesn=E2=80=99t allow a = clean way to >> define the use of both OAuth 2 scopes and rich requests. XYZ does this b= y >> allowing scope-style strings and full JSON objects to be specified at th= e >> same level in the same data structure, so there=E2=80=99s no confusion o= ver how >> they=E2=80=99re grouped or applied. XAuth makes me choose ahead of time = to use one >> or the other, effectively at the API level. So I can no longer easily ca= ll >> for, say, =E2=80=9Clogin information=E2=80=9D (a general scope) along wi= th =E2=80=9Ctransaction >> history for a specific bank account=E2=80=9D (a rich data object) in the= same >> request. Even RAR handles this better than XAuth by simply letting the >> =E2=80=9Cscope=E2=80=9D parameter also be passed along side the authoriz= ation_details >> object, but there are significant complexity issues with this as there >> isn=E2=80=99t a clear way to combine these concepts in the OAuth 2 world= . I think >> we can do so much better here, and XYZ proposes one such consistent way = to >> do that by defining the scope-equivalent to be a pass-by-reference versi= on >> of the rich object that is passed-by-value. If clients have a shortcut (= a >> scope), they can use that; if they need the expressiveness of the resour= ces >> structure, they can do that. >> > > Once again it does not seem that you have read the latest draft. XAuth > allows existing OAuth 2 scopes, OR OAuth 2 scopes with RAR, OR a new type > authorization type that works differently. > > > >> >> >> *Summary* >> >> While concerns (3-7) can be addressed in XYZ, (1-2) look fundamental to >> the XYZ architecture. >> >> [1] >> https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-= 7 >> >> [2] https://w3c.github.io/vc-data-model/ >> >> >> I=E2=80=99m not sure what you intended to bring up about VC=E2=80=99s in= your email, >> because I didn=E2=80=99t see a back-reference to this, but I=E2=80=99m g= lad you did mention >> it. This is an example of a query, assertion, and proofing data model fo= r >> users that uses a structure and language that is outside of the OIDC wor= ld, >> but existing parallel to it. >> > > I meant to include [2] as another claim schema in point (6) above. In > XAuth, you will see that "vc" is another object in the "claims" Object. > > >> I believe our protocol needs to be flexible enough to allow this kind of >> thing on input (the client presenting information about who the user is,= as >> well as requesting specific information about the user) and output (the = AS >> claiming information about the user), in addition to the client being gi= ven >> something that it can then in turn use with another service down the lin= e >> to present user information. The world is moving away from an IdP-driven >> identity model, and we need to keep moving with it and enable it here. >> > > We agree on the flexibility. The XAuth proposal is to namespace the > schemas so that adopting existing schemas, or using a new one is > straightforward. > > >> >> Thanks, >> =E2=80=94 Justin >> >> >> =E1=90=A7 >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> =E1=90=A7 > --000000000000c3493a05a788422c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd be interested to see how you address any of the co= ncerns you think have merit with an update to XYZ. I think it would also be= useful for the group to adopt the terms Grant and Negotiation rather than = Transaction in your doc to reflect the terms the WG has settled on.
/Dick
3D""=E1=90=A7

On Sun, Jun 7, 2020 = at 3:32 PM Dick Hardt <dick.hard= t@gmail.com> wrote:
comments inline ...
<= br>
On Sun,= Jun 7, 2020 at 1:41 PM Justin Richer <jricher@mit.edu> wrote:
Hi Dick, responses inline.
=
On Jun 7, 2020, at 3:27 PM, Dick Hardt &= lt;dick.hardt@gma= il.com> wrote:

Hello
<= br>
I have just posed some updates on the XAuth draft:
=
In -07 I added the XYZ features of interaction negotiation, = and a Client Handle for dynamic clients. I also updated the name to GNAP, b= ut preserved the draft-hardt-xauth-protocol filename for ease of tracking c= hanges.=C2=A0

In -08 I split the doc into: core pr= otocol, advanced features, and JOSE authentication.=C2=A0
<= div>
I think that renaming your individual draft is premature= and presumptive, as the WG has not yet decided on an approach for the WG b= ase draft and renaming one of the input drafts like this is going to simply= add to confusion when trying to discuss and compare different approaches. = I would recommend undoing this name change in order to facilitate discussio= n going forward, to allow people to refer to one project with a single name= and know what it means.

As you and I have discuss= ed offline, and as you yourself suggested, it might be beneficial for the w= orking group to start from a new draft document incorporating the most impo= rtant features. Until we reach that point, renaming any of the input drafts= into what the group=E2=80=99s target draft will be is going to cause probl= ems.

My intent was to rem= ove confusion, not create confusion. Per my comments below, I refer to my d= raft as XAuth, and your draft as XYZ. The filename still has -xauth- and no= t -gnap-.=C2=A0

I have pushed a -09 that has addit= ional text in the introduction to clarify it should be referred to as XAuth= .=C2=A0


I named the= other files with draft-hardt-gnap to make it clear the document is related= to the proposed GNAP WG.=C2=A0

=C2=A0


XYZ vs XAuth

The remaining major differences = between XYZ and XAuth are areas I have concerns about. (I will continue to = use XYZ and XAuth refer to each draft). The concerns are:

1) API in JSON vs URI and HTTP Verb

In XYZ, all calls are to the same endpoint=C2=A0as an HTTP POST. Th= e AS must parse the JSON to determine what to do.=C2=A0

XAuth has a RESTful interface. A Grant=C2=A0Request starts at the GS = URI, and Grants and Authorizations are returned as URI resources. Creating = a Grant is done with a POST, reading a Grant is done with a GET.=C2=A0
<= br>
With URIs and HTTP verbs, A large scale GS can easily impleme= nt independent services for=C2=A0each=C2=A0 functionality as routing of req= uests can be done at the HTTP layer based on the URI and HTTP verb. This al= lows a separation of concerns, independent deployment, and resiliency.

As I have said many, many tim= es, both on the list and in the documentation for XYZ, this is an area that= is worth discussing within the working group. It=E2=80=99s been tagged a p= otential direction in XYZ from early days, but not something that we=E2=80= =99ve pursued because it hasn=E2=80=99t been needed in the spaces we=E2=80= =99ve used it.

So saying this is a fundamental asp= ect of XYZ and implying that it=E2=80=99s a non-starter for it to not be bu= ilt that way is misdirection. I hope that the conversation here in this gro= up can continue without you ignoring or dismissing previous statements like= this as we discuss things.=C2=A0

I'm comparing the two drafts we=C2=A0have today,=C2=A0not what= the drafts could be. You have consistently stated that there is just one e= nd point in the XYZ model, and that handles represent the transaction rathe= r than URIs -- as you state= again below in your response to point 4.

I= find it is much easier for people to understand a proposal to write it up.= I could not see how to easily modify XYZ to support the models I envisione= d, which is why I wrote XAuth.
=C2=A0

Additionally, I f= ind XAuth=E2=80=99s restrictions on the structure of the Grant URI potentia= lly problematic, namely that it has to start with the server=E2=80=99s URL.= This will lead to deployments needing to bend their setups with proxies or= redirectors to make things fit, which you yourself have said is going to b= e an issue for things like supporting a short redirect URL vs. a long redir= ect URL. Your complaint there was one of latency and complexity, why does t= hat not apply here? But most fundamentally, I do not see what value this re= striction brings to the system. If the value is coming back from the GS end= point, and the client is getting all of its pointers from there, what=E2=80= =99s the point of dictating how that has to look?

Requiring the Grant URI to start with the GS URI i= s open to discussion. It is not clear to me why a deployment would need to = have a redirector. Large scale deployments I have worked on have a router /= proxy that routes requests to internal services. Having all the URIs start= with the GS URI enables all GNAP operations to be routed in the same place= .

An advantage of starting with the GS URI is that= any software on the Client side knows which GS it belongs to. A Grant URI = passed to a Client in a GS initiated=C2=A0login allows the Client to know i= f it trusts the GS before operating on the Grant URI.=C2=A0

<= /div>
If the Grant URI can be any URI, then a Client could be tricked i= nto operating on a Grant URI it should not be operating on.=C2=A0
=C2=A0

2) Handles fo= r all Clients vs Client ID and Client Handle

In XYZ, both pre-registered clients and dynamic clients use a handle.= =C2=A0

In XAuth, the Client ID refers to a pre-reg= istered client, and the Client Handle is specific to an instance of a dynam= ic client. Using separate terms clearly differentiates which identifier is = being presented to the GS.=C2=A0

This allows a GS = to use separate mechanisms for managing pre-registered clients and dynamic = clients, an important consideration as there can easily be millions of inst= ances of a single dynamic client.

Additionally= , developers are already familiar=C2=A0with what a Client ID is for pre-reg= istered clients.

I see th= e inconsistency in the XAuth draft to be problematic. Under this proposed m= odel, I now need to be able to track clients using different kinds of ident= ifiers depending on what kind of registration they used? Why build in this = dichotomy?

A GS implement= ation is free to use the same identifiers and storage system for Client IDs= and Client Handles.=C2=A0
=C2=A0

One of the design goa= ls of XYZ was to bring consistency to the haphazard world of OAuth 2, where= a client ID could mean a class of client software or an individual client = or a cluster of servers or any number of other things.=C2=A0

In XYZ a client handle refers to both r= egistered clients, and dynamic clients. That seems to continue to be haphaz= ard.=C2=A0

Dynamic Registration needed to use Clie= nt ID as the rest of OAuth only understood that identifier for a client.

XAuth allows each type of client to have their own i= dentifier.
=C2=A0

And as I=E2=80=99ve demonstrated with= an implementation on top of the MITREid Connect OAuth 2 server, it=E2=80= =99s completely possible and well within-protocol to pass in a static clien= t ID within the XYZ=E2=80=99s =E2=80=9Ckey handle=E2=80=9D field and have t= hings work as expected. Yes, it=E2=80=99s called something different =E2=80= =94 but if that=E2=80=99s a problem, then XAuth=E2=80=99s renaming of the A= uthorization Server to a Grant Server is going to be significantly more con= fusing for developers, don=E2=80=99t you think?

Nope.=C2=A0
=C2=A0


3) Transaction Handles are O= ne Time Use

In XYZ, transaction handles= are one time use [1]. In the OAuth WG discussion on one time use refresh t= okens, clients are often distributed across components, which complicates o= ne time use references.=C2=A0

One time use transac= tion handles also makes them inconsistent with the display, resource, user,= and key handles.

T= ransaction handles being one-time-use is based on experience with a session= fixation attack against UMA=C2=A0(now patched):

<= a href=3D"https://kantarainitiative.org/confluence/display/uma/Understandin= g+the+Session+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+Miti= gation" target=3D"_blank">https://kantarainitiative.org/confluence/display/= uma/Understanding+the+Session+Fixation+Attack+on+UMA+Claims-Gathering+and+t= he+Provided+Mitigation

Clients with distribute= d components are going to have to be considered in our core model, and so t= here are considerations and tradeoffs in terms of security and deployabilit= y that we need to address here. These are the same kinds of discussions tha= t we=E2=80=99re having in OAuth 2, as you point out, and so we can not only= apply that experience and knowledge to this, but we can build something th= at behaves better than a refresh token for this purpose.
<= /blockquote>

The XAuth proposal is to use a URI to repre= sent the authorization.=C2=A0
=C2=A0


4) New User Identifier
<= div>
XYZ introduces a new identifier for the user, a User Han= dle. Unclear why a new type o= f user identifier is needed, except for the desire to have a handle for eve= rything.

This is based directly on the Persisted Claims Token concept fr= om UMA2, where a client (that is trusted to make such a statement) can say = that it reasonably believes that the current user interacting with this cli= ent is the same user that it=E2=80=99s been interacting with before, for us= e with a future request. An AS can take this signal into consideration when= processing the request, potentially avoiding unnecessary interaction and f= riction.

My statement is that it was unclear = why it was needed. Perhaps you can add a Rationale section to XYZ?
=C2=A0
<= div>
I=E2=80=99m not surprised that you see this as =E2=80=9C= just applying a handle for everything=E2=80=9D considering you=E2=80=99ve p= reviously objected to the use of the pass-by-reference construct for other = aspects of the protocol in the past as well. Each component in XYZ that has= a separate handle has one for specific and documented reasons, and it=E2= =80=99s a core feature that= these are handled (pun intended) in a consistent and predictable manner.

This is why I state that it seems hard = to change (1) above.=C2=A0
=C2=A0

5) Interaction Capabilities vs Modes
<= /div>

In XYZ, the capabilities are expressed by t= he client, and the GS states which capabilities it will accept. This can ma= ke it difficult for the GS to enforce the interaction choices as the client= can mix and match which capabilities are returned. For example, a GS may n= ot want to support a redirect without a callback to protect itself from ses= sion fixation attacks. In XAuth, the interaction modes provide clarity on t= he mode of interaction and the security properties. For example the GS may = support both user_code and redirect modes, but not the indirect mode which = is subject to session fixation attacks.


If the GS doesn=E2=80=99t want to acce= pt a redirect without a callback, it can because the request will have a re= direct, but not a callback, and it can reject the request. What makes you b= elieve that this is not detectable or not possible in XYZ?=C2=A0

I did not say it could not be done,= I'm saying it is more difficult in XYZ than in XAuth
=C2=A0<= /div>

<= /div>
The modes in XAuth are much more limiting, as the mixing of diffe= rent interaction methods is already something that we need to start figurin= g out. Let=E2=80=99s say, for example, a client can do a redirect, accept a= CIBA-style ping, or do a direct app2app communication. There=E2=80=99s a n= atural preference the client will have here: if it can talk to another app = directly, it=E2=80=99ll try that first. If that doesn=E2=80=99t work, it ca= n get a push notification sent, and if all that fails, it can pop open a br= owser. If I have to pick just one of those modes when I make the request, t= hen the client needs to make three different requests to the AS before I ge= t anything that works.=C2=A0

<= div>Have you read the revised draft? As I noted above, I have added negotia= tion. The Client can state all the modes it wants, the GS can respond with = the modes it will support, and the Client can offer the User any modes retu= rned from the GS.
=C2=A0

This kind of mixing is importa= nt to allow for different modalities of client. In fact, the return callbac= k could be tied to the entry of a user code, not just an outbound redirect.= How the client gets the user to the AS and how the user gets back are sepa= rate questions, and we need flexibility in both.

Yes, we need flexibility. We also need the GS to be= able to easily enforce what can happen.
=C2=A0
XAuth ties them toget= her in the same way that OAuth 2 does, and this is an unnecessary restricti= on that does not add security or simplicity.

6) Claims at Top Level vs Namespaced=C2= =A0

In XYZ, there is one schema for= claims, and they are requested as:

=C2=A0 =C2=A0&= quot;claims": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0"subject": tru= e,
=C2=A0 =C2=A0 =C2=A0 =C2=A0"email": true
=C2=A0 =C2=A0}<= br>

Whereas in XAuth, claims are in their own name= space:

=C2=A0 =C2=A0 "claims": {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 "oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 "id_token" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 "email" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: { "essential" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 "email_verified" : { "essential&quo= t; : true }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "userinfo" : {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "name" =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 : { "essential" : true },
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "picture" =C2=A0 =C2=A0= =C2=A0 =C2=A0: null
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 }

In this exam= ple, the client is requesting OIDC defined claims, the email to be in an ID= Token, and the name and picture to be as text. While the XYZ schema may be= extended, there are already numerous schemas being used. The XAuth approac= h is to support existing and new schemas,=C2=A0rather than pick one and/or = create another one, and allows a Grant Request to contain claims from multi= ple schemas at the same time.

=
Again, as I have said many times, this part of the request (as is the = rest of the request) is extensible. The goal of the =E2=80=9Cclaims=E2=80= =9D object in XYZ was to propose a simple, common core. Is this the best se= t? Probably not, but that=E2=80=99s why nothing is final yet, right?=C2=A0<= /div>

Yes, XYZ is extensible. I= t is not namespaced as XAuth is.
=C2=A0

If we wanted to= allow for OIDC style claims objects, we have space to do exactly that, eit= her as a sub-component of the existing claims object or as a new top-level = object in the request. This flexibility is important, as there are other sc= hemas and other query languages that people might want to support, includin= g things like JWM:


And at Mike Jones=E2= =80=99s request, I=E2=80=99ve added notes in the current draft of XYZ to th= e places that will be extensible via registry or some other mechanism =E2= =80=94 but the goal was to have everything in there be extensible by reason= able mechanisms in ways that will allow innovation to flourish without brea= king core and common functionality.=C2=A0

I do not= understand why you insist on painting XYZ as a static, inflexible, and unb= ending model when it is exactly the opposite. You don=E2=80=99t have to ext= ernalize every piece of flexibility in order to have it, and I really hope = that these myths don=E2=80=99t keep getting repeated in the group.

All I am doing is comparing what = is written. I'm not trying to paint XYZ anything.=C2=A0
=C2= =A0

7)= No Authorization Type

Similar to (6), XYZ= has a single schema for how to request access to a resource. While that sc= hema is extensible, it requires adaption=C2=A0from any system with an exist= ing schema. XAuth has a type for each authorization request (oauth2, rar), = allowing existing schemas and new schemas to be supported.

This is a ridiculous claim because the RA= R format is a back port of the XYZ format to an OAuth 2 architecture. If yo= u consider that RAR is extensible, then XYZ is extensible by your same defi= nitions. In addition, if there are other resource query languages out there= beyond these, and we can support them just like we would support additiona= l claims query languages.=C2=A0

Furthermore, as I= =E2=80=99ve said before, XAuth doesn=E2=80=99t allow a clean way to define = the use of both OAuth 2 scopes and rich requests. XYZ does this by allowing= scope-style strings and full JSON objects to be specified at the same leve= l in the same data structure, so there=E2=80=99s no confusion over how they= =E2=80=99re grouped or applied. XAuth makes me choose ahead of time to use = one or the other, effectively at the API level. So I can no longer easily c= all for, say, =E2=80=9Clogin information=E2=80=9D (a general scope) along w= ith =E2=80=9Ctransaction history for a specific bank account=E2=80=9D (a ri= ch data object) in the same request. Even RAR handles this better than XAut= h by simply letting the =E2=80=9Cscope=E2=80=9D parameter also be passed al= ong side the authorization_details object, but there are significant comple= xity issues with this as there isn=E2=80=99t a clear way to combine these c= oncepts in the OAuth 2 world. I think we can do so much better here, and XY= Z proposes one such consistent way to do that by defining the scope-equival= ent to be a pass-by-reference version of the rich object that is passed-by-= value. If clients have a shortcut (a scope), they can use that; if they nee= d the expressiveness of the resources structure, they can do that.=C2=A0

Once again it does not seem= that you have read the latest draft. XAuth allows existing OAuth 2 scopes,= OR OAuth 2 scopes with RAR, OR a new type authorization type that works di= fferently.

=C2=A0

I meant to include [2] as another claim schema in point (6) above.= In XAuth, you will see that "vc" is another object in the "= claims" Object.
=C2=A0
I believe our protocol needs to be flexibl= e enough to allow this kind of thing on input (the client presenting inform= ation about who the user is, as well as requesting specific information abo= ut the user) and output (the AS claiming information about the user), in ad= dition to the client being given something that it can then in turn use wit= h another service down the line to present user information. The world is m= oving away from an IdP-driven identity model, and we need to keep moving wi= th it and enable it here.

We agree on the flexibility. The XAuth proposal is to namespace the schema= s so that adopting existing schemas, or using a new one is straightforward.=


3D""=E1=90=A7
--000000000000c3493a05a788422c-- From nobody Mon Jun 8 05:29:35 2020 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 CA97F3A0A26 for ; Mon, 8 Jun 2020 05:29:32 -0700 (PDT) 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 pH7bF4NOn87B for ; Mon, 8 Jun 2020 05:29:27 -0700 (PDT) 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 E32833A0A21 for ; Mon, 8 Jun 2020 05:29:26 -0700 (PDT) Received: from [192.168.1.14] (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 058CTNup013524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Jun 2020 08:29:23 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1FAC5CFF-639E-4E53-9446-0607D7938AA7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 8 Jun 2020 08:29:23 -0400 In-Reply-To: Cc: txauth@ietf.org To: Dick Hardt References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 08 Jun 2020 12:29:33 -0000 --Apple-Mail=_1FAC5CFF-639E-4E53-9446-0607D7938AA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Comments inline, again. > On Jun 7, 2020, at 6:32 PM, Dick Hardt wrote: >=20 > comments inline ... >=20 > On Sun, Jun 7, 2020 at 1:41 PM Justin Richer > wrote: > Hi Dick, responses inline. >=20 >> On Jun 7, 2020, at 3:27 PM, Dick Hardt > wrote: >>=20 >> Hello >>=20 >> I have just posed some updates on the XAuth draft: >>=20 >> In -07 I added the XYZ features of interaction negotiation, and a = Client Handle for dynamic clients. I also updated the name to GNAP, but = preserved the draft-hardt-xauth-protocol filename for ease of tracking = changes.=20 >>=20 >> In -08 I split the doc into: core protocol, advanced features, and = JOSE authentication.=20 >>=20 >> https://www.ietf.org/id/draft-hardt-xauth-protocol-08.html = >> https://www.ietf.org/id/draft-hardt-gnap-advanced-00.html = >> https://www.ietf.org/id/draft-hardt-gnap-jose-00.html = >>=20 >> IMHO, the main doc is much more readable. :) >>=20 >=20 > I think that renaming your individual draft is premature and = presumptive, as the WG has not yet decided on an approach for the WG = base draft and renaming one of the input drafts like this is going to = simply add to confusion when trying to discuss and compare different = approaches. I would recommend undoing this name change in order to = facilitate discussion going forward, to allow people to refer to one = project with a single name and know what it means. >=20 > As you and I have discussed offline, and as you yourself suggested, it = might be beneficial for the working group to start from a new draft = document incorporating the most important features. Until we reach that = point, renaming any of the input drafts into what the group=E2=80=99s = target draft will be is going to cause problems. >=20 > My intent was to remove confusion, not create confusion. Per my = comments below, I refer to my draft as XAuth, and your draft as XYZ. The = filename still has -xauth- and not -gnap-.=20 >=20 > I have pushed a -09 that has additional text in the introduction to = clarify it should be referred to as XAuth.=20 >=20 > https://www.ietf.org/id/draft-hardt-xauth-protocol-09.html > >=20 > I named the other files with draft-hardt-gnap to make it clear the = document is related to the proposed GNAP WG.=20 >=20 Thank you for adding the disclaimer, but by naming the draft set "The = Grant Negotiation and Authorization Protocol=E2=80=9D it still gives a = different impression, intended or otherwise. > =20 >=20 >>=20 >> XYZ vs XAuth >>=20 >> The remaining major differences between XYZ and XAuth are areas I = have concerns about. (I will continue to use XYZ and XAuth refer to each = draft). The concerns are: >>=20 >> 1) API in JSON vs URI and HTTP Verb >>=20 >> In XYZ, all calls are to the same endpoint as an HTTP POST. The AS = must parse the JSON to determine what to do.=20 >>=20 >> XAuth has a RESTful interface. A Grant Request starts at the GS URI, = and Grants and Authorizations are returned as URI resources. Creating a = Grant is done with a POST, reading a Grant is done with a GET.=20 >>=20 >> With URIs and HTTP verbs, A large scale GS can easily implement = independent services for each functionality as routing of requests can = be done at the HTTP layer based on the URI and HTTP verb. This allows a = separation of concerns, independent deployment, and resiliency. >=20 > As I have said many, many times, both on the list and in the = documentation for XYZ, this is an area that is worth discussing within = the working group. It=E2=80=99s been tagged a potential direction in XYZ = from early days, but not something that we=E2=80=99ve pursued because it = hasn=E2=80=99t been needed in the spaces we=E2=80=99ve used it. >=20 > So saying this is a fundamental aspect of XYZ and implying that it=E2=80= =99s a non-starter for it to not be built that way is misdirection. I = hope that the conversation here in this group can continue without you = ignoring or dismissing previous statements like this as we discuss = things.=20 >=20 > I'm comparing the two drafts we have today, not what the drafts could = be. You have consistently stated that there is just one end point in the = XYZ model, and that handles represent the transaction rather than URIs = -- as you state again below in your response to point 4. >=20 > I find it is much easier for people to understand a proposal to write = it up. I could not see how to easily modify XYZ to support the models I = envisioned, which is why I wrote XAuth. You and I both agree that things are easier to understand when written = up, and that=E2=80=99s why I have produced significant write-ups of both = the current state and the potential future state of XYZ during its = lifetime, and continue to do so. The ID is only one of these artifacts, = and I find it problematic that you dismiss any and all additional = material. As both drafts are inputs to a proposed working group, and not final = systems, they should be compared not only for what=E2=80=99s there but = for what direction they could go. To do otherwise is to ignore the = changes that a working group can and will make on its inputs in pursuit = of a general solution. It is not my intent that XYZ, as currently = proposed, be simple accepted as-is. In fact, I hope it=E2=80=99s not, as = the entire point of me trying to start this working group was to bring a = community together to build something new, useful, and powerful. My = contention with your statement, if you read what I said, is not that XYZ = doesn=E2=80=99t do something today, but that in your view it cannot do = something. The entire purpose of this exercise is to compare = possibility. So then: let=E2=80=99s unpack that possibility. Checking my notes on = this topic, I see a pretty straightforward way to do this kind of thing. = Note that herein I=E2=80=99ll be using the native terminology of XYZ, = including =E2=80=9Ctransaction=E2=80=9D and =E2=80=9Chandle=E2=80=9D, = for consistency and to avoid confusion. Currently, the spec has the Tx = endpoint return a reference to the ongoing transaction, known as a = handle. This credential has a value and a presentation method, and = it=E2=80=99s returned at the top level of the response: "handle": { "value": "80UPRY5NM33OMUKMKSKU", "type": "bearer" } It would be very simple for this credential to also include a URI for it = to be used at: "handle": { "value": "80UPRY5NM33OMUKMKSKU", "type": =E2=80=9Cbearer=E2=80=9D, =E2=80=9Curi": =E2=80=9Chttps://server.example/tx/foo-123 = " } Or if we wanted to, we could even break it out into a multi part = structure: =E2=80=9Ctransaction": { "handle": { "value": "80UPRY5NM33OMUKMKSKU", "type": =E2=80=9Cbearer=E2=80=9D } =E2=80=9Curi": =E2=80=9Chttps://server.example/tx/foo-123 = " } This pattern of supplying both a credential and a URL for the client to = use in a tightly-coupled fashion is one that has been used before and we = know works. It=E2=80=99s the basis of RFC7592 and ODIC=E2=80=99s Dynamic = Registration, for example. What=E2=80=99s important here is that the = client is told exactly where to go. This URL could be the transaction = endpoint itself, it could be a RESTful style API, it could be a graph = API node, it could be a management service on another cluster. The = protocol quite frankly shouldn=E2=80=99t care about this, and = shouldn=E2=80=99t dictate to the AS how to deploy its parts. Instead, = the protocol should concern itself only with the interconnection of = well-defined components. By providing both a handle and a target URL we = allow the AS to decide whether it wants to dispatch based on URL, = handle, or something else that it gets to decide.=20 Note that this credential, the handle, still needs to be presented in = the context of the client=E2=80=99s key proofing that was used to start = things off, so it isn=E2=80=99t fully a bearer access token. This makes = it significantly harder for an attacker to do a man-in-the-middle attack = with a fake AS, since they can=E2=80=99t get a client to use the = attacker=E2=80=99s keys or vice versa. But this also means that I = don=E2=80=99t think we can use an access token here, because the client = needs to be able to present its keys in a consistent manner and that = might include its own use of an Authorization header, depending on the = key proofing method. We shouldn=E2=80=99t step on that space. = Additionally, the client is going to be providing additional information = in the follow-up requests anyway, such as a reference from the = front-channel callback, the signed response to a cryptographic = challenge, an identifier for a push endpoint, etc. Since we=E2=80=99re = in the back channel we=E2=80=99re not limited to just stuffing things = into URLs, and these can all be presented as part of the protocol = request.=20 Furthermore, this handle should be independent from its use in any = follow-up requests because it should also be able to be used to start a = new transaction in a new context. This kind of step-up authorization is = something that people have long desired in OAuth 2 and have hacked = together in a few different ways in the wild, but we can do it here. = Now of course we could hack around this by providing the grant URL in a = new transaction request, but that unnecessarily conflates the identifier = (the URL) with the access method.=20 Additionally, the handle in my implementations of XYZ have all been = random values, but that doesn=E2=80=99t need to be the case at all. For = a distributed system, the AS might want to pack information about the = transaction into an encrypted bundle and pass it to the handle in a more = stateless/serverless fashion. If we force the AS to put that information = into the URL itself, then we=E2=80=99re going to run into many of the = same problems that we do in the front channel of OAuth 2 today and end = up with some of the same workarounds and patches. This is the back = channel, and we should make use of the fact that the client can send = more than just a plain GET to a URL. As an aside, this approach of bundling a target with the handle is = something that=E2=80=99s been brought up on this list already, and I = know there=E2=80=99s appetite for addressing it with regard to access = tokens. Namely, there are a few different groups that want to be able to = indicate to the client where it should use an access token. This has = implications for multiple access tokens and resource set descriptions, = among other key aspects of the protocol. This is a difficult and complex = problem that fans out quickly, but thanks to previous indication of = interest from the members of this list, it is within our proposed = charter and I look forward to discussing this issue as the group gets = going. Now with that said, there are still some good reasons to define it as a = single endpoint. Namely, the kinds of responses you get from starting a = transaction are the same as those returned from continuing a transaction = in progress. For example, with the functionality split, you now have two = places in your architecture that could return an access token, depending = on if the policies allow for the token to be issued without user = interaction (the client credentials equivalent) or not (the auth code = equivalent). Furthermore, the inputs to the request on both sides are = largely the same =E2=80=94 much of the information that you might = present in a follow-up could be presented in an initial request. As = such, this is not a purely restful process unless you jump through some = additional hoops to force it to be, like making the client do a = =E2=80=9CGET=E2=80=9D on the results of the request in order to get its = access token instead of returning it directly. However, not even XAuth = requires this, for what I hope are obvious reasons. This is the kind of = thing that needs to be balanced against the benefits of splitting the = endpoints, and something the group needs to debate and come to terms = with.=20 Using a different URI, optionally, isn=E2=80=99t the problem, and that = could easily be added to the. Removal of the separate handle is the = problem I have with the XAuth approach. > =20 >=20 > Additionally, I find XAuth=E2=80=99s restrictions on the structure of = the Grant URI potentially problematic, namely that it has to start with = the server=E2=80=99s URL. This will lead to deployments needing to bend = their setups with proxies or redirectors to make things fit, which you = yourself have said is going to be an issue for things like supporting a = short redirect URL vs. a long redirect URL. Your complaint there was one = of latency and complexity, why does that not apply here? But most = fundamentally, I do not see what value this restriction brings to the = system. If the value is coming back from the GS endpoint, and the client = is getting all of its pointers from there, what=E2=80=99s the point of = dictating how that has to look? >=20 > Requiring the Grant URI to start with the GS URI is open to = discussion. It is not clear to me why a deployment would need to have a = redirector. Large scale deployments I have worked on have a router / = proxy that routes requests to internal services. Having all the URIs = start with the GS URI enables all GNAP operations to be routed in the = same place. You still haven=E2=80=99t addressed why you think that this is a = reasonable requirement or assumption here but not when dealing with = long/short URLs for QR codes. What is the difference? >=20 > An advantage of starting with the GS URI is that any software on the = Client side knows which GS it belongs to. A Grant URI passed to a Client = in a GS initiated login allows the Client to know if it trusts the GS = before operating on the Grant URI.=20 Is the client then required to make this check for security purposes? Or = can we protect against this kind of confusion by building the system to = be resilient to it in a different way? I have opted for the latter in = XYZ=E2=80=99s design. >=20 > If the Grant URI can be any URI, then a Client could be tricked into = operating on a Grant URI it should not be operating on.=20 This is not true if the client also needs to present its keys with the = request, is it? Am I missing an attack here? > =20 >=20 >>=20 >> 2) Handles for all Clients vs Client ID and Client Handle >>=20 >> In XYZ, both pre-registered clients and dynamic clients use a handle.=20= >>=20 >> In XAuth, the Client ID refers to a pre-registered client, and the = Client Handle is specific to an instance of a dynamic client. Using = separate terms clearly differentiates which identifier is being = presented to the GS.=20 >>=20 >> This allows a GS to use separate mechanisms for managing = pre-registered clients and dynamic clients, an important consideration = as there can easily be millions of instances of a single dynamic client. >>=20 >> Additionally, developers are already familiar with what a Client ID = is for pre-registered clients. >=20 > I see the inconsistency in the XAuth draft to be problematic. Under = this proposed model, I now need to be able to track clients using = different kinds of identifiers depending on what kind of registration = they used? Why build in this dichotomy? >=20 > A GS implementation is free to use the same identifiers and storage = system for Client IDs and Client Handles.=20 > =20 >=20 > One of the design goals of XYZ was to bring consistency to the = haphazard world of OAuth 2, where a client ID could mean a class of = client software or an individual client or a cluster of servers or any = number of other things.=20 >=20 > In XYZ a client handle refers to both registered clients, and dynamic = clients. That seems to continue to be haphazard.=20 >=20 > Dynamic Registration needed to use Client ID as the rest of OAuth only = understood that identifier for a client. >=20 > XAuth allows each type of client to have their own identifier. The key handle represents a set of keying material that is passed by = reference instead of by value. That keying material is something that = the server has seen before. It can be associated with a piece of = software that has either been statically registered, or it could be a = key that showed up dynamically and the server is providing a shortcut to = reference it. In both cases, static and dynamic clients can present their keys by = value and get expected behavior. Instead of a fuzzy definition where = =E2=80=9Cclient=E2=80=9D could mean an instance, a class, or a concept, = we=20 This is why I want to get away from a =E2=80=9Cclient identifier=E2=80=9D = because there is not a concrete and consistent definition of what a = =E2=80=9Cclient=E2=80=9D means across the wide variety of use cases we = already know we have. > =20 >=20 > And as I=E2=80=99ve demonstrated with an implementation on top of the = MITREid Connect OAuth 2 server, it=E2=80=99s completely possible and = well within-protocol to pass in a static client ID within the XYZ=E2=80=99= s =E2=80=9Ckey handle=E2=80=9D field and have things work as expected. = Yes, it=E2=80=99s called something different =E2=80=94 but if that=E2=80=99= s a problem, then XAuth=E2=80=99s renaming of the Authorization Server = to a Grant Server is going to be significantly more confusing for = developers, don=E2=80=99t you think? >=20 > Nope.=20 > =20 >=20 >>=20 >> 3) Transaction Handles are One Time Use >>=20 >> In XYZ, transaction handles are one time use [1]. In the OAuth WG = discussion on one time use refresh tokens, clients are often distributed = across components, which complicates one time use references.=20 >>=20 >> One time use transaction handles also makes them inconsistent with = the display, resource, user, and key handles. >=20 > Transaction handles being one-time-use is based on experience with a = session fixation attack against UMA (now patched): >=20 > = https://kantarainitiative.org/confluence/display/uma/Understanding+the+Ses= sion+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+Mitigation = = >=20 > Clients with distributed components are going to have to be considered = in our core model, and so there are considerations and tradeoffs in = terms of security and deployability that we need to address here. These = are the same kinds of discussions that we=E2=80=99re having in OAuth 2, = as you point out, and so we can not only apply that experience and = knowledge to this, but we can build something that behaves better than a = refresh token for this purpose. >=20 > The XAuth proposal is to use a URI to represent the authorization.=20 I know what XAuth does, and it does not help that kind of attack. = Automatic credential rotation on use is a well established mitigation = mechanism that is impossible if the only item you have is a URI that is = given exactly once within the protocol. This is in addition to the = discussion above regarding issuing the credential alongside the URI. > =20 >=20 >>=20 >> 4) New User Identifier >>=20 >> XYZ introduces a new identifier for the user, a User Handle. Unclear = why a new type of user identifier is needed, except for the desire to = have a handle for everything. >>=20 >=20 > This is based directly on the Persisted Claims Token concept from = UMA2, where a client (that is trusted to make such a statement) can say = that it reasonably believes that the current user interacting with this = client is the same user that it=E2=80=99s been interacting with before, = for use with a future request. An AS can take this signal into = consideration when processing the request, potentially avoiding = unnecessary interaction and friction. >=20 > My statement is that it was unclear why it was needed. Perhaps you can = add a Rationale section to XYZ? > =20 >=20 > I=E2=80=99m not surprised that you see this as =E2=80=9Cjust applying = a handle for everything=E2=80=9D considering you=E2=80=99ve previously = objected to the use of the pass-by-reference construct for other aspects = of the protocol in the past as well. Each component in XYZ that has a = separate handle has one for specific and documented reasons, and it=E2=80=99= s a core feature that these are handled (pun intended) in a consistent = and predictable manner. >=20 > This is why I state that it seems hard to change (1) above.=20 > =20 >=20 >> 5) Interaction Capabilities vs Modes >>=20 >> In XYZ, the capabilities are expressed by the client, and the GS = states which capabilities it will accept. This can make it difficult for = the GS to enforce the interaction choices as the client can mix and = match which capabilities are returned. For example, a GS may not want to = support a redirect without a callback to protect itself from session = fixation attacks. In XAuth, the interaction modes provide clarity on the = mode of interaction and the security properties. For example the GS may = support both user_code and redirect modes, but not the indirect mode = which is subject to session fixation attacks. >>=20 >=20 > If the GS doesn=E2=80=99t want to accept a redirect without a = callback, it can because the request will have a redirect, but not a = callback, and it can reject the request. What makes you believe that = this is not detectable or not possible in XYZ?=20 >=20 > I did not say it could not be done, I'm saying it is more difficult in = XYZ than in XAuth Can you explain to me how it=E2=80=99s more difficult in XYZ? I have = explained how it can be done and I am failing to see why you think = it=E2=80=99s harder. > =20 >=20 > The modes in XAuth are much more limiting, as the mixing of different = interaction methods is already something that we need to start figuring = out. Let=E2=80=99s say, for example, a client can do a redirect, accept = a CIBA-style ping, or do a direct app2app communication. There=E2=80=99s = a natural preference the client will have here: if it can talk to = another app directly, it=E2=80=99ll try that first. If that doesn=E2=80=99= t work, it can get a push notification sent, and if all that fails, it = can pop open a browser. If I have to pick just one of those modes when I = make the request, then the client needs to make three different requests = to the AS before I get anything that works.=20 >=20 > Have you read the revised draft? As I noted above, I have added = negotiation. The Client can state all the modes it wants, the GS can = respond with the modes it will support, and the Client can offer the = User any modes returned from the GS. Yes, did you read what I wrote? I think we=E2=80=99re talking past each = other. > =20 >=20 > This kind of mixing is important to allow for different modalities of = client. In fact, the return callback could be tied to the entry of a = user code, not just an outbound redirect. How the client gets the user = to the AS and how the user gets back are separate questions, and we need = flexibility in both. >=20 > Yes, we need flexibility. We also need the GS to be able to easily = enforce what can happen. > =20 > XAuth ties them together in the same way that OAuth 2 does, and this = is an unnecessary restriction that does not add security or simplicity. >=20 >> 6) Claims at Top Level vs Namespaced=20 >>=20 >> In XYZ, there is one schema for claims, and they are requested as: >>=20 >> "claims": { >> "subject": true, >> "email": true >> } >>=20 >> Whereas in XAuth, claims are in their own namespace: >>=20 >> "claims": { >> "oidc": { >> "id_token" : { >> "email" : { "essential" : true }, >> "email_verified" : { "essential" : true } >> }, >> "userinfo" : { >> "name" : { "essential" : true }, >> "picture" : null >> } >> } >>=20 >> In this example, the client is requesting OIDC defined claims, the = email to be in an ID Token, and the name and picture to be as text. = While the XYZ schema may be extended, there are already numerous schemas = being used. The XAuth approach is to support existing and new schemas, = rather than pick one and/or create another one, and allows a Grant = Request to contain claims from multiple schemas at the same time. >=20 > Again, as I have said many times, this part of the request (as is the = rest of the request) is extensible. The goal of the =E2=80=9Cclaims=E2=80=9D= object in XYZ was to propose a simple, common core. Is this the best = set? Probably not, but that=E2=80=99s why nothing is final yet, right?=20= >=20 > Yes, XYZ is extensible. It is not namespaced as XAuth is. It is, though, as I said above. > =20 >=20 > If we wanted to allow for OIDC style claims objects, we have space to = do exactly that, either as a sub-component of the existing claims object = or as a new top-level object in the request. This flexibility is = important, as there are other schemas and other query languages that = people might want to support, including things like JWM: >=20 > https://tools.ietf.org/id/draft-looker-jwm-01.html = >=20 > And at Mike Jones=E2=80=99s request, I=E2=80=99ve added notes in the = current draft of XYZ to the places that will be extensible via registry = or some other mechanism =E2=80=94 but the goal was to have everything in = there be extensible by reasonable mechanisms in ways that will allow = innovation to flourish without breaking core and common functionality.=20= >=20 > I do not understand why you insist on painting XYZ as a static, = inflexible, and unbending model when it is exactly the opposite. You = don=E2=80=99t have to externalize every piece of flexibility in order to = have it, and I really hope that these myths don=E2=80=99t keep getting = repeated in the group. >=20 > All I am doing is comparing what is written. I'm not trying to paint = XYZ anything.=20 Except that you are doing that =E2=80=94 when I raise a concern on = something in XAuth you often respond with =E2=80=9Coh but that=E2=80=99s = up for debate!=E2=80=9D while dismissing the same counter-argument with = =E2=80=9CI=E2=80=99m comparing what=E2=80=99s written=E2=80=9D.=20 These are input proposals, everything is up for debate. That=E2=80=99s = why we=E2=80=99re debating. > =20 >=20 >>=20 >> 7) No Authorization Type >>=20 >> Similar to (6), XYZ has a single schema for how to request access to = a resource. While that schema is extensible, it requires adaption from = any system with an existing schema. XAuth has a type for each = authorization request (oauth2, rar), allowing existing schemas and new = schemas to be supported. >=20 > This is a ridiculous claim because the RAR format is a back port of = the XYZ format to an OAuth 2 architecture. If you consider that RAR is = extensible, then XYZ is extensible by your same definitions. In = addition, if there are other resource query languages out there beyond = these, and we can support them just like we would support additional = claims query languages.=20 >=20 > Furthermore, as I=E2=80=99ve said before, XAuth doesn=E2=80=99t allow = a clean way to define the use of both OAuth 2 scopes and rich requests. = XYZ does this by allowing scope-style strings and full JSON objects to = be specified at the same level in the same data structure, so there=E2=80=99= s no confusion over how they=E2=80=99re grouped or applied. XAuth makes = me choose ahead of time to use one or the other, effectively at the API = level. So I can no longer easily call for, say, =E2=80=9Clogin = information=E2=80=9D (a general scope) along with =E2=80=9Ctransaction = history for a specific bank account=E2=80=9D (a rich data object) in the = same request. Even RAR handles this better than XAuth by simply letting = the =E2=80=9Cscope=E2=80=9D parameter also be passed along side the = authorization_details object, but there are significant complexity = issues with this as there isn=E2=80=99t a clear way to combine these = concepts in the OAuth 2 world. I think we can do so much better here, = and XYZ proposes one such consistent way to do that by defining the = scope-equivalent to be a pass-by-reference version of the rich object = that is passed-by-value. If clients have a shortcut (a scope), they can = use that; if they need the expressiveness of the resources structure, = they can do that.=20 >=20 > Once again it does not seem that you have read the latest draft. XAuth = allows existing OAuth 2 scopes, OR OAuth 2 scopes with RAR, OR a new = type authorization type that works differently. I don=E2=80=99t think you read what I wrote here. I did read the new = XAuth draft before replying, and my complaint is that it is still an OR.=20= >=20 > =20 >=20 >>=20 >> Summary >>=20 >> While concerns (3-7) can be addressed in XYZ, (1-2) look fundamental = to the XYZ architecture. >>=20 >> [1] = https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-7 = >>=20 >> [2] https://w3c.github.io/vc-data-model/ = > I=E2=80=99m not sure what you intended to bring up about VC=E2=80=99s = in your email, because I didn=E2=80=99t see a back-reference to this, = but I=E2=80=99m glad you did mention it. This is an example of a query, = assertion, and proofing data model for users that uses a structure and = language that is outside of the OIDC world, but existing parallel to it.=20= >=20 > I meant to include [2] as another claim schema in point (6) above. In = XAuth, you will see that "vc" is another object in the "claims" Object. > =20 > I believe our protocol needs to be flexible enough to allow this kind = of thing on input (the client presenting information about who the user = is, as well as requesting specific information about the user) and = output (the AS claiming information about the user), in addition to the = client being given something that it can then in turn use with another = service down the line to present user information. The world is moving = away from an IdP-driven identity model, and we need to keep moving with = it and enable it here. >=20 > We agree on the flexibility. The XAuth proposal is to namespace the = schemas so that adopting existing schemas, or using a new one is = straightforward. The XYZ proposal is to have a core namespace for common elements and = additionally to allow other namespaces to be added in as needed. =E2=80=94 Justin >=20 >=20 >=20 > Thanks, > =E2=80=94 Justin >=20 >>=20 >> =E1=90=A7 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 > =E1=90=A7 --Apple-Mail=_1FAC5CFF-639E-4E53-9446-0607D7938AA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Comments inline, again.

On Jun = 7, 2020, at 6:32 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

comments inline ...

On Sun, Jun 7, 2020 at 1:41 PM Justin Richer <jricher@mit.edu> = wrote:
Hi Dick, responses inline.

On Jun = 7, 2020, at 3:27 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Hello

I have just posed some = updates on the XAuth draft:

In -07 I added the XYZ features of interaction negotiation, = and a Client Handle for dynamic clients. I also updated the name to = GNAP, but preserved the draft-hardt-xauth-protocol filename for ease of = tracking changes. 

In -08 I split the doc into: core protocol, advanced = features, and JOSE authentication. 

https://www.ietf.org/id/draft-hardt-xauth-protocol-08.html<= br class=3D"">
https://www.ietf.org/id/draft-hardt-gnap-advanced-00.html
https://www.ietf.org/id/draft-hardt-gnap-jose-00.html

IMHO, the main doc is much more readable. :)


I think that renaming = your individual draft is premature and presumptive, as the WG has not = yet decided on an approach for the WG base draft and renaming one of the = input drafts like this is going to simply add to confusion when trying = to discuss and compare different approaches. I would recommend undoing = this name change in order to facilitate discussion going forward, to = allow people to refer to one project with a single name and know what it = means.

As you = and I have discussed offline, and as you yourself suggested, it might be = beneficial for the working group to start from a new draft document = incorporating the most important features. Until we reach that point, = renaming any of the input drafts into what the group=E2=80=99s target = draft will be is going to cause = problems.

My intent was to remove confusion, not = create confusion. Per my comments below, I refer to my draft as XAuth, = and your draft as XYZ. The filename still has -xauth- and not = -gnap-. 

I = have pushed a -09 that has additional text in the introduction to = clarify it should be referred to as XAuth. 

https://www.ietf.org/id/draft-hardt-xauth-protocol-09.html

I named the other files with draft-hardt-gnap to make it = clear the document is related to the proposed GNAP WG. 


Thank you for adding the disclaimer, but by naming = the draft set "The Grant Negotiation and Authorization Protocol=E2=80=9D = it still gives a different impression, intended or otherwise.

 

XYZ vs = XAuth

The = remaining major differences between XYZ and XAuth are areas I have = concerns about. (I will continue to use XYZ and XAuth refer to each = draft). The concerns are:

1) API in JSON vs URI and HTTP = Verb

In XYZ, all calls are to the same endpoint as an HTTP = POST. The AS must parse the JSON to determine what to = do. 

XAuth = has a RESTful interface. A Grant Request starts at the GS URI, and = Grants and Authorizations are returned as URI resources. Creating a = Grant is done with a POST, reading a Grant is done with a GET. 

With URIs and HTTP = verbs, A large scale GS can easily implement independent services = for each  functionality as routing of requests can be done at = the HTTP layer based on the URI and HTTP verb. This allows a separation = of concerns, independent deployment, and = resiliency.

As I have said many, many times, both = on the list and in the documentation for XYZ, this is an area that is = worth discussing within the working group. It=E2=80=99s been tagged a = potential direction in XYZ from early days, but not something that = we=E2=80=99ve pursued because it hasn=E2=80=99t been needed in the = spaces we=E2=80=99ve used it.

So saying this is a fundamental aspect = of XYZ and implying that it=E2=80=99s a non-starter for it to not be = built that way is misdirection. I hope that the conversation here in = this group can continue without you ignoring or dismissing previous = statements like this as we discuss = things. 

I'm comparing the two drafts = we have today, not what the drafts could be. You have = consistently stated that there is just one end point in the XYZ model, = and that handles represent the transaction rather than URIs -- as you state = again below in = your response to point 4.

I find it is much easier for people to understand a proposal = to write it up. I could not see how to easily modify XYZ to support the = models I envisioned, which is why I wrote = XAuth.

You and I both agree that things are easier to = understand when written up, and that=E2=80=99s why I have produced = significant write-ups of both the current state and the potential future = state of XYZ during its lifetime, and continue to do so. The ID is only = one of these artifacts, and I find it problematic that you dismiss any = and all additional material.

As both = drafts are inputs to a proposed working group, and not final systems, = they should be compared not only for what=E2=80=99s there but for what = direction they could go. To do otherwise is to ignore the changes that a = working group can and will make on its inputs in pursuit of a general = solution. It is not my intent that XYZ, as currently proposed, be simple = accepted as-is. In fact, I hope it=E2=80=99s not, as the entire point of = me trying to start this working group was to bring a community together = to build something new, useful, and powerful. My contention with your = statement, if you read what I said, is not that XYZ doesn=E2=80=99t do = something today, but that in your view it cannot do something. The = entire purpose of this exercise is to compare possibility.

So then: let=E2=80=99s unpack that possibility. = Checking my notes on this topic, I see a pretty straightforward way to = do this kind of thing. Note that herein I=E2=80=99ll be using the native = terminology of XYZ, including =E2=80=9Ctransaction=E2=80=9D and = =E2=80=9Chandle=E2=80=9D, for consistency and to avoid confusion. = Currently, the spec has the Tx endpoint return a reference to the = ongoing transaction, known as a handle. This credential has a value and = a presentation method, and it=E2=80=99s returned at the top level of the = response:

  =   "handle": {
= "value": "80UPRY5NM33OMUKMKSKU",
= "type": "bearer"
    = }

It would be very simple for = this credential to also include a URI for it to be used = at:

    = "handle": {
        = "value": "80UPRY5NM33OMUKMKSKU",
    =     "type": =E2=80=9Cbearer=E2=80=9D,
        =E2=80=9Curi": =E2=80=9Chttps://server.example/tx/foo-123"
    }

Or if we wanted to, we could even break it out into a multi = part structure:

    =E2=80=9Ctransaction": {
        "handle": {
            =  "value": "80UPRY5NM33OMUKMKSKU",
    =          "type": =E2=80=9Cbearer=E2=80=9D
        }
        =E2=80=9Curi": =E2=80=9Chttps://server.example/tx/foo-123"
    }


This pattern of supplying both a = credential and a URL for the client to use in a tightly-coupled fashion = is one that has been used before and we know works. It=E2=80=99s the = basis of RFC7592 and ODIC=E2=80=99s Dynamic Registration, for example. = What=E2=80=99s important here is that the client is told exactly where = to go. This URL could be the transaction endpoint itself, it could be a = RESTful style API, it could be a graph API node, it could be a = management service on another cluster. The protocol quite frankly = shouldn=E2=80=99t care about this, and shouldn=E2=80=99t dictate to the = AS how to deploy its parts. Instead, the protocol should concern itself = only with the interconnection of well-defined components. By providing = both a handle and a target URL we allow the AS to decide whether it = wants to dispatch based on URL, handle, or something else that it gets = to decide. 

Note that this = credential, the handle, still needs to be presented in the context of = the client=E2=80=99s key proofing that was used to start things off, so = it isn=E2=80=99t fully a bearer access token. This makes it = significantly harder for an attacker to do a man-in-the-middle attack = with a fake AS, since they can=E2=80=99t get a client to use the = attacker=E2=80=99s keys or vice versa. But this also means that I = don=E2=80=99t think we can use an access token here, because the client = needs to be able to present its keys in a consistent manner and that = might include its own use of an Authorization header, depending on the = key proofing method. We shouldn=E2=80=99t step on that space. = Additionally, the client is going to be providing additional information = in the follow-up requests anyway, such as a reference from the = front-channel callback, the signed response to a cryptographic = challenge, an identifier for a push endpoint, etc. Since we=E2=80=99re = in the back channel we=E2=80=99re not limited to just stuffing things = into URLs, and these can all be presented as part of the protocol = request. 

Furthermore, this = handle should be independent from its use in any follow-up requests = because it should also be able to be used to start a new transaction in = a new context. This kind of step-up authorization is something that = people have long desired in OAuth 2 and have hacked together in a =  few different ways in the wild, but we can do it here. Now of = course we could hack around this by providing the grant URL in a new = transaction request, but that unnecessarily conflates the identifier = (the URL) with the access method. 

Additionally, the handle in my implementations of = XYZ have all been random values, but that doesn=E2=80=99t need to be the = case at all. For a distributed system, the AS might want to pack = information about the transaction into an encrypted bundle and pass it = to the handle in a more stateless/serverless fashion. If we force the AS = to put that information into the URL itself, then we=E2=80=99re going to = run into many of the same problems that we do in the front channel of = OAuth 2 today and end up with some of the same workarounds and patches. = This is the back channel, and we should make use of the fact that the = client can send more than just a plain GET to a URL.

As an aside, this approach of bundling a target = with the handle is something that=E2=80=99s been brought up on this list = already, and I know there=E2=80=99s appetite for addressing it with = regard to access tokens. Namely, there are a few different groups that = want to be able to indicate to the client where it should use an access = token. This has implications for multiple access tokens and resource set = descriptions, among other key aspects of the protocol. This is a = difficult and complex problem that fans out quickly, but thanks to = previous indication of interest from the members of this list, it is = within our proposed charter and I look forward to discussing this issue = as the group gets going.

Now with = that said, there are still some good reasons to define it as a single = endpoint. Namely, the kinds of responses you get from starting a = transaction are the same as those returned from continuing a transaction = in progress. For example, with the functionality split, you now have two = places in your architecture that could return an access token, depending = on if the policies allow for the token to be issued without user = interaction (the client credentials equivalent) or not (the auth code = equivalent). Furthermore, the inputs to the request on both sides are = largely the same =E2=80=94 much of the information that you might = present in a follow-up could be presented in an initial request. As = such, this is not a purely restful process unless you jump through some = additional hoops to force it to be, like making the client do a = =E2=80=9CGET=E2=80=9D on the results of the request in order to get its = access token instead of returning it directly. However, not even XAuth = requires this, for what I hope are obvious reasons. This is the kind of = thing that needs to be balanced against the benefits of splitting the = endpoints, and something the group needs to debate and come to terms = with. 

Using a different URI, = optionally, isn=E2=80=99t the problem, and that could easily be added to = the. Removal of the separate handle is the problem I have with the XAuth = approach.

 

Additionally, I find = XAuth=E2=80=99s restrictions on the structure of the Grant URI = potentially problematic, namely that it has to start with the server=E2=80= =99s URL. This will lead to deployments needing to bend their setups = with proxies or redirectors to make things fit, which you yourself have = said is going to be an issue for things like supporting a short redirect = URL vs. a long redirect URL. Your complaint there was one of latency and = complexity, why does that not apply here? But most fundamentally, I do = not see what value this restriction brings to the system. If the value = is coming back from the GS endpoint, and the client is getting all of = its pointers from there, what=E2=80=99s the point of dictating how that = has to look?

Requiring the Grant URI to start with = the GS URI is open to discussion. It is not clear to me why a deployment = would need to have a redirector. Large scale deployments I have worked = on have a router / proxy that routes requests to internal services. = Having all the URIs start with the GS URI enables all GNAP operations to = be routed in the same = place.

You still haven=E2=80=99t addressed why you think = that this is a reasonable requirement or assumption here but not when = dealing with long/short URLs for QR codes. What is the = difference?


An advantage of starting = with the GS URI is that any software on the Client side knows which GS = it belongs to. A Grant URI passed to a Client in a GS = initiated login allows the Client to know if it trusts the GS = before operating on the Grant = URI. 

Is the client then required to make this check for = security purposes? Or can we protect against this kind of confusion by = building the system to be resilient to it in a different way? I have = opted for the latter in XYZ=E2=80=99s design.


If the Grant URI can be any URI, then a = Client could be tricked into operating on a Grant URI it should not be = operating on. 

This is not true if the client also needs to = present its keys with the request, is it? Am I missing an attack = here?

 


2) = Handles for all Clients vs Client ID and Client Handle

In = XYZ, both pre-registered clients and dynamic clients use a = handle. 

In= XAuth, the Client ID refers to a pre-registered client, and the Client = Handle is specific to an instance of a dynamic client. Using separate = terms clearly differentiates which identifier is being presented to the = GS. 

This = allows a GS to use separate mechanisms for managing pre-registered = clients and dynamic clients, an important consideration as there can = easily be millions of instances of a single dynamic client.

Additionally, developers are already familiar with what = a Client ID is for pre-registered = clients.

I see the inconsistency in the XAuth = draft to be problematic. Under this proposed model, I now need to be = able to track clients using different kinds of identifiers depending on = what kind of registration they used? Why build in this = dichotomy?

A GS implementation is free to use the = same identifiers and storage system for Client IDs and Client = Handles. 
 

One of the design goals of XYZ was to = bring consistency to the haphazard world of OAuth 2, where a client ID = could mean a class of client software or an individual client or a = cluster of servers or any number of other = things. 

In XYZ a client handle refers to both = registered clients, and dynamic clients. That seems to continue to be = haphazard. 

Dynamic Registration needed to use Client ID as the rest of = OAuth only understood that identifier for a client.

XAuth allows each type = of client to have their own = identifier.

The key handle represents a set of keying material = that is passed by reference instead of by value. That keying material is = something that the server has seen before. It can be associated with a = piece of software that has either been statically registered, or it = could be a key that showed up dynamically and the server is providing a = shortcut to reference it.

In both = cases, static and dynamic clients can present their keys by value and = get expected behavior. Instead of a fuzzy definition where =E2=80=9Cclient= =E2=80=9D could mean an instance, a class, or a concept, = we 

This is why I want to get = away from a =E2=80=9Cclient identifier=E2=80=9D because there is not a = concrete and consistent definition of what a =E2=80=9Cclient=E2=80=9D = means across the wide variety of use cases we already know we = have.

 

And as I=E2=80=99ve = demonstrated with an implementation on top of the MITREid Connect OAuth = 2 server, it=E2=80=99s completely possible and well within-protocol to = pass in a static client ID within the XYZ=E2=80=99s =E2=80=9Ckey = handle=E2=80=9D field and have things work as expected. Yes, it=E2=80=99s = called something different =E2=80=94 but if that=E2=80=99s a problem, = then XAuth=E2=80=99s renaming of the Authorization Server to a Grant = Server is going to be significantly more confusing for developers, = don=E2=80=99t you think?
Nope. 

 


3) Transaction Handles are = One Time Use

In XYZ, transaction handles are one = time use [1]. In the OAuth WG discussion on one time use refresh tokens, = clients are often distributed across components, which complicates one = time use references. 

One time use transaction handles also makes them inconsistent = with the display, resource, user, and key = handles.

Transaction handles being one-time-use = is based on experience with a session fixation attack against = UMA (now patched):

https://kantarainitiative.org/confluence/display/uma/Understand= ing+the+Session+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+M= itigation

Clients with distributed components are going to have to be = considered in our core model, and so there are considerations and = tradeoffs in terms of security and deployability that we need to address = here. These are the same kinds of discussions that we=E2=80=99re having = in OAuth 2, as you point out, and so we can not only apply that = experience and knowledge to this, but we can build something that = behaves better than a refresh token for this = purpose.

The XAuth proposal is to use a URI to = represent the = authorization. 

I know what XAuth does, and it does not help that = kind of attack. Automatic credential rotation on use is a well = established mitigation mechanism that is impossible if the only item you = have is a URI that is given exactly once within the protocol. This is in = addition to the discussion above regarding issuing the credential = alongside the URI.

 


4) New User = Identifier

XYZ introduces a new identifier for the user, a User = Handle. Unclear why a new = type of user identifier is needed, except for the desire to have a = handle for everything.


This is based directly on the Persisted = Claims Token concept from UMA2, where a client (that is trusted to make = such a statement) can say that it reasonably believes that the current = user interacting with this client is the same user that it=E2=80=99s = been interacting with before, for use with a future request. An AS can = take this signal into consideration when processing the request, = potentially avoiding unnecessary interaction and = friction.

My statement is that it was unclear why = it was needed. Perhaps you can add a Rationale section to XYZ?
 

I=E2=80=99m not = surprised that you see this as =E2=80=9Cjust applying a handle for = everything=E2=80=9D considering you=E2=80=99ve previously objected to = the use of the pass-by-reference construct for other aspects of the = protocol in the past as well. Each component in XYZ that has a separate = handle has one for specific and documented reasons, and it=E2=80=99s = a core feature = that these are handled (pun intended) in a consistent and predictable = manner.

This is why I state that it = seems hard to change (1) above. 
 

5) Interaction Capabilities vs Modes

In XYZ, the capabilities are = expressed by the client, and the GS states which capabilities it will = accept. This can make it difficult for the GS to enforce the interaction = choices as the client can mix and match which capabilities are returned. = For example, a GS may not want to support a redirect without a callback = to protect itself from session fixation attacks. In XAuth, the = interaction modes provide clarity on the mode of interaction and the = security properties. For example the GS may support both user_code and = redirect modes, but not the indirect mode which is subject to session = fixation attacks.


If the GS doesn=E2=80=99t want to = accept a redirect without a callback, it can because the request will = have a redirect, but not a callback, and it can reject the request. What = makes you believe that this is not detectable or not possible in = XYZ? 

I did not say it could not be done, I'm = saying it is more difficult in XYZ than in = XAuth

Can you explain to me how it=E2=80=99s more = difficult in XYZ? I have explained how it can be done and I am failing = to see why you think it=E2=80=99s harder.

 

The modes in XAuth are much more = limiting, as the mixing of different interaction methods is already = something that we need to start figuring out. Let=E2=80=99s say, for = example, a client can do a redirect, accept a CIBA-style ping, or do a = direct app2app communication. There=E2=80=99s a natural preference the = client will have here: if it can talk to another app directly, it=E2=80=99= ll try that first. If that doesn=E2=80=99t work, it can get a push = notification sent, and if all that fails, it can pop open a browser. If = I have to pick just one of those modes when I make the request, then the = client needs to make three different requests to the AS before I get = anything that works. 

Have you read the = revised draft? As I noted above, I have added negotiation. The Client = can state all the modes it wants, the GS can respond with the modes it = will support, and the Client can offer the User any modes returned from = the GS.

Yes, did you read what I wrote? I think we=E2=80=99r= e talking past each other.

 

This kind of mixing is = important to allow for different modalities of client. In fact, the = return callback could be tied to the entry of a user code, not just an = outbound redirect. How the client gets the user to the AS and how the = user gets back are separate questions, and we need flexibility in = both.

Yes, we need flexibility. We also need = the GS to be able to easily enforce what can happen.
 
XAuth ties them together in the same way that OAuth 2 does, = and this is an unnecessary restriction that does not add security or = simplicity.

6) = Claims at Top Level vs Namespaced 

In = XYZ, there is one schema for claims, and they are requested = as:

  =  "claims": {
       "subject": = true,
       "email": true
   }

Whereas in XAuth, claims are in their = own namespace:

    "claims": {
      =   "oidc": {
            = "id_token" : {
            =     "email"          : { "essential" = : true },
              =   "email_verified" : { "essential" : true }
  =           },
      =       "userinfo" : {
      =           "name"         =   : { "essential" : true },
      =           "picture"       =  : null
            = }
        }

In = this example, the client is requesting OIDC defined claims, the email to = be in an ID Token, and the name and picture to be as text. While the XYZ = schema may be extended, there are already numerous schemas being used. = The XAuth approach is to support existing and new schemas, rather = than pick one and/or create another one, and allows a Grant Request to = contain claims from multiple schemas at the same = time.

Again, as I have said many times, this = part of the request (as is the rest of the request) is extensible. The = goal of the =E2=80=9Cclaims=E2=80=9D object in XYZ was to propose a = simple, common core. Is this the best set? Probably not, but that=E2=80=99= s why nothing is final yet, = right? 

Yes, XYZ is extensible. It is not = namespaced as XAuth is.

It is, though, as I said above.

 

If we wanted to allow = for OIDC style claims objects, we have space to do exactly that, either = as a sub-component of the existing claims object or as a new top-level = object in the request. This flexibility is important, as there are other = schemas and other query languages that people might want to support, = including things like JWM:

https://tools.ietf.org/id/draft-looker-jwm-01.html

And at Mike Jones=E2=80=99= s request, I=E2=80=99ve added notes in the current draft of XYZ to the = places that will be extensible via registry or some other mechanism =E2=80= =94 but the goal was to have everything in there be extensible by = reasonable mechanisms in ways that will allow innovation to flourish = without breaking core and common functionality. 

I do not understand why = you insist on painting XYZ as a static, inflexible, and unbending model = when it is exactly the opposite. You don=E2=80=99t have to externalize = every piece of flexibility in order to have it, and I really hope that = these myths don=E2=80=99t keep getting repeated in the = group.

All I am doing is comparing what is = written. I'm not trying to paint XYZ = anything. 

Except that you are doing that =E2=80=94 when I = raise a concern on something in XAuth you often respond with =E2=80=9Coh = but that=E2=80=99s up for debate!=E2=80=9D while dismissing the same = counter-argument with =E2=80=9CI=E2=80=99m comparing what=E2=80=99s = written=E2=80=9D. 

These are = input proposals, everything is up for debate. That=E2=80=99s why we=E2=80=99= re debating.

 

7) No Authorization = Type

Similar to (6), XYZ has a single schema for how to request = access to a resource. While that schema is extensible, it requires = adaption from any system with an existing schema. XAuth has a type = for each authorization request (oauth2, rar), allowing existing schemas = and new schemas to be supported.

This is a ridiculous = claim because the RAR format is a back port of the XYZ format to an = OAuth 2 architecture. If you consider that RAR is extensible, then XYZ = is extensible by your same definitions. In addition, if there are other = resource query languages out there beyond these, and we can support them = just like we would support additional claims query = languages. 

Furthermore, as I=E2=80=99ve said before, XAuth doesn=E2=80=99t= allow a clean way to define the use of both OAuth 2 scopes and rich = requests. XYZ does this by allowing scope-style strings and full JSON = objects to be specified at the same level in the same data structure, so = there=E2=80=99s no confusion over how they=E2=80=99re grouped or = applied. XAuth makes me choose ahead of time to use one or the other, = effectively at the API level. So I can no longer easily call for, say, = =E2=80=9Clogin information=E2=80=9D (a general scope) along with = =E2=80=9Ctransaction history for a specific bank account=E2=80=9D (a = rich data object) in the same request. Even RAR handles this better than = XAuth by simply letting the =E2=80=9Cscope=E2=80=9D parameter also be = passed along side the authorization_details object, but there are = significant complexity issues with this as there isn=E2=80=99t a clear = way to combine these concepts in the OAuth 2 world. I think we can do so = much better here, and XYZ proposes one such consistent way to do that by = defining the scope-equivalent to be a pass-by-reference version of the = rich object that is passed-by-value. If clients have a shortcut (a = scope), they can use that; if they need the expressiveness of the = resources structure, they can do = that. 

Once again it does not seem that you = have read the latest draft. XAuth allows existing OAuth 2 scopes, OR = OAuth 2 scopes with RAR, OR a new type authorization type that works = differently.

I don=E2=80=99t think you read what I wrote here. = I did read the new XAuth draft before replying, and my complaint is that = it is still an OR. 


 


Summary

While concerns (3-7) can be addressed in XYZ, (1-2) look = fundamental to the XYZ architecture.

[1] https://tools.ietf.org/html/draft-richer-transactional-authz-08= #section-7

[2] https://w3c.github.io/vc-data-model/

I=E2=80=99m = not sure what you intended to bring up about VC=E2=80=99s in your email, = because I didn=E2=80=99t see a back-reference to this, but I=E2=80=99m = glad you did mention it. This is an example of a query, assertion, and = proofing data model for users that uses a structure and language that is = outside of the OIDC world, but existing parallel to it. 

I meant to = include [2] as another claim schema in point (6) above. In XAuth, you = will see that "vc" is another object in the "claims" Object.
 
I believe our protocol needs to be flexible enough to allow = this kind of thing on input (the client presenting information about who = the user is, as well as requesting specific information about the user) = and output (the AS claiming information about the user), in addition to = the client being given something that it can then in turn use with = another service down the line to present user information. The world is = moving away from an IdP-driven identity model, and we need to keep = moving with it and enable it here.

We agree on the = flexibility. The XAuth proposal is to namespace the schemas so that = adopting existing schemas, or using a new one is = straightforward.

The XYZ proposal is to have a core namespace for = common elements and additionally to allow other namespaces to be added = in as needed.

 =E2=80=94 = Justin




Thanks,
 =E2=80=94 Justin


3D""=E1=90=A7
-- 
Txauth = mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

3D""=E1=90=A7

= --Apple-Mail=_1FAC5CFF-639E-4E53-9446-0607D7938AA7-- From nobody Mon Jun 8 11:58:40 2020 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 E14843A0EF2 for ; Mon, 8 Jun 2020 11:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 5lppcBvHWDUX for ; Mon, 8 Jun 2020 11:58:34 -0700 (PDT) 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 A5E1E3A0EF1 for ; Mon, 8 Jun 2020 11:58:33 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id i27so10929303ljb.12 for ; Mon, 08 Jun 2020 11:58:33 -0700 (PDT) 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=JoPgEU9knwERODokWd2xl8WFonVs7B6iuF5cnF69Lh4=; b=En2NN8s/ZBb8FVrhaWhTrAGsozcqIeh6sB5h8/EPJUi8uvrUGCJJXj1s91dxsMQi+Y DyRKvGmJD8qCaU1a8hRTZ+E3+QVbw2MItvKYwCOG1/VJkrrZ1vqZkDJgaGa9Ly9c4nXP cP8h/5kaj4zc3hNL1Bwet21g66tq5nOMWCxKtQFvVBR8v4Lx6Bn8QiYqRfC4O8NzqmLv zSxQ/dQHoi8LoneuXxK/cSSgCNpyraUuL/maIsfUCKRY/hhSTdy9XiNsFoNTfEWVCKyr VSsQ6UWB7xaZpjF2PkVyEgdk8XFqrE/qMqAWS6losUEVrifJ+HjougLR9lJ8jGZe/zxm MSxg== 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=JoPgEU9knwERODokWd2xl8WFonVs7B6iuF5cnF69Lh4=; b=poolbgr+wkpEEeSp8NU3SVgr5RxhIkAOKImzqDO7zO+IbtuZqNG0iiULi3v18qiJuj yQYy65EfXsK7D1OUOAmFzWMYQJ6odTYqGMFG7KGLOi7jT4AUZxiywc6VbKanpcQ4Ho8x 8m4eBjGk/8tmjS6JjIRA1XPos1ZPs2rat5188CjH40qiJAIbjxXKg+XKVcAGTW+rd4Vm DByOeUegxYRxvZDNG0/GrqvRv9jW8RVPcieprGA54ysUiuCJIesvGBley0zQg/bjp1li cjclGC9ncvth2IXgjCM+ldDhyyJtSqXDxe5fhQCNuMZWz4zEj69NmjZ8lGr3x65xHEUS Xs2A== X-Gm-Message-State: AOAM532v5KWf6aVNSfRy+UWd5HhlpRQK4gikdWglLApAg0Sc2SP6GsQg E0iBcXVW4/4i2D63Ba/yC794Ix/w6YOQklht09U= X-Google-Smtp-Source: ABdhPJyJSiWup0AfwDK9PcZNYBo34Gc4ccauzlQtjHTumGT4uGQ6TVRQeyaBXEFsiI1UJG/McsrcvF54/Luz5kw//eY= X-Received: by 2002:a05:651c:3cc:: with SMTP id f12mr11857299ljp.244.1591642711378; Mon, 08 Jun 2020 11:58:31 -0700 (PDT) MIME-Version: 1.0 References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> In-Reply-To: From: Dick Hardt Date: Mon, 8 Jun 2020 11:58:03 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000006bcea905a7973297" Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 08 Jun 2020 18:58:39 -0000 --0000000000006bcea905a7973297 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 8, 2020 at 5:29 AM Justin Richer wrote: > > >> >> >> *XYZ vs XAuth* >> >> The remaining major differences between XYZ and XAuth are areas I have >> concerns about. (I will continue to use XYZ and XAuth refer to each draf= t). >> The concerns are: >> >> *1) API in JSON vs URI and HTTP Verb* >> >> In XYZ, all calls are to the same endpoint as an HTTP POST. The AS must >> parse the JSON to determine what to do. >> >> XAuth has a RESTful interface. A Grant Request starts at the GS URI, and >> Grants and Authorizations are returned as URI resources. Creating a Gran= t >> is done with a POST, reading a Grant is done with a GET. >> >> With URIs and HTTP verbs, A large scale GS can easily implement >> independent services for each functionality as routing of requests can = be >> done at the HTTP layer based on the URI and HTTP verb. This allows a >> separation of concerns, independent deployment, and resiliency. >> >> >> As I have said many, many times, both on the list and in the >> documentation for XYZ, this is an area that is worth discussing within t= he >> working group. It=E2=80=99s been tagged a potential direction in XYZ fro= m early >> days, but not something that we=E2=80=99ve pursued because it hasn=E2=80= =99t been needed in >> the spaces we=E2=80=99ve used it. >> >> So saying this is a fundamental aspect of XYZ and implying that it=E2=80= =99s a >> non-starter for it to not be built that way is misdirection. I hope that >> the conversation here in this group can continue without you ignoring or >> dismissing previous statements like this as we discuss things. >> > > I'm comparing the two drafts we have today, not what the drafts could be. > You have consistently stated that there is just one end point in the XYZ > model, and that handles represent the transaction rather than URIs -- as = you > state again below in your response to point 4. > > I find it is much easier for people to understand a proposal to write it > up. I could not see how to easily modify XYZ to support the models I > envisioned, which is why I wrote XAuth. > > > You and I both agree that things are easier to understand when written up= , > and that=E2=80=99s why I have produced significant write-ups of both the = current > state and the potential future state of XYZ during its lifetime, and > continue to do so. The ID is only one of these artifacts, and I find it > problematic that you dismiss any and all additional material. > An ID is submitted under the IETF IPR regime. While you have written much about XYZ, what is before the group are the IDs. > > As both drafts are inputs to a proposed working group, and not final > systems, they should be compared not only for what=E2=80=99s there but fo= r what > direction they could go. To do otherwise is to ignore the changes that a > working group can and will make on its inputs in pursuit of a general > solution. It is not my intent that XYZ, as currently proposed, be simple > accepted as-is. In fact, I hope it=E2=80=99s not, as the entire point of = me trying > to start this working group was to bring a community together to build > something new, useful, and powerful. My contention with your statement, i= f > you read what I said, is not that XYZ doesn=E2=80=99t do something today,= but that > in your view it cannot do something. The entire purpose of this exercise = is > to compare possibility. > The documents are text and obviously can be edited to be anything. What we are debating are the proposed approaches. > > So then: let=E2=80=99s unpack that possibility. Checking my notes on this= topic, I > see a pretty straightforward way to do this kind of thing. Note that here= in > I=E2=80=99ll be using the native terminology of XYZ, including =E2=80=9Ct= ransaction=E2=80=9D and > =E2=80=9Chandle=E2=80=9D, for consistency and to avoid confusion. Current= ly, the spec has > the Tx endpoint return a reference to the ongoing transaction, known as a > handle. This credential has a value and a presentation method, and it=E2= =80=99s > returned at the top level of the response: > > "handle": { > "value": "80UPRY5NM33OMUKMKSKU", > "type": "bearer" > } > > It would be very simple for this credential to also include a URI for it > to be used at: > > "handle": { > "value": "80UPRY5NM33OMUKMKSKU", > "type": =E2=80=9Cbearer=E2=80=9D, > =E2=80=9Curi": =E2=80=9Chttps://server.example/tx/foo-123" > } > > Or if we wanted to, we could even break it out into a multi part structur= e: > > =E2=80=9Ctransaction": { > "handle": { > "value": "80UPRY5NM33OMUKMKSKU", > "type": =E2=80=9Cbearer=E2=80=9D > } > =E2=80=9Curi": =E2=80=9Chttps://server.example/tx/foo-123" > } > > > This pattern of supplying both a credential and a URL for the client to > use in a tightly-coupled fashion is one that has been used before and we > know works. It=E2=80=99s the basis of RFC7592 and ODIC=E2=80=99s Dynamic = Registration, for > example. What=E2=80=99s important here is that the client is told exactly= where to > go. This URL could be the transaction endpoint itself, it could be a > RESTful style API, it could be a graph API node, it could be a management > service on another cluster. The protocol quite frankly shouldn=E2=80=99t = care about > this, and shouldn=E2=80=99t dictate to the AS how to deploy its parts. In= stead, the > protocol should concern itself only with the interconnection of > well-defined components. By providing both a handle and a target URL we > allow the AS to decide whether it wants to dispatch based on URL, handle, > or something else that it gets to decide. > > Note that this credential, the handle, still needs to be presented in the > context of the client=E2=80=99s key proofing that was used to start thing= s off, so > it isn=E2=80=99t fully a bearer access token. This makes it significantly= harder > for an attacker to do a man-in-the-middle attack with a fake AS, since th= ey > can=E2=80=99t get a client to use the attacker=E2=80=99s keys or vice ver= sa. But this also > means that I don=E2=80=99t think we can use an access token here, because= the > client needs to be able to present its keys in a consistent manner and th= at > might include its own use of an Authorization header, depending on the ke= y > proofing method. We shouldn=E2=80=99t step on that space. Additionally, t= he client > is going to be providing additional information in the follow-up requests > anyway, such as a reference from the front-channel callback, the signed > response to a cryptographic challenge, an identifier for a push endpoint, > etc. Since we=E2=80=99re in the back channel we=E2=80=99re not limited to= just stuffing > things into URLs, and these can all be presented as part of the protocol > request. > > Furthermore, this handle should be independent from its use in any > follow-up requests because it should also be able to be used to start a n= ew > transaction in a new context. This kind of step-up authorization is > something that people have long desired in OAuth 2 and have hacked togeth= er > in a few different ways in the wild, but we can do it here. Now of cours= e > we could hack around this by providing the grant URL in a new transaction > request, but that unnecessarily conflates the identifier (the URL) with t= he > access method. > > Additionally, the handle in my implementations of XYZ have all been rando= m > values, but that doesn=E2=80=99t need to be the case at all. For a distri= buted > system, the AS might want to pack information about the transaction into = an > encrypted bundle and pass it to the handle in a more stateless/serverless > fashion. If we force the AS to put that information into the URL itself, > then we=E2=80=99re going to run into many of the same problems that we do= in the > front channel of OAuth 2 today and end up with some of the same workaroun= ds > and patches. This is the back channel, and we should make use of the fact > that the client can send more than just a plain GET to a URL. > The front channel is problematic as the Client is not communicating directly to an AS. I don't see how those issues would apply to a Client doing a GET of a URL. > > As an aside, this approach of bundling a target with the handle is > something that=E2=80=99s been brought up on this list already, and I know= there=E2=80=99s > appetite for addressing it with regard to access tokens. Namely, there ar= e > a few different groups that want to be able to indicate to the client whe= re > it should use an access token. This has implications for multiple access > tokens and resource set descriptions, among other key aspects of the > protocol. This is a difficult and complex problem that fans out quickly, > but thanks to previous indication of interest from the members of this > list, it is within our proposed charter and I look forward to discussing > this issue as the group gets going. > > Now with that said, there are still some good reasons to define it as a > single endpoint. Namely, the kinds of responses you get from starting a > transaction are the same as those returned from continuing a transaction = in > progress. For example, with the functionality split, you now have two > places in your architecture that could return an access token, depending = on > if the policies allow for the token to be issued without user interaction > (the client credentials equivalent) or not (the auth code equivalent). > Furthermore, the inputs to the request on both sides are largely the same= =E2=80=94 > much of the information that you might present in a follow-up could be > presented in an initial request. As such, this is not a purely restful > process unless you jump through some additional hoops to force it to be, > like making the client do a =E2=80=9CGET=E2=80=9D on the results of the r= equest in order to > get its access token instead of returning it directly. However, not even > XAuth requires this, for what I hope are obvious reasons. This is the kin= d > of thing that needs to be balanced against the benefits of splitting the > endpoints, and something the group needs to debate and come to terms with= . > A GS implementation can decide to only return an authorization from doing a GET on the AZ URL. Returning only an AZ URL is an option in XAuth. Similarly, we could do the same for a Grant URI. > > Using a different URI, optionally, isn=E2=80=99t the problem, and that co= uld > easily be added to the. Removal of the separate handle is the problem I > have with the XAuth approach. > In XAuth, the Grant URI is the GS URI + TBD + handle Given we have asymmetric crypto as a requirement, it is unclear what having two pieces of random signal provide. > > > >> >> Additionally, I find XAuth=E2=80=99s restrictions on the structure of th= e Grant >> URI potentially problematic, namely that it has to start with the server= =E2=80=99s >> URL. This will lead to deployments needing to bend their setups with >> proxies or redirectors to make things fit, which you yourself have said = is >> going to be an issue for things like supporting a short redirect URL vs.= a >> long redirect URL. Your complaint there was one of latency and complexit= y, >> why does that not apply here? But most fundamentally, I do not see what >> value this restriction brings to the system. If the value is coming back >> from the GS endpoint, and the client is getting all of its pointers from >> there, what=E2=80=99s the point of dictating how that has to look? >> > > Requiring the Grant URI to start with the GS URI is open to discussion. I= t > is not clear to me why a deployment would need to have a redirector. Larg= e > scale deployments I have worked on have a router / proxy that routes > requests to internal services. Having all the URIs start with the GS URI > enables all GNAP operations to be routed in the same place. > > > You still haven=E2=80=99t addressed why you think that this is a reasonab= le > requirement or assumption here but not when dealing with long/short URLs > for QR codes. What is the difference? > Short URLs generally use a short host name as well as a short path. Most REST interfaces have the pattern I am proposing. A mental model many developers are familiar with. > > > An advantage of starting with the GS URI is that any software on the > Client side knows which GS it belongs to. A Grant URI passed to a Client = in > a GS initiated login allows the Client to know if it trusts the GS before > operating on the Grant URI. > > > Is the client then required to make this check for security purposes? Or > can we protect against this kind of confusion by building the system to b= e > resilient to it in a different way? I have opted for the latter in XYZ=E2= =80=99s > design. > > > If the Grant URI can be any URI, then a Client could be tricked into > operating on a Grant URI it should not be operating on. > > > This is not true if the client also needs to present its keys with the > request, is it? Am I missing an attack here? > An attacker being able to trick a Client to authenticate somewhere it is not intending to go seems like something worth preventing. The GS initiated login is easily supported with the URI representing the Grant. See https://tools.ietf.org/html/draft-hardt-gnap-advanced-00#section-5 > > > >> >> >> *2) Handles for all Clients vs Client ID and Client Handle* >> >> In XYZ, both pre-registered clients and dynamic clients use a handle. >> >> In XAuth, the Client ID refers to a pre-registered client, and the Clien= t >> Handle is specific to an instance of a dynamic client. Using separate te= rms >> clearly differentiates which identifier is being presented to the GS. >> >> This allows a GS to use separate mechanisms for managing pre-registered >> clients and dynamic clients, an important consideration as there can eas= ily >> be millions of instances of a single dynamic client. >> >> Additionally, developers are already familiar with what a Client ID is >> for pre-registered clients. >> >> >> I see the inconsistency in the XAuth draft to be problematic. Under this >> proposed model, I now need to be able to track clients using different >> kinds of identifiers depending on what kind of registration they used? W= hy >> build in this dichotomy? >> > > A GS implementation is free to use the same identifiers and storage syste= m > for Client IDs and Client Handles. > > >> >> One of the design goals of XYZ was to bring consistency to the haphazard >> world of OAuth 2, where a client ID could mean a class of client softwar= e >> or an individual client or a cluster of servers or any number of other >> things. >> > > In XYZ a client handle refers to both registered clients, and dynamic > clients. That seems to continue to be haphazard. > > Dynamic Registration needed to use Client ID as the rest of OAuth only > understood that identifier for a client. > > XAuth allows each type of client to have their own identifier. > > > The key handle represents a set of keying material that is passed by > reference instead of by value. That keying material is something that the > server has seen before. It can be associated with a piece of software tha= t > has either been statically registered, or it could be a key that showed u= p > dynamically and the server is providing a shortcut to reference it. > At the start of the protocol, the server is either looking up the key from a handle / Client ID if it is a pre-registered client. Correct? Once the server has done that, it can associate the key with the Grant. > > In both cases, static and dynamic clients can present their keys by value= and > get expected behavior. Instead of a fuzzy definition where =E2=80=9Cclien= t=E2=80=9D could > mean an instance, a class, or a concept, we > You did not complete this sentence. I'm confused by this I would think that the server would require a pre-registered client to have a private key tied to the public key the server has for the Client. No? > > This is why I want to get away from a =E2=80=9Cclient identifier=E2=80=9D= because there is > not a concrete and consistent definition of what a =E2=80=9Cclient=E2=80= =9D means across > the wide variety of use cases we already know we have. > I would take a different approach. Let's clarify what a Client is. We are using the term. Having it be fuzzy and avoiding what a Client is seems the wrong approach. > > > >> >> And as I=E2=80=99ve demonstrated with an implementation on top of the MI= TREid >> Connect OAuth 2 server, it=E2=80=99s completely possible and well within= -protocol >> to pass in a static client ID within the XYZ=E2=80=99s =E2=80=9Ckey hand= le=E2=80=9D field and have >> things work as expected. Yes, it=E2=80=99s called something different = =E2=80=94 but if >> that=E2=80=99s a problem, then XAuth=E2=80=99s renaming of the Authoriza= tion Server to a >> Grant Server is going to be significantly more confusing for developers, >> don=E2=80=99t you think? >> > > Nope. > > > > >> >> >> *3) Transaction Handles are One Time Use* >> >> In XYZ, transaction handles are one time use [1]. In the OAuth WG >> discussion on one time use refresh tokens, clients are often distributed >> across components, which complicates one time use references. >> >> One time use transaction handles also makes them inconsistent with the >> display, resource, user, and key handles. >> >> >> Transaction handles being one-time-use is based on experience with a >> session fixation attack against UMA (now patched): >> >> >> https://kantarainitiative.org/confluence/display/uma/Understanding+the+S= ession+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+Mitigation >> >> Clients with distributed components are going to have to be considered i= n >> our core model, and so there are considerations and tradeoffs in terms o= f >> security and deployability that we need to address here. These are the s= ame >> kinds of discussions that we=E2=80=99re having in OAuth 2, as you point = out, and so >> we can not only apply that experience and knowledge to this, but we can >> build something that behaves better than a refresh token for this purpos= e. >> > > The XAuth proposal is to use a URI to represent the authorization. > > > I know what XAuth does, and it does not help that kind of attack. > Automatic credential rotation on use is a well established mitigation > mechanism that is impossible if the only item you have is a URI that is > given exactly once within the protocol. This is in addition to the > discussion above regarding issuing the credential alongside the URI. > I don't see how that attack is possible. The Grant URI has a random element in it that the GS uses to retrieve information about the Grant, including the Client that created it. > > > >> >> >> *4) New User Identifier* >> >> XYZ introduces a new identifier for the user, a User Handle. Unclear why >> a new type of user identifier is needed, except for the desire to have a >> handle for everything. >> >> >> This is based directly on the Persisted Claims Token concept from UMA2, >> where a client (that is trusted to make such a statement) can say that i= t >> reasonably believes that the current user interacting with this client i= s >> the same user that it=E2=80=99s been interacting with before, for use wi= th a future >> request. An AS can take this signal into consideration when processing t= he >> request, potentially avoiding unnecessary interaction and friction. >> > > My statement is that it was unclear why it was needed. Perhaps you can > add a Rationale section to XYZ? > > >> >> I=E2=80=99m not surprised that you see this as =E2=80=9Cjust applying a = handle for >> everything=E2=80=9D considering you=E2=80=99ve previously objected to th= e use of the >> pass-by-reference construct for other aspects of the protocol in the pas= t >> as well. Each component in XYZ that has a separate handle has one for >> specific and documented reasons, and it=E2=80=99s a core feature that th= ese are >> handled (pun intended) in a consistent and predictable manner. >> > > This is why I state that it seems hard to change (1) above. > > >> >> *5) Interaction Capabilities vs Modes* >> >> In XYZ, the capabilities are expressed by the client, and the GS states >> which capabilities it will accept. This can make it difficult for the GS= to >> enforce the interaction choices as the client can mix and match which >> capabilities are returned. For example, a GS may not want to support a >> redirect without a callback to protect itself from session fixation >> attacks. In XAuth, the interaction modes provide clarity on the mode of >> interaction and the security properties. For example the GS may support >> both user_code and redirect modes, but not the indirect mode which is >> subject to session fixation attacks. >> >> >> If the GS doesn=E2=80=99t want to accept a redirect without a callback, = it can >> because the request will have a redirect, but not a callback, and it can >> reject the request. What makes you believe that this is not detectable o= r >> not possible in XYZ? >> > > I did not say it could not be done, I'm saying it is more difficult in XY= Z > than in XAuth > > > Can you explain to me how it=E2=80=99s more difficult in XYZ? I have expl= ained how > it can be done and I am failing to see why you think it=E2=80=99s harder. > Having both a handle and a URI seems more complicated than just a URI. If you think that having a URI in addition to a handle makes sense, how about you put that into your draft and see how it works? For example: How is a transaction updated? How are separate access tokens refreshed? Refreshing an access token in XYZ returns a full transaction response per Section 9.3 which refers to Section 8. By using URIs and methods, XAuth has an easy to understand API for CRUD operations on Grants and Authorizations. +--------------+-----------+--------+-----------------------------+ | request | http verb | uri | response | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Create Grant | POST | GS URI | interaction, wait, or grant | +--------------+-----------+--------+-----------------------------+ | List Grants | GET | GS URI | grant list | +--------------+-----------+--------+-----------------------------+ | Verify Grant | PATCH | Grant | grant | | | | URI | | +--------------+-----------+--------+-----------------------------+ | Read Grant | GET | Grant | wait, or grant | | | | URI | | +--------------+-----------+--------+-----------------------------+ | Update Grant | PUT | Grant | interaction, wait, or grant | | | | URI | | +--------------+-----------+--------+-----------------------------+ | Delete Grant | DELETE | Grant | success | | | | URI | | +--------------+-----------+--------+-----------------------------+ | Read AuthZ | GET | AZ URI | authorization | +--------------+-----------+--------+-----------------------------+ | Update AuthZ | PUT | AZ URI | authorization | +--------------+-----------+--------+-----------------------------+ | Delete AuthZ | DELETE | AZ URI | success | +--------------+-----------+--------+-----------------------------+ | GS Options | OPTIONS | GS URI | metadata | +--------------+-----------+--------+-----------------------------+ | Grant | OPTIONS | Grant | metadata | | Options | | URI | | +--------------+-----------+--------+-----------------------------+ | AuthZ | OPTIONS | AZ URI | metadata | | Options | | | | +--------------+-----------+--------+-----------------------------+ > > > >> >> The modes in XAuth are much more limiting, as the mixing of different >> interaction methods is already something that we need to start figuring >> out. Let=E2=80=99s say, for example, a client can do a redirect, accept = a >> CIBA-style ping, or do a direct app2app communication. There=E2=80=99s a= natural >> preference the client will have here: if it can talk to another app >> directly, it=E2=80=99ll try that first. If that doesn=E2=80=99t work, it= can get a push >> notification sent, and if all that fails, it can pop open a browser. If >> I have to pick just one of those modes when I make the request, then the >> client needs to make three different requests to the AS before I get >> anything that works. >> > > Have you read the revised draft? As I noted above, I have added > negotiation. The Client can state all the modes it wants, the GS can > respond with the modes it will support, and the Client can offer the User > any modes returned from the GS. > > > Yes, did you read what I wrote? I think we=E2=80=99re talking past each o= ther. > This is not how XAuth is written currently. The Client can list all of the modes it wants to use. The Server will return all the modes that fit in its policy for the Grant Request. Why would the Client need to make different requests? per https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.2 The interaction object contains one or more interaction mode objects per Section 5 Three modes are defined here: https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-5 More modes may defined in extensions, or in this document. > > >> >> This kind of mixing is important to allow for different modalities of >> client. In fact, the return callback could be tied to the entry of a use= r >> code, not just an outbound redirect. How the client gets the user to the= AS >> and how the user gets back are separate questions, and we need flexibili= ty >> in both. >> > > Yes, we need flexibility. We also need the GS to be able to easily enforc= e > what can happen. > > >> XAuth ties them together in the same way that OAuth 2 does, and this is >> an unnecessary restriction that does not add security or simplicity. >> >> *6) Claims at Top Level vs Namespaced * >> >> In XYZ, there is one schema for claims, and they are requested as: >> >> "claims": { >> "subject": true, >> "email": true >> } >> >> Whereas in XAuth, claims are in their own namespace: >> >> "claims": { >> "oidc": { >> "id_token" : { >> "email" : { "essential" : true }, >> "email_verified" : { "essential" : true } >> }, >> "userinfo" : { >> "name" : { "essential" : true }, >> "picture" : null >> } >> } >> >> In this example, the client is requesting OIDC defined claims, the email >> to be in an ID Token, and the name and picture to be as text. While the = XYZ >> schema may be extended, there are already numerous schemas being used. T= he >> XAuth approach is to support existing and new schemas, rather than pick = one >> and/or create another one, and allows a Grant Request to contain claims >> from multiple schemas at the same time. >> >> >> Again, as I have said many times, this part of the request (as is the >> rest of the request) is extensible. The goal of the =E2=80=9Cclaims=E2= =80=9D object in XYZ >> was to propose a simple, common core. Is this the best set? Probably not= , >> but that=E2=80=99s why nothing is final yet, right? >> > > Yes, XYZ is extensible. It is not namespaced as XAuth is. > > > It is, though, as I said above. > Where? > > > >> >> If we wanted to allow for OIDC style claims objects, we have space to do >> exactly that, either as a sub-component of the existing claims object or= as >> a new top-level object in the request. This flexibility is important, as >> there are other schemas and other query languages that people might want= to >> support, including things like JWM: >> >> https://tools.ietf.org/id/draft-looker-jwm-01.html >> >> And at Mike Jones=E2=80=99s request, I=E2=80=99ve added notes in the cur= rent draft of XYZ >> to the places that will be extensible via registry or some other mechani= sm >> =E2=80=94 but the goal was to have everything in there be extensible by = reasonable >> mechanisms in ways that will allow innovation to flourish without breaki= ng >> core and common functionality. >> >> I do not understand why you insist on painting XYZ as a static, >> inflexible, and unbending model when it is exactly the opposite. You don= =E2=80=99t >> have to externalize every piece of flexibility in order to have it, and = I >> really hope that these myths don=E2=80=99t keep getting repeated in the = group. >> > > All I am doing is comparing what is written. I'm not trying to paint XYZ > anything. > > > Except that you are doing that =E2=80=94 when I raise a concern on someth= ing in > XAuth you often respond with =E2=80=9Coh but that=E2=80=99s up for debate= !=E2=80=9D while > dismissing the same counter-argument with =E2=80=9CI=E2=80=99m comparing = what=E2=80=99s written=E2=80=9D. > Your comment was that I was "insisting" on a specific feature (the Grant URI MUST start with the GS URI). I think the requirement has many advantages, but I don't have a strong conviction about it, and am open to debating it. > > These are input proposals, everything is up for debate. That=E2=80=99s wh= y we=E2=80=99re > debating. > Yes, we are debating the pros and cons of each proposal. > > > >> >> >> *7) No Authorization Type* >> >> Similar to (6), XYZ has a single schema for how to request access to a >> resource. While that schema is extensible, it requires adaption from any >> system with an existing schema. XAuth has a type for each authorization >> request (oauth2, rar), allowing existing schemas and new schemas to be >> supported. >> >> >> This is a ridiculous claim because the RAR format is a back port of the >> XYZ format to an OAuth 2 architecture. If you consider that RAR is >> extensible, then XYZ is extensible by your same definitions. In addition= , >> if there are other resource query languages out there beyond these, and = we >> can support them just like we would support additional claims query >> languages. >> >> Furthermore, as I=E2=80=99ve said before, XAuth doesn=E2=80=99t allow a = clean way to >> define the use of both OAuth 2 scopes and rich requests. XYZ does this b= y >> allowing scope-style strings and full JSON objects to be specified at th= e >> same level in the same data structure, so there=E2=80=99s no confusion o= ver how >> they=E2=80=99re grouped or applied. XAuth makes me choose ahead of time = to use one >> or the other, effectively at the API level. So I can no longer easily ca= ll >> for, say, =E2=80=9Clogin information=E2=80=9D (a general scope) along wi= th =E2=80=9Ctransaction >> history for a specific bank account=E2=80=9D (a rich data object) in the= same >> request. Even RAR handles this better than XAuth by simply letting the >> =E2=80=9Cscope=E2=80=9D parameter also be passed along side the authoriz= ation_details >> object, but there are significant complexity issues with this as there >> isn=E2=80=99t a clear way to combine these concepts in the OAuth 2 world= . I think >> we can do so much better here, and XYZ proposes one such consistent way = to >> do that by defining the scope-equivalent to be a pass-by-reference versi= on >> of the rich object that is passed-by-value. If clients have a shortcut (= a >> scope), they can use that; if they need the expressiveness of the resour= ces >> structure, they can do that. >> > > Once again it does not seem that you have read the latest draft. XAuth > allows existing OAuth 2 scopes, OR OAuth 2 scopes with RAR, OR a new type > authorization type that works differently. > > > I don=E2=80=99t think you read what I wrote here. I did read the new XAut= h draft > before replying, and my complaint is that it is still an OR. > It is an OR in that if the client is using the type "oauth_scope", they cannot have an "authorization_details" attribute, they can only have "scope= " If the client is using the type "oauth_rich", the client MUST include "authorization_details", and MAY include "scope" I have updated the the doc to better capture that: https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.4 and example 2 now is of type "oauth_rich" https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.2 > > > >> >> >> *Summary* >> >> While concerns (3-7) can be addressed in XYZ, (1-2) look fundamental to >> the XYZ architecture. >> >> [1] >> https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-= 7 >> >> [2] https://w3c.github.io/vc-data-model/ >> >> >> I=E2=80=99m not sure what you intended to bring up about VC=E2=80=99s in= your email, >> because I didn=E2=80=99t see a back-reference to this, but I=E2=80=99m g= lad you did mention >> it. This is an example of a query, assertion, and proofing data model fo= r >> users that uses a structure and language that is outside of the OIDC wor= ld, >> but existing parallel to it. >> > > I meant to include [2] as another claim schema in point (6) above. In > XAuth, you will see that "vc" is another object in the "claims" Object. > > >> I believe our protocol needs to be flexible enough to allow this kind of >> thing on input (the client presenting information about who the user is,= as >> well as requesting specific information about the user) and output (the = AS >> claiming information about the user), in addition to the client being gi= ven >> something that it can then in turn use with another service down the lin= e >> to present user information. The world is moving away from an IdP-driven >> identity model, and we need to keep moving with it and enable it here. >> > > We agree on the flexibility. The XAuth proposal is to namespace the > schemas so that adopting existing schemas, or using a new one is > straightforward. > > > The XYZ proposal is to have a core namespace for common elements and > additionally to allow other namespaces to be added in as needed. > I don't follow how this would work. Perhaps you could provide an example in JSON? /Dick =E1=90=A7 --0000000000006bcea905a7973297 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 8, 2020 at 5:29 AM Justin= Richer <jricher@mit.edu> wrot= e:
<snip>
=
=C2=A0


XYZ vs XAuth
The remaining major differences between XYZ and XAuth are areas= I have concerns about. (I will continue to use XYZ and XAuth refer to each= draft). The concerns are:

1) API in JSON vs UR= I and HTTP Verb

In XYZ, all calls are t= o the same endpoint=C2=A0as an HTTP POST. The AS must parse the JSON to det= ermine what to do.=C2=A0

XAuth has a RESTful inter= face. A Grant=C2=A0Request starts at the GS URI, and Grants and Authorizati= ons are returned as URI resources. Creating a Grant is done with a POST, re= ading a Grant is done with a GET.=C2=A0

With URIs and HTT= P verbs, A large scale GS can easily implement independent services for=C2= =A0each=C2=A0 functionality as routing of requests can be done at the HTTP = layer based on the URI and HTTP verb. This allows a separation of concerns,= independent deployment, and resiliency.

As I have said many, many times, both on the list and in th= e documentation for XYZ, this is an area that is worth discussing within th= e working group. It=E2=80=99s been tagged a potential direction in XYZ from= early days, but not something that we=E2=80=99ve pursued because it hasn= =E2=80=99t been needed in the spaces we=E2=80=99ve used it.

<= /div>
So saying this is a fundamental aspect of XYZ and implying that i= t=E2=80=99s a non-starter for it to not be built that way is misdirection. = I hope that the conversation here in this group can continue without you ig= noring or dismissing previous statements like this as we discuss things.=C2= =A0

I'm comparing the= two drafts we=C2=A0have today,=C2=A0not what the drafts could be. You have= consistently stated that there is just one end point in the XYZ model, and= that handles represent the transaction rather than URIs -- as=C2=A0<= /span>you state again=C2=A0below in your response to point 4.

=
I find it is much easier for people to understand a proposal to write = it up. I could not see how to easily modify XYZ to support the models I env= isioned, which is why I wrote XAuth.

You and I both agree that things are easier to understand= when written up, and that=E2=80=99s why I have produced significant write-= ups of both the current state and the potential future state of XYZ during = its lifetime, and continue to do so. The ID is only one of these artifacts,= and I find it problematic that you dismiss any and all additional material= .

An ID is submitted unde= r the IETF IPR regime. While you have written much about XYZ, what is befor= e the group are the IDs.
=C2=A0
<= br>
As both drafts are inputs to a proposed working group, and no= t final systems, they should be compared not only for what=E2=80=99s there = but for what direction they could go. To do otherwise is to ignore the chan= ges that a working group can and will make on its inputs in pursuit of a ge= neral solution. It is not my intent that XYZ, as currently proposed, be sim= ple accepted as-is. In fact, I hope it=E2=80=99s not, as the entire point o= f me trying to start this working group was to bring a community together t= o build something new, useful, and powerful. My contention with your statem= ent, if you read what I said, is not that XYZ doesn=E2=80=99t do something = today, but that in your view it cannot do something. The entire purpose of = this exercise is to compare possibility.

The documents are text and obviously can be edited to be an= ything. What we are debating are the proposed approaches.=C2=A0
= =C2=A0

So then: let=E2=80=99= s unpack that possibility. Checking my notes on this topic, I see a pretty = straightforward way to do this kind of thing. Note that herein I=E2=80=99ll= be using the native terminology of XYZ, including =E2=80=9Ctransaction=E2= =80=9D and =E2=80=9Chandle=E2=80=9D, for consistency and to avoid confusion= . Currently, the spec has the Tx endpoint return a reference to the ongoing= transaction, known as a handle. This credential has a value and a presenta= tion method, and it=E2=80=99s returned at the top level of the response:

=C2=A0 =C2=A0=C2=A0"handle":=C2=A0{
"value":=C2=A0"80U= PRY5NM33OMUKMKSKU",
&= quot;type":=C2=A0"bearer"
=C2=A0 =C2=A0 }

It would be very simple for this credential to also = include a URI for it to be used at:

This pattern of supplying both a credential a= nd a URL for the client to use in a tightly-coupled fashion is one that has= been used before and we know works. It=E2=80=99s the basis of RFC7592 and = ODIC=E2=80=99s Dynamic Registration, for example. What=E2=80=99s important = here is that the client is told exactly where to go. This URL could be the = transaction endpoint itself, it could be a RESTful style API, it could be a= graph API node, it could be a management service on another cluster. The p= rotocol quite frankly shouldn=E2=80=99t care about this, and shouldn=E2=80= =99t dictate to the AS how to deploy its parts. Instead, the protocol shoul= d concern itself only with the interconnection of well-defined components. = By providing both a handle and a target URL we allow the AS to decide wheth= er it wants to dispatch based on URL, handle, or something else that it get= s to decide.=C2=A0

Note that this credential, the = handle, still needs to be presented in the context of the client=E2=80=99s = key proofing that was used to start things off, so it isn=E2=80=99t fully a= bearer access token. This makes it significantly harder for an attacker to= do a man-in-the-middle attack with a fake AS, since they can=E2=80=99t get= a client to use the attacker=E2=80=99s keys or vice versa. But this also m= eans that I don=E2=80=99t think we can use an access token here, because th= e client needs to be able to present its keys in a consistent manner and th= at might include its own use of an Authorization header, depending on the k= ey proofing method. We shouldn=E2=80=99t step on that space. Additionally, = the client is going to be providing additional information in the follow-up= requests anyway, such as a reference from the front-channel callback, the = signed response to a cryptographic challenge, an identifier for a push endp= oint, etc. Since we=E2=80=99re in the back channel we=E2=80=99re not limite= d to just stuffing things into URLs, and these can all be presented as part= of the protocol request.=C2=A0

Furthermore, this = handle should be independent from its use in any follow-up requests because= it should also be able to be used to start a new transaction in a new cont= ext. This kind of step-up authorization is something that people have long = desired in OAuth 2 and have hacked together in a =C2=A0few different ways i= n the wild, but we can do it here. Now of course we could hack around this = by providing the grant URL in a new transaction request, but that unnecessa= rily conflates the identifier (the URL) with the access method.=C2=A0
=

Additionally, the handle in my implementations of XYZ h= ave all been random values, but that doesn=E2=80=99t need to be the case at= all. For a distributed system, the AS might want to pack information about= the transaction into an encrypted bundle and pass it to the handle in a mo= re stateless/serverless fashion. If we force the AS to put that information= into the URL itself, then we=E2=80=99re going to run into many of the same= problems that we do in the front channel of OAuth 2 today and end up with = some of the same workarounds and patches. This is the back channel, and we = should make use of the fact that the client can send more than just a plain= GET to a URL.

The front = channel is problematic as the Client is not communicating directly to an AS= . I don't see how those issues would apply to a Client doing a GET of a= URL.
=C2=A0

As an= aside, this approach of bundling a target with the handle is something tha= t=E2=80=99s been brought up on this list already, and I know there=E2=80=99= s appetite for addressing it with regard to access tokens. Namely, there ar= e a few different groups that want to be able to indicate to the client whe= re it should use an access token. This has implications for multiple access= tokens and resource set descriptions, among other key aspects of the proto= col. This is a difficult and complex problem that fans out quickly, but tha= nks to previous indication of interest from the members of this list, it is= within our proposed charter and I look forward to discussing this issue as= the group gets going.

Now with that said, there a= re still some good reasons to define it as a single endpoint. Namely, the k= inds of responses you get from starting a transaction are the same as those= returned from continuing a transaction in progress. For example, with the = functionality split, you now have two places in your architecture that coul= d return an access token, depending on if the policies allow for the token = to be issued without user interaction (the client credentials equivalent) o= r not (the auth code equivalent). Furthermore, the inputs to the request on= both sides are largely the same =E2=80=94 much of the information that you= might present in a follow-up could be presented in an initial request. As = such, this is not a purely restful process unless you jump through some add= itional hoops to force it to be, like making the client do a =E2=80=9CGET= =E2=80=9D on the results of the request in order to get its access token in= stead of returning it directly. However, not even XAuth requires this, for = what I hope are obvious reasons. This is the kind of thing that needs to be= balanced against the benefits of splitting the endpoints, and something th= e group needs to debate and come to terms with.=C2=A0

A GS implementation can decide to only return = an authorization from doing a GET on the AZ URL. Returning only an AZ URL i= s an option in XAuth. Similarly, we could do the same for a Grant URI.=C2= =A0
=C2=A0

Usi= ng a different URI, optionally, isn=E2=80=99t the problem, and that could e= asily be added to the. Removal of the separate handle is the problem I have= with the XAuth approach.

In XAuth, the Grant URI is the GS URI=C2=A0+ TBD=C2=A0+ handle
<= br>
Given we have asymmetric=C2=A0crypto as a requirement, it is = unclear what having two pieces of random signal=C2=A0provide.
=C2= =A0

=C2=A0

A= dditionally, I find XAuth=E2=80=99s restrictions on the structure of the Gr= ant URI potentially problematic, namely that it has to start with the serve= r=E2=80=99s URL. This will lead to deployments needing to bend their setups= with proxies or redirectors to make things fit, which you yourself have sa= id is going to be an issue for things like supporting a short redirect URL = vs. a long redirect URL. Your complaint there was one of latency and comple= xity, why does that not apply here? But most fundamentally, I do not see wh= at value this restriction brings to the system. If the value is coming back= from the GS endpoint, and the client is getting all of its pointers from t= here, what=E2=80=99s the point of dictating how that has to look?

Requiring the Grant URI to start w= ith the GS URI is open to discussion. It is not clear to me why a deploymen= t would need to have a redirector. Large scale deployments I have worked on= have a router / proxy that routes requests to internal services. Having al= l the URIs start with the GS URI enables all GNAP operations to be routed i= n the same place.

Y= ou still haven=E2=80=99t addressed why you think that this is a reasonable = requirement or assumption here but not when dealing with long/short URLs fo= r QR codes. What is the difference?

=
Short URLs generally use a short host name as well as a short pa= th.=C2=A0

Most REST interfaces have the pattern I = am proposing. A mental model many developers are familiar with.=C2=A0
=
=C2=A0

<= div dir=3D"ltr" style=3D"font-family:Helvetica;font-size:12px;font-style:no= rmal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text= -align:start;text-indent:0px;text-transform:none;white-space:normal;word-sp= acing:0px;text-decoration:none">

<= div>An advantage of starting with the GS URI is that any software on the Cl= ient side knows which GS it belongs to. A Grant URI passed to a Client in a= GS initiated=C2=A0login allows the Client to know if it trusts the GS befo= re operating on the Grant URI.=C2=A0

Is the client then required to make this check for securi= ty purposes? Or can we protect against this kind of confusion by building t= he system to be resilient to it in a different way? I have opted for the la= tter in XYZ=E2=80=99s design.=C2=A0


If the Grant URI can b= e any URI, then a Client could be tricked into operating on a Grant URI it = should not be operating on.=C2=A0
=
This is not true if the client also needs to present its key= s with the request, is it? Am I missing an attack here?

An attacker being able to trick a Client to = authenticate somewhere it is not intending to go seems like something worth= preventing.=C2=A0

The GS initiated login is easil= y supported with the URI representing the Grant.



=C2=A0
=
=C2=A0


2) Handles for all Clients vs Client ID and Client Handle=

In XYZ, both pre-registered clients an= d dynamic clients use a handle.=C2=A0

In XAuth, th= e Client ID refers to a pre-registered client, and the Client Handle is spe= cific to an instance of a dynamic client. Using separate terms clearly diff= erentiates which identifier is being presented to the GS.=C2=A0
<= br>
This allows a GS to use separate mechanisms for managing pre-= registered clients and dynamic clients, an important consideration as there= can easily be millions of instances of a single dynamic client.
<= div>
Additionally, developers are already familiar=C2=A0with = what a Client ID is for pre-registered clients.

I see the inconsistency in the XAuth draft to be pro= blematic. Under this proposed model, I now need to be able to track clients= using different kinds of identifiers depending on what kind of registratio= n they used? Why build in this dichotomy?

A GS implementation is free to use the same identifiers an= d storage system for Client IDs and Client Handles.=C2=A0
=C2=A0<= /div>

<= /div>
One of the design goals of XYZ was to bring consistency to the ha= phazard world of OAuth 2, where a client ID could mean a class of client so= ftware or an individual client or a cluster of servers or any number of oth= er things.=C2=A0

In XYZ a= client handle refers to both registered clients, and dynamic clients. That= seems to continue to be haphazard.=C2=A0

Dynamic = Registration needed to use Client ID as the rest of OAuth only understood t= hat identifier for a client.

XAuth allows each typ= e of client to have their own identifier.

The key handle represents a set of keying material t= hat is passed by reference instead of by value. That keying material is som= ething that the server has seen before. It can be associated with a piece o= f software that has either been statically registered, or it could be a key= that showed up dynamically and the server is providing a shortcut to refer= ence it.

At the start of = the protocol, the server is either looking up the key from a handle / Clien= t ID if it is a pre-registered client. Correct?

On= ce the server has done that, it can associate the key with the Grant.
=
=C2=A0

In both cases, static and dynamic clients c= an present their keys by value and get expected behavior. Instead of= a fuzzy definition where =E2=80=9Cclient=E2=80=9D could mean an instance, = a class, or a concept, we=C2=A0

You did not complete this sentence.

I'm= confused by this=C2= =A0

I would think that the server would require a = pre-registered=C2=A0client to have a private key tied to the public key the= server has for the Client. No?
=C2=A0

This is why I want to get away from a =E2=80=9Cclient = identifier=E2=80=9D because there is not a concrete and consistent definiti= on of what a =E2=80=9Cclient=E2=80=9D means across the wide variety of use = cases we already know we have.

I would take a different approach. Let's clarify what a Client is= . We are using the term. Having it be fuzzy and avoiding what a Client is s= eems the wrong approach.=C2=A0
=C2=A0
=
=C2=A0

And as I=E2=80=99ve demonstrated = with an implementation on top of the MITREid Connect OAuth 2 server, it=E2= =80=99s completely possible and well within-protocol to pass in a static cl= ient ID within the XYZ=E2=80=99s =E2=80=9Ckey handle=E2=80=9D field and hav= e things work as expected. Yes, it=E2=80=99s called something different =E2= =80=94 but if that=E2=80=99s a problem, then XAuth=E2=80=99s renaming of th= e Authorization Server to a Grant Server is going to be significantly more = confusing for developers, don=E2=80=99t you think?

Nope.=C2=A0
<= br>
=C2=A0


3) Transaction Handles are One Time Use
=

In XYZ, transaction handles are one time use [1]= . In the OAuth WG discussion on one time use refresh tokens, clients are of= ten distributed across components, which complicates one time use reference= s.=C2=A0

One time use transaction handles also mak= es them inconsistent with the display, resource, user, and key handles.

Transaction handles be= ing one-time-use is based on experience with a session fixation attack agai= nst UMA=C2=A0(now patched):


Clients with distributed components are goin= g to have to be considered in our core model, and so there are consideratio= ns and tradeoffs in terms of security and deployability that we need to add= ress here. These are the same kinds of discussions that we=E2=80=99re havin= g in OAuth 2, as you point out, and so we can not only apply that experienc= e and knowledge to this, but we can build something that behaves better tha= n a refresh token for this purpose.

=
The XAuth proposal is to use a URI to represent the authorizatio= n.=C2=A0

I know wha= t XAuth does, and it does not help that kind of attack. Automatic credentia= l rotation on use is a well established mitigation mechanism that is imposs= ible if the only item you have is a URI that is given exactly once within t= he protocol. This is in addition to the discussion above regarding issuing = the credential alongside the URI.

I don't see how that attack is possible. The Grant URI has a r= andom element in it that the GS uses to retrieve information about the Gran= t, including the Client that created it.
=C2=A0

=C2=A0


4) New User Identifier
<= br>
XYZ introduces a new identifier for the user, a User Handle.<= span>=C2=A0Unclear why= a new type of user identifier is needed, except for the desire to have a h= andle for everything.


This is based directly on the Persisted Claims Tok= en concept from UMA2, where a client (that is trusted to make such a statem= ent) can say that it reasonably believes that the current user interacting = with this client is the same user that it=E2=80=99s been interacting with b= efore, for use with a future request. An AS can take this signal into consi= deration when processing the request, potentially avoiding unnecessary inte= raction and friction.

My<= span>=C2=A0statement=C2=A0is that it was unclear why it was needed. Perhaps y= ou can add a Rationale section to XYZ?
=C2=A0

I=E2=80= =99m not surprised that you see this as =E2=80=9Cjust applying a handle for= everything=E2=80=9D considering you=E2=80=99ve previously objected to the = use of the pass-by-reference construct for other aspects of the protocol in= the past as well. Each component in XYZ that has a separate handle has one= for specific and documented reasons, and it=E2=80=99s a=C2=A0= core feature that these are= handled (pun intended) in a consistent and predictable manner.

This=C2=A0is why I state that it see= ms hard to change (1) above.=C2=A0
=C2=A0

5) Interaction Capabilities vs Modes=

In XYZ, the capabilities are expre= ssed by the client, and the GS states which capabilities it will accept. Th= is can make it difficult for the GS to enforce the interaction choices as t= he client can mix and match which capabilities are returned. For example, a= GS may not want to support a redirect without a callback to protect itself= from session fixation attacks. In XAuth, the interaction modes provide cla= rity on the mode of interaction and the security properties. For example th= e GS may support both user_code and redirect modes, but not the indirect mo= de which is subject to session fixation attacks.


If the GS doesn=E2=80=99t wan= t to accept a redirect without a callback, it can because the request will = have a redirect, but not a callback, and it can reject the request. What ma= kes you believe that this is not detectable or not possible in XYZ?=C2=A0

I did not say it could not= be done, I'm saying it is more difficult in XYZ than in XAuth

Can you explain to me how i= t=E2=80=99s more difficult in XYZ? I have explained how it can be done and = I am failing to see why you think it=E2=80=99s harder.

Having both a handle and a URI seems more com= plicated than just a URI.

If you think that having= a URI in addition to a handle makes sense, how about you put that into you= r draft and see how it works?

For example:=C2=A0

How is a transaction updated?=C2=A0
How a= re separate access tokens refreshed?=C2=A0
Refreshing an access t= oken in XYZ returns a full transaction response per Section 9.3 which refer= s to Section 8.


By using URIs = and methods, XAuth has an easy to understand API for CRUD operations on Gra= nts and Authorizations.

    +--------------+-----------+--------+-------------------=
----------+
    | request      | http verb | uri    | response                    |
    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
    | Create Grant | POST      | GS URI | interaction, wait, or grant |
    +--------------+-----------+--------+-----------------------------+
    | List Grants  | GET       | GS URI | grant list                  |
    +--------------+-----------+--------+-----------------------------+
    | Verify Grant | PATCH     | Grant  | grant                       |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read Grant   | GET       | Grant  | wait, or grant              |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Update Grant | PUT       | Grant  | interaction, wait, or grant |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Delete Grant | DELETE    | Grant  | success                     |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read AuthZ   | GET       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Update AuthZ | PUT       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Delete AuthZ | DELETE    | AZ URI | success                     |
    +--------------+-----------+--------+-----------------------------+
    | GS Options   | OPTIONS   | GS URI | metadata                    |
    +--------------+-----------+--------+-----------------------------+
    | Grant        | OPTIONS   | Grant  | metadata                    |
    | Options      |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | AuthZ        | OPTIONS   | AZ URI | metadata                    |
    | Options      |           |        |                             |
    +--------------+-----------+--------+-----------------------------+
=C2=A0
=

=C2= =A0
<= br>
The modes in XAuth are much more limiting, as the mixing of d= ifferent interaction methods is already something that we need to start fig= uring out. Let=E2=80=99s say, for example, a client can do a redirect, acce= pt a CIBA-style ping, or do a direct app2app communication. There=E2=80=99s= a natural preference the client will have here: if it can talk to another = app directly, it=E2=80=99ll try that first. If that doesn=E2=80=99t work, i= t can get a push notification sent, and if all that fails, it can pop open = a browser. If I have to pic= k just one of those modes when I make the request, then the client needs to= make three different requests to the AS before I get anything that works.= =C2=A0

Have you re= ad the revised draft? As I noted above, I have added negotiation. The Clien= t can state all the modes it wants, the GS can respond with the modes it wi= ll support, and the Client can offer the User any modes returned from the G= S.

Yes, did you rea= d what I wrote? I think we=E2=80=99re talking past each other.
<= /div>

This is not how XAuth is written currently. The Client ca= n list all of the modes it wants to use. The Server will return all the mod= es that fit in its policy for the Grant Request. Why would the Client need = to make different requests?

per


The interaction objec= t contains one or more interaction mode objects per Section 5

Three modes are defined here:


More modes may defined in extensions, or in this= document.


=
=C2=A0

This kind of mixing is important to allow for differe= nt modalities of client. In fact, the return callback could be tied to the = entry of a user code, not just an outbound redirect. How the client gets th= e user to the AS and how the user gets back are separate questions, and we = need flexibility in both.

Yes, we need flexibility. We also need the GS to be able to easily enforce= what can happen.
=C2=A0
XAuth ties them together in the same way that= OAuth 2 does, and this is an unnecessary restriction that does not add sec= urity or simplicity.

6) Claims at Top Level vs Namespaced=C2=A0
=
In XYZ, there is one schema for claims, and they are req= uested as:

=C2=A0 =C2=A0"claims": {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0"subject": true,
=C2=A0 =C2=A0 =C2= =A0 =C2=A0"email": true
=C2=A0 =C2=A0}

Whereas in XAuth, claims are in their own namespace:

=C2=A0 =C2=A0 "claims": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0= "oidc": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id_= token" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = "email" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: { "essential&quo= t; : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;email_verified" : { "essential" : true }
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 "userinfo" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 "name" =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : { "= ;essential" : true },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "picture" =C2=A0 =C2=A0 =C2=A0 =C2=A0: null
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

In this example, the client is requesting OI= DC defined claims, the email to be in an ID Token, and the name and picture= to be as text. While the XYZ schema may be extended, there are already num= erous schemas being used. The XAuth approach is to support existing and new= schemas,=C2=A0rather than pick one and/or create another one, and allows a= Grant Request to contain claims from multiple schemas at the same time.

Again, as I have said many = times, this part of the request (as is the rest of the request) is extensib= le. The goal of the =E2=80=9Cclaims=E2=80=9D object in XYZ was to propose a= simple, common core. Is this the best set? Probably not, but that=E2=80=99= s why nothing is final yet, right?=C2=A0

Yes, XYZ is extensible. It is not namespaced as XAuth is.

It is, though, as I = said above.

Where?=C2=A0<= /div>
=C2=A0

<= div>
=C2=A0=

=
If we wanted to allow for OIDC style claims objects, we have spa= ce to do exactly that, either as a sub-component of the existing claims obj= ect or as a new top-level object in the request. This flexibility is import= ant, as there are other schemas and other query languages that people might= want to support, including things like JWM:


And at Mike Jones=E2=80=99s request, I=E2=80=99ve added notes in the = current draft of XYZ to the places that will be extensible via registry or = some other mechanism =E2=80=94 but the goal was to have everything in there= be extensible by reasonable mechanisms in ways that will allow innovation = to flourish without breaking core and common functionality.=C2=A0

I do not understand why you insist on painting XYZ as a sta= tic, inflexible, and unbending model when it is exactly the opposite. You d= on=E2=80=99t have to externalize every piece of flexibility in order to hav= e it, and I really hope that these myths don=E2=80=99t keep getting repeate= d in the group.

All I am = doing is comparing what is written. I'm not trying to paint XYZ anythin= g.=C2=A0

Except tha= t you are doing that =E2=80=94 when I raise a concern on something in XAuth= you often respond with =E2=80=9Coh but that=E2=80=99s up for debate!=E2=80= =9D while dismissing the same counter-argument with =E2=80=9CI=E2=80=99m co= mparing what=E2=80=99s written=E2=80=9D.=C2=A0

Your comment was that I was "insisting" on = a specific feature (the Grant URI MUST start with the GS URI). I think the = requirement has many advantages, but I don't have a strong conviction a= bout it, and am open to debating it.=C2=A0
=C2=A0

These are input proposals, everything is up= for debate. That=E2=80=99s why we=E2=80=99re debating.

Yes, we are debating the pros and cons of ea= ch proposal.=C2=A0
=C2=A0

=C2=A0


=
7) No Authorization Type

Sim= ilar to (6), XYZ has a single schema for how to request access to a resourc= e. While that schema is extensible, it requires adaption=C2=A0from any syst= em with an existing schema. XAuth has a type for each authorization request= (oauth2, rar), allowing existing schemas and new schemas to be supported.<= /div>

This is a ridiculous clai= m because the RAR format is a back port of the XYZ format to an OAuth 2 arc= hitecture. If you consider that RAR is extensible, then XYZ is extensible b= y your same definitions. In addition, if there are other resource query lan= guages out there beyond these, and we can support them just like we would s= upport additional claims query languages.=C2=A0

Fu= rthermore, as I=E2=80=99ve said before, XAuth doesn=E2=80=99t allow a clean= way to define the use of both OAuth 2 scopes and rich requests. XYZ does t= his by allowing scope-style strings and full JSON objects to be specified a= t the same level in the same data structure, so there=E2=80=99s no confusio= n over how they=E2=80=99re grouped or applied. XAuth makes me choose ahead = of time to use one or the other, effectively at the API level. So I can no = longer easily call for, say, =E2=80=9Clogin information=E2=80=9D (a general= scope) along with =E2=80=9Ctransaction history for a specific bank account= =E2=80=9D (a rich data object) in the same request. Even RAR handles this b= etter than XAuth by simply letting the =E2=80=9Cscope=E2=80=9D parameter al= so be passed along side the authorization_details object, but there are sig= nificant complexity issues with this as there isn=E2=80=99t a clear way to = combine these concepts in the OAuth 2 world. I think we can do so much bett= er here, and XYZ proposes one such consistent way to do that by defining th= e scope-equivalent to be a pass-by-reference version of the rich object tha= t is passed-by-value. If clients have a shortcut (a scope), they can use th= at; if they need the expressiveness of the resources structure, they can do= that.=C2=A0

Once again i= t does not seem that you have read the latest draft. XAuth allows existing = OAuth 2 scopes, OR OAuth 2 scopes with RAR, OR a new type authorization typ= e that works differently.

I don=E2=80=99t think you read what I wrote here. I did read the new= XAuth draft before replying, and my complaint is that it is still an OR.= =C2=A0

It is an OR in tha= t if the client is using the type "oauth_scope", they cannot have= an "authorization_details" attribute, they can only have "s= cope"

If the client is using the type "o= auth_rich", the client MUST include=C2=A0"authorization_details&q= uot;, and MAY include "scope"
=C2=A0
I have u= pdated the the doc to better capture that:






=C2=A0


Summary

<= /div>
While concerns (3-7) can be addressed in XYZ, (1-2)=C2=A0look fun= damental to the XYZ architecture.



I=E2=80= =99m not sure what you intended to bring up about VC=E2=80=99s in your emai= l, because I didn=E2=80=99t see a back-reference to this, but I=E2=80=99m g= lad you did mention it. This is an example of a query, assertion, and proof= ing data model for users that uses a structure and language that is outside= of the OIDC world, but existing parallel to it.=C2=A0

I meant to include [2] as anothe= r claim schema in point (6) above. In XAuth, you will see that "vc&quo= t; is another object in the "claims" Object.
=C2=A0
I believ= e our protocol needs to be flexible enough to allow this kind of thing on i= nput (the client presenting information about who the user is, as well as r= equesting specific information about the user) and output (the AS claiming = information about the user), in addition to the client being given somethin= g that it can then in turn use with another service down the line to presen= t user information. The world is moving away from an IdP-driven identity mo= del, and we need to keep moving with it and enable it here.

We agree on the flexibility. The XAuth p= roposal is to namespace the schemas so that adopting existing schemas, or u= sing a new one is straightforward.

The XYZ proposal is to have a core namespace for common ele= ments and additionally to allow other namespaces to be added in as needed.<= /div>

I don't follow how th= is would work. Perhaps you could provide an example in JSON?

=
/Dick
3D""=E1=90=A7
--0000000000006bcea905a7973297-- From nobody Mon Jun 8 13:02:33 2020 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 A74F83A0F7A for ; Mon, 8 Jun 2020 13:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 wiKw9XY6Zqgf for ; Mon, 8 Jun 2020 13:02:25 -0700 (PDT) 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 22B8A3A0F79 for ; Mon, 8 Jun 2020 13:02:24 -0700 (PDT) Received: from [192.168.1.14] (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 058K2L1a012258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Jun 2020 16:02:22 -0400 From: Justin Richer Message-Id: <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_5769A679-9256-427C-9108-CF575FD3AA0D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 8 Jun 2020 16:02:21 -0400 In-Reply-To: Cc: txauth@ietf.org To: Dick Hardt References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 08 Jun 2020 20:02:32 -0000 --Apple-Mail=_5769A679-9256-427C-9108-CF575FD3AA0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 8, 2020, at 2:58 PM, Dick Hardt wrote: >=20 >=20 >=20 > On Mon, Jun 8, 2020 at 5:29 AM Justin Richer > wrote: > >> =20 >>=20 >>>=20 >>> XYZ vs XAuth >>>=20 >>> The remaining major differences between XYZ and XAuth are areas I = have concerns about. (I will continue to use XYZ and XAuth refer to each = draft). The concerns are: >>>=20 >>> 1) API in JSON vs URI and HTTP Verb >>>=20 >>> In XYZ, all calls are to the same endpoint as an HTTP POST. The AS = must parse the JSON to determine what to do.=20 >>>=20 >>> XAuth has a RESTful interface. A Grant Request starts at the GS URI, = and Grants and Authorizations are returned as URI resources. Creating a = Grant is done with a POST, reading a Grant is done with a GET.=20 >>>=20 >>> With URIs and HTTP verbs, A large scale GS can easily implement = independent services for each functionality as routing of requests can = be done at the HTTP layer based on the URI and HTTP verb. This allows a = separation of concerns, independent deployment, and resiliency. >>=20 >> As I have said many, many times, both on the list and in the = documentation for XYZ, this is an area that is worth discussing within = the working group. It=E2=80=99s been tagged a potential direction in XYZ = from early days, but not something that we=E2=80=99ve pursued because it = hasn=E2=80=99t been needed in the spaces we=E2=80=99ve used it. >>=20 >> So saying this is a fundamental aspect of XYZ and implying that = it=E2=80=99s a non-starter for it to not be built that way is = misdirection. I hope that the conversation here in this group can = continue without you ignoring or dismissing previous statements like = this as we discuss things.=20 >>=20 >> I'm comparing the two drafts we have today, not what the drafts could = be. You have consistently stated that there is just one end point in the = XYZ model, and that handles represent the transaction rather than URIs = -- as you state again below in your response to point 4. >>=20 >> I find it is much easier for people to understand a proposal to write = it up. I could not see how to easily modify XYZ to support the models I = envisioned, which is why I wrote XAuth. >=20 > You and I both agree that things are easier to understand when written = up, and that=E2=80=99s why I have produced significant write-ups of both = the current state and the potential future state of XYZ during its = lifetime, and continue to do so. The ID is only one of these artifacts, = and I find it problematic that you dismiss any and all additional = material. >=20 > An ID is submitted under the IETF IPR regime. While you have written = much about XYZ, what is before the group are the IDs. > =20 >=20 > As both drafts are inputs to a proposed working group, and not final = systems, they should be compared not only for what=E2=80=99s there but = for what direction they could go. To do otherwise is to ignore the = changes that a working group can and will make on its inputs in pursuit = of a general solution. It is not my intent that XYZ, as currently = proposed, be simple accepted as-is. In fact, I hope it=E2=80=99s not, as = the entire point of me trying to start this working group was to bring a = community together to build something new, useful, and powerful. My = contention with your statement, if you read what I said, is not that XYZ = doesn=E2=80=99t do something today, but that in your view it cannot do = something. The entire purpose of this exercise is to compare = possibility. >=20 > The documents are text and obviously can be edited to be anything. = What we are debating are the proposed approaches.=20 Then please stop presenting things in XYZ as if it cannot be changed. = Thanks. > =20 >=20 > So then: let=E2=80=99s unpack that possibility. Checking my notes on = this topic, I see a pretty straightforward way to do this kind of thing. = Note that herein I=E2=80=99ll be using the native terminology of XYZ, = including =E2=80=9Ctransaction=E2=80=9D and =E2=80=9Chandle=E2=80=9D, = for consistency and to avoid confusion. Currently, the spec has the Tx = endpoint return a reference to the ongoing transaction, known as a = handle. This credential has a value and a presentation method, and = it=E2=80=99s returned at the top level of the response: >=20 > "handle": { > "value": "80UPRY5NM33OMUKMKSKU", > "type": "bearer" > } >=20 > It would be very simple for this credential to also include a URI for = it to be used at: >=20 > "handle": { > "value": "80UPRY5NM33OMUKMKSKU", > "type": =E2=80=9Cbearer=E2=80=9D, > =E2=80=9Curi": =E2=80=9Chttps://server.example/tx/foo-123 = " > } >=20 > Or if we wanted to, we could even break it out into a multi part = structure: >=20 > =E2=80=9Ctransaction": { > "handle": { > "value": "80UPRY5NM33OMUKMKSKU", > "type": =E2=80=9Cbearer=E2=80=9D > } > =E2=80=9Curi": =E2=80=9Chttps://server.example/tx/foo-123 = " > } >=20 >=20 > This pattern of supplying both a credential and a URL for the client = to use in a tightly-coupled fashion is one that has been used before and = we know works. It=E2=80=99s the basis of RFC7592 and ODIC=E2=80=99s = Dynamic Registration, for example. What=E2=80=99s important here is that = the client is told exactly where to go. This URL could be the = transaction endpoint itself, it could be a RESTful style API, it could = be a graph API node, it could be a management service on another = cluster. The protocol quite frankly shouldn=E2=80=99t care about this, = and shouldn=E2=80=99t dictate to the AS how to deploy its parts. = Instead, the protocol should concern itself only with the = interconnection of well-defined components. By providing both a handle = and a target URL we allow the AS to decide whether it wants to dispatch = based on URL, handle, or something else that it gets to decide.=20 >=20 > Note that this credential, the handle, still needs to be presented in = the context of the client=E2=80=99s key proofing that was used to start = things off, so it isn=E2=80=99t fully a bearer access token. This makes = it significantly harder for an attacker to do a man-in-the-middle attack = with a fake AS, since they can=E2=80=99t get a client to use the = attacker=E2=80=99s keys or vice versa. But this also means that I = don=E2=80=99t think we can use an access token here, because the client = needs to be able to present its keys in a consistent manner and that = might include its own use of an Authorization header, depending on the = key proofing method. We shouldn=E2=80=99t step on that space. = Additionally, the client is going to be providing additional information = in the follow-up requests anyway, such as a reference from the = front-channel callback, the signed response to a cryptographic = challenge, an identifier for a push endpoint, etc. Since we=E2=80=99re = in the back channel we=E2=80=99re not limited to just stuffing things = into URLs, and these can all be presented as part of the protocol = request.=20 >=20 > Furthermore, this handle should be independent from its use in any = follow-up requests because it should also be able to be used to start a = new transaction in a new context. This kind of step-up authorization is = something that people have long desired in OAuth 2 and have hacked = together in a few different ways in the wild, but we can do it here. = Now of course we could hack around this by providing the grant URL in a = new transaction request, but that unnecessarily conflates the identifier = (the URL) with the access method.=20 >=20 > Additionally, the handle in my implementations of XYZ have all been = random values, but that doesn=E2=80=99t need to be the case at all. For = a distributed system, the AS might want to pack information about the = transaction into an encrypted bundle and pass it to the handle in a more = stateless/serverless fashion. If we force the AS to put that information = into the URL itself, then we=E2=80=99re going to run into many of the = same problems that we do in the front channel of OAuth 2 today and end = up with some of the same workarounds and patches. This is the back = channel, and we should make use of the fact that the client can send = more than just a plain GET to a URL. >=20 > The front channel is problematic as the Client is not communicating = directly to an AS. I don't see how those issues would apply to a Client = doing a GET of a URL. > =20 >=20 > As an aside, this approach of bundling a target with the handle is = something that=E2=80=99s been brought up on this list already, and I = know there=E2=80=99s appetite for addressing it with regard to access = tokens. Namely, there are a few different groups that want to be able to = indicate to the client where it should use an access token. This has = implications for multiple access tokens and resource set descriptions, = among other key aspects of the protocol. This is a difficult and complex = problem that fans out quickly, but thanks to previous indication of = interest from the members of this list, it is within our proposed = charter and I look forward to discussing this issue as the group gets = going. >=20 > Now with that said, there are still some good reasons to define it as = a single endpoint. Namely, the kinds of responses you get from starting = a transaction are the same as those returned from continuing a = transaction in progress. For example, with the functionality split, you = now have two places in your architecture that could return an access = token, depending on if the policies allow for the token to be issued = without user interaction (the client credentials equivalent) or not (the = auth code equivalent). Furthermore, the inputs to the request on both = sides are largely the same =E2=80=94 much of the information that you = might present in a follow-up could be presented in an initial request. = As such, this is not a purely restful process unless you jump through = some additional hoops to force it to be, like making the client do a = =E2=80=9CGET=E2=80=9D on the results of the request in order to get its = access token instead of returning it directly. However, not even XAuth = requires this, for what I hope are obvious reasons. This is the kind of = thing that needs to be balanced against the benefits of splitting the = endpoints, and something the group needs to debate and come to terms = with.=20 >=20 > A GS implementation can decide to only return an authorization from = doing a GET on the AZ URL. Returning only an AZ URL is an option in = XAuth. Similarly, we could do the same for a Grant URI.=20 And that=E2=80=99s a lot of complex code paths for both the GS and = client to deal with. With more ways that it might happen, the client has = to be prepared for any of them =E2=80=94 and get them all right.=20 > =20 >=20 > Using a different URI, optionally, isn=E2=80=99t the problem, and that = could easily be added to the. Removal of the separate handle is the = problem I have with the XAuth approach. >=20 > In XAuth, the Grant URI is the GS URI + TBD + handle >=20 > Given we have asymmetric crypto as a requirement, it is unclear what = having two pieces of random signal provide. Asymmetric crypto is an implementation requirement in both the input = drafts but it isn=E2=80=99t a requirement in the charter, and there are = likely symmetric use cases and key proofing mechanisms that are going to = be desirable for a lot of people. > =20 >=20 >> =20 >>=20 >> Additionally, I find XAuth=E2=80=99s restrictions on the structure of = the Grant URI potentially problematic, namely that it has to start with = the server=E2=80=99s URL. This will lead to deployments needing to bend = their setups with proxies or redirectors to make things fit, which you = yourself have said is going to be an issue for things like supporting a = short redirect URL vs. a long redirect URL. Your complaint there was one = of latency and complexity, why does that not apply here? But most = fundamentally, I do not see what value this restriction brings to the = system. If the value is coming back from the GS endpoint, and the client = is getting all of its pointers from there, what=E2=80=99s the point of = dictating how that has to look? >>=20 >> Requiring the Grant URI to start with the GS URI is open to = discussion. It is not clear to me why a deployment would need to have a = redirector. Large scale deployments I have worked on have a router / = proxy that routes requests to internal services. Having all the URIs = start with the GS URI enables all GNAP operations to be routed in the = same place. >=20 > You still haven=E2=80=99t addressed why you think that this is a = reasonable requirement or assumption here but not when dealing with = long/short URLs for QR codes. What is the difference? >=20 > Short URLs generally use a short host name as well as a short path.=20 >=20 > Most REST interfaces have the pattern I am proposing. A mental model = many developers are familiar with.=20 This is assuming a lot on the part of the GS implementation, still, and = all of my arguments stand.=20 > =20 >=20 >>=20 >> An advantage of starting with the GS URI is that any software on the = Client side knows which GS it belongs to. A Grant URI passed to a Client = in a GS initiated login allows the Client to know if it trusts the GS = before operating on the Grant URI.=20 >=20 > Is the client then required to make this check for security purposes? = Or can we protect against this kind of confusion by building the system = to be resilient to it in a different way? I have opted for the latter in = XYZ=E2=80=99s design.=20 >=20 >>=20 >> If the Grant URI can be any URI, then a Client could be tricked into = operating on a Grant URI it should not be operating on.=20 >=20 > This is not true if the client also needs to present its keys with the = request, is it? Am I missing an attack here? >=20 > An attacker being able to trick a Client to authenticate somewhere it = is not intending to go seems like something worth preventing.=20 >=20 > The GS initiated login is easily supported with the URI representing = the Grant. >=20 > See https://tools.ietf.org/html/draft-hardt-gnap-advanced-00#section-5 = >=20 >=20 > =20 >=20 >> =20 >>=20 >>>=20 >>> 2) Handles for all Clients vs Client ID and Client Handle >>>=20 >>> In XYZ, both pre-registered clients and dynamic clients use a = handle.=20 >>>=20 >>> In XAuth, the Client ID refers to a pre-registered client, and the = Client Handle is specific to an instance of a dynamic client. Using = separate terms clearly differentiates which identifier is being = presented to the GS.=20 >>>=20 >>> This allows a GS to use separate mechanisms for managing = pre-registered clients and dynamic clients, an important consideration = as there can easily be millions of instances of a single dynamic client. >>>=20 >>> Additionally, developers are already familiar with what a Client ID = is for pre-registered clients. >>=20 >> I see the inconsistency in the XAuth draft to be problematic. Under = this proposed model, I now need to be able to track clients using = different kinds of identifiers depending on what kind of registration = they used? Why build in this dichotomy? >>=20 >> A GS implementation is free to use the same identifiers and storage = system for Client IDs and Client Handles.=20 >> =20 >>=20 >> One of the design goals of XYZ was to bring consistency to the = haphazard world of OAuth 2, where a client ID could mean a class of = client software or an individual client or a cluster of servers or any = number of other things.=20 >>=20 >> In XYZ a client handle refers to both registered clients, and dynamic = clients. That seems to continue to be haphazard.=20 >>=20 >> Dynamic Registration needed to use Client ID as the rest of OAuth = only understood that identifier for a client. >>=20 >> XAuth allows each type of client to have their own identifier. >=20 > The key handle represents a set of keying material that is passed by = reference instead of by value. That keying material is something that = the server has seen before. It can be associated with a piece of = software that has either been statically registered, or it could be a = key that showed up dynamically and the server is providing a shortcut to = reference it. >=20 > At the start of the protocol, the server is either looking up the key = from a handle / Client ID if it is a pre-registered client. Correct? >=20 > Once the server has done that, it can associate the key with the = Grant. That is not entirely correct. A pre-registered client can still pass its = key by value, and a dynamic client can still use a = (dynamically-acquired) handle. In all cases, the client is identifying = itself by its key. The difference is how the server looks up that key = =E2=80=94 it=E2=80=99s either from the handle, or it=E2=80=99s from the = key value itself.=20 There=E2=80=99s a parallelism between dynamic, ephemeral, and static = clients in XYZ that I think is very valuable and it=E2=80=99s enabled by = this feature. The ability to use a =E2=80=9Cclient_id=E2=80=9D as a key = handle still makes sense semantically, because it=E2=80=99s a value that = the AS can use to look up the key material. But fundamentally in XYZ, = the client is known by its key not by a separate identifier. You can = have internal identifiers for developer-facing things, of course, but = the protocol does not need them. > =20 >=20 > In both cases, static and dynamic clients can present their keys by = value and get expected behavior. Instead of a fuzzy definition where = =E2=80=9Cclient=E2=80=9D could mean an instance, a class, or a concept, = we=20 >=20 > You did not complete this sentence. >=20 > I'm confused by this=20 >=20 > I would think that the server would require a pre-registered client to = have a private key tied to the public key the server has for the Client. = No? My apologies for missing that sentence. All it was going to say was = =E2=80=9Cwe have a chance to define more clearly what a client is and = each part of the request separate from that=E2=80=9D. > =20 >=20 > This is why I want to get away from a =E2=80=9Cclient identifier=E2=80=9D= because there is not a concrete and consistent definition of what a = =E2=80=9Cclient=E2=80=9D means across the wide variety of use cases we = already know we have. >=20 > I would take a different approach. Let's clarify what a Client is. We = are using the term. Having it be fuzzy and avoiding what a Client is = seems the wrong approach.=20 > =20 >=20 >> =20 >>=20 >> And as I=E2=80=99ve demonstrated with an implementation on top of the = MITREid Connect OAuth 2 server, it=E2=80=99s completely possible and = well within-protocol to pass in a static client ID within the XYZ=E2=80=99= s =E2=80=9Ckey handle=E2=80=9D field and have things work as expected. = Yes, it=E2=80=99s called something different =E2=80=94 but if that=E2=80=99= s a problem, then XAuth=E2=80=99s renaming of the Authorization Server = to a Grant Server is going to be significantly more confusing for = developers, don=E2=80=99t you think? >>=20 >> Nope.=20 >=20 >> =20 >>=20 >>>=20 >>> 3) Transaction Handles are One Time Use >>>=20 >>> In XYZ, transaction handles are one time use [1]. In the OAuth WG = discussion on one time use refresh tokens, clients are often distributed = across components, which complicates one time use references.=20 >>>=20 >>> One time use transaction handles also makes them inconsistent with = the display, resource, user, and key handles. >>=20 >> Transaction handles being one-time-use is based on experience with a = session fixation attack against UMA (now patched): >>=20 >> = https://kantarainitiative.org/confluence/display/uma/Understanding+the+Ses= sion+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+Mitigation = = >>=20 >> Clients with distributed components are going to have to be = considered in our core model, and so there are considerations and = tradeoffs in terms of security and deployability that we need to address = here. These are the same kinds of discussions that we=E2=80=99re having = in OAuth 2, as you point out, and so we can not only apply that = experience and knowledge to this, but we can build something that = behaves better than a refresh token for this purpose. >>=20 >> The XAuth proposal is to use a URI to represent the authorization.=20 >=20 > I know what XAuth does, and it does not help that kind of attack. = Automatic credential rotation on use is a well established mitigation = mechanism that is impossible if the only item you have is a URI that is = given exactly once within the protocol. This is in addition to the = discussion above regarding issuing the credential alongside the URI. >=20 > I don't see how that attack is possible. The Grant URI has a random = element in it that the GS uses to retrieve information about the Grant, = including the Client that created it. > =20 >=20 >> =20 >>=20 >>>=20 >>> 4) New User Identifier >>>=20 >>> XYZ introduces a new identifier for the user, a User Handle. Unclear = why a new type of user identifier is needed, except for the desire to = have a handle for everything. >>>=20 >>=20 >> This is based directly on the Persisted Claims Token concept from = UMA2, where a client (that is trusted to make such a statement) can say = that it reasonably believes that the current user interacting with this = client is the same user that it=E2=80=99s been interacting with before, = for use with a future request. An AS can take this signal into = consideration when processing the request, potentially avoiding = unnecessary interaction and friction. >>=20 >> My statement is that it was unclear why it was needed. Perhaps you = can add a Rationale section to XYZ? >> =20 >>=20 >> I=E2=80=99m not surprised that you see this as =E2=80=9Cjust applying = a handle for everything=E2=80=9D considering you=E2=80=99ve previously = objected to the use of the pass-by-reference construct for other aspects = of the protocol in the past as well. Each component in XYZ that has a = separate handle has one for specific and documented reasons, and it=E2=80=99= s a core feature that these are handled (pun intended) in a consistent = and predictable manner. >>=20 >> This is why I state that it seems hard to change (1) above.=20 >> =20 >>=20 >>> 5) Interaction Capabilities vs Modes >>>=20 >>> In XYZ, the capabilities are expressed by the client, and the GS = states which capabilities it will accept. This can make it difficult for = the GS to enforce the interaction choices as the client can mix and = match which capabilities are returned. For example, a GS may not want to = support a redirect without a callback to protect itself from session = fixation attacks. In XAuth, the interaction modes provide clarity on the = mode of interaction and the security properties. For example the GS may = support both user_code and redirect modes, but not the indirect mode = which is subject to session fixation attacks. >>>=20 >>=20 >> If the GS doesn=E2=80=99t want to accept a redirect without a = callback, it can because the request will have a redirect, but not a = callback, and it can reject the request. What makes you believe that = this is not detectable or not possible in XYZ?=20 >>=20 >> I did not say it could not be done, I'm saying it is more difficult = in XYZ than in XAuth >=20 > Can you explain to me how it=E2=80=99s more difficult in XYZ? I have = explained how it can be done and I am failing to see why you think = it=E2=80=99s harder. >=20 > Having both a handle and a URI seems more complicated than just a URI. You=E2=80=99re conflating things: This is a separate discussion. Here we = are talking about how it=E2=80=99s more difficult for an AS to determine = the presence or absence of the =E2=80=9Ccallback=E2=80=9D field vs. = detecting the presence or absence of the =E2=80=9Cdirect=E2=80=9D and/or = =E2=80=9Cindirect=E2=80=9D fields. >=20 > If you think that having a URI in addition to a handle makes sense, = how about you put that into your draft and see how it works? Because I haven=E2=80=99t had an opportunity to implement it in this way = yet, and I=E2=80=99m not yet convinced the extra complexity is worth it. = I said it MIGHT make sense and it=E2=80=99s worth talking about, which = has been my public stance since before you proposed XAuth. That=E2=80=99s = still the case, and I=E2=80=99ve gone to length here on the list (which = is under the IETF IPR rules) to discuss it. Are you suggesting that I = need to prove this to you in a particular way, instead? As this is an = individual draft, it should represent what I, personally, think is the = best approach. Part of my criteria for adding things to my individual = draft is making sure it at least makes some amount of sense with real = code. Your draft should likewise follow your own convictions. This is of course a very different thing from being a working group = editor, where the editor=E2=80=99s role is to capture, express, and = refine what the desires of the WG are. I know the difference between = these roles well, and they serve different purposes in the process. >=20 > For example:=20 >=20 > How is a transaction updated?=20 > How are separate access tokens refreshed?=20 > Refreshing an access token in XYZ returns a full transaction response = per Section 9.3 which refers to Section 8. >=20 >=20 > By using URIs and methods, XAuth has an easy to understand API for = CRUD operations on Grants and Authorizations. >=20 > = +--------------+-----------+--------+-----------------------------+ > | request | http verb | uri | response = | > = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > | Create Grant | POST | GS URI | interaction, wait, or grant = | > = +--------------+-----------+--------+-----------------------------+ > | List Grants | GET | GS URI | grant list = | > = +--------------+-----------+--------+-----------------------------+ > | Verify Grant | PATCH | Grant | grant = | > | | | URI | = | > = +--------------+-----------+--------+-----------------------------+ > | Read Grant | GET | Grant | wait, or grant = | > | | | URI | = | > = +--------------+-----------+--------+-----------------------------+ > | Update Grant | PUT | Grant | interaction, wait, or grant = | > | | | URI | = | > = +--------------+-----------+--------+-----------------------------+ > | Delete Grant | DELETE | Grant | success = | > | | | URI | = | > = +--------------+-----------+--------+-----------------------------+ > | Read AuthZ | GET | AZ URI | authorization = | > = +--------------+-----------+--------+-----------------------------+ > | Update AuthZ | PUT | AZ URI | authorization = | > = +--------------+-----------+--------+-----------------------------+ > | Delete AuthZ | DELETE | AZ URI | success = | > = +--------------+-----------+--------+-----------------------------+ > | GS Options | OPTIONS | GS URI | metadata = | > = +--------------+-----------+--------+-----------------------------+ > | Grant | OPTIONS | Grant | metadata = | > | Options | | URI | = | > = +--------------+-----------+--------+-----------------------------+ > | AuthZ | OPTIONS | AZ URI | metadata = | > | Options | | | = | > = +--------------+-----------+--------+-----------------------------+ > =20 While this looks good on paper, there are very pragmatic reasons that = many APIs have moved away from purely RESTful patterns over the last = decade, including limitations on what can be sent with GET and DELETE = requests, for example. I don=E2=80=99t think it=E2=80=99s as clean a win = as you=E2=80=99re presenting it, but I think it=E2=80=99s worth checking = out. >=20 >> =20 >>=20 >> The modes in XAuth are much more limiting, as the mixing of different = interaction methods is already something that we need to start figuring = out. Let=E2=80=99s say, for example, a client can do a redirect, accept = a CIBA-style ping, or do a direct app2app communication. There=E2=80=99s = a natural preference the client will have here: if it can talk to = another app directly, it=E2=80=99ll try that first. If that doesn=E2=80=99= t work, it can get a push notification sent, and if all that fails, it = can pop open a browser. If I have to pick just one of those modes when I = make the request, then the client needs to make three different requests = to the AS before I get anything that works.=20 >>=20 >> Have you read the revised draft? As I noted above, I have added = negotiation. The Client can state all the modes it wants, the GS can = respond with the modes it will support, and the Client can offer the = User any modes returned from the GS. >=20 > Yes, did you read what I wrote? I think we=E2=80=99re talking past = each other. >=20 > This is not how XAuth is written currently. The Client can list all of = the modes it wants to use. The Server will return all the modes that fit = in its policy for the Grant Request. Why would the Client need to make = different requests? >=20 > per >=20 > = https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.2 = = =20 >=20 > The interaction object contains one or more interaction mode objects = per Section 5 >=20 > Three modes are defined here: >=20 > https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-5 = >=20 > More modes may defined in extensions, or in this document. Yes, this is an improvement, and I=E2=80=99m glad you=E2=80=99re moving = your thinking in this direction. However, it=E2=80=99s still not as = clear how things combine to solve different use cases, and it conflates = the means of getting the user TO the interaction page with the way of = getting them BACK from it. It=E2=80=99s these flexible combinations that = I think are important, and I don=E2=80=99t think XAuth gets this quite = right yet.=20 >=20 >=20 >> =20 >>=20 >> This kind of mixing is important to allow for different modalities of = client. In fact, the return callback could be tied to the entry of a = user code, not just an outbound redirect. How the client gets the user = to the AS and how the user gets back are separate questions, and we need = flexibility in both. >>=20 >> Yes, we need flexibility. We also need the GS to be able to easily = enforce what can happen. >> =20 >> XAuth ties them together in the same way that OAuth 2 does, and this = is an unnecessary restriction that does not add security or simplicity. >>=20 >>> 6) Claims at Top Level vs Namespaced=20 >>>=20 >>> In XYZ, there is one schema for claims, and they are requested as: >>>=20 >>> "claims": { >>> "subject": true, >>> "email": true >>> } >>>=20 >>> Whereas in XAuth, claims are in their own namespace: >>>=20 >>> "claims": { >>> "oidc": { >>> "id_token" : { >>> "email" : { "essential" : true }, >>> "email_verified" : { "essential" : true } >>> }, >>> "userinfo" : { >>> "name" : { "essential" : true }, >>> "picture" : null >>> } >>> } >>>=20 >>> In this example, the client is requesting OIDC defined claims, the = email to be in an ID Token, and the name and picture to be as text. = While the XYZ schema may be extended, there are already numerous schemas = being used. The XAuth approach is to support existing and new schemas, = rather than pick one and/or create another one, and allows a Grant = Request to contain claims from multiple schemas at the same time. >>=20 >> Again, as I have said many times, this part of the request (as is the = rest of the request) is extensible. The goal of the =E2=80=9Cclaims=E2=80=9D= object in XYZ was to propose a simple, common core. Is this the best = set? Probably not, but that=E2=80=99s why nothing is final yet, right?=20= >>=20 >> Yes, XYZ is extensible. It is not namespaced as XAuth is. >=20 > It is, though, as I said above. >=20 > Where?=20 > =20 >=20 >> =20 >>=20 >> If we wanted to allow for OIDC style claims objects, we have space to = do exactly that, either as a sub-component of the existing claims object = or as a new top-level object in the request. This flexibility is = important, as there are other schemas and other query languages that = people might want to support, including things like JWM: >>=20 >> https://tools.ietf.org/id/draft-looker-jwm-01.html = >>=20 >> And at Mike Jones=E2=80=99s request, I=E2=80=99ve added notes in the = current draft of XYZ to the places that will be extensible via registry = or some other mechanism =E2=80=94 but the goal was to have everything in = there be extensible by reasonable mechanisms in ways that will allow = innovation to flourish without breaking core and common functionality.=20= >>=20 >> I do not understand why you insist on painting XYZ as a static, = inflexible, and unbending model when it is exactly the opposite. You = don=E2=80=99t have to externalize every piece of flexibility in order to = have it, and I really hope that these myths don=E2=80=99t keep getting = repeated in the group. >>=20 >> All I am doing is comparing what is written. I'm not trying to paint = XYZ anything.=20 >=20 > Except that you are doing that =E2=80=94 when I raise a concern on = something in XAuth you often respond with =E2=80=9Coh but that=E2=80=99s = up for debate!=E2=80=9D while dismissing the same counter-argument with = =E2=80=9CI=E2=80=99m comparing what=E2=80=99s written=E2=80=9D.=20 >=20 > Your comment was that I was "insisting" on a specific feature (the = Grant URI MUST start with the GS URI). I think the requirement has many = advantages, but I don't have a strong conviction about it, and am open = to debating it.=20 I open to debating everything in XYZ, including things I have strong = convictions about. This is why I=E2=80=99m bringing it to a standards = body and trying to start a standards process instead of just launching = it as a commercial solution. > =20 >=20 > These are input proposals, everything is up for debate. That=E2=80=99s = why we=E2=80=99re debating. >=20 > Yes, we are debating the pros and cons of each proposal.=20 > =20 >=20 >> =20 >>=20 >>>=20 >>> 7) No Authorization Type >>>=20 >>> Similar to (6), XYZ has a single schema for how to request access to = a resource. While that schema is extensible, it requires adaption from = any system with an existing schema. XAuth has a type for each = authorization request (oauth2, rar), allowing existing schemas and new = schemas to be supported. >>=20 >> This is a ridiculous claim because the RAR format is a back port of = the XYZ format to an OAuth 2 architecture. If you consider that RAR is = extensible, then XYZ is extensible by your same definitions. In = addition, if there are other resource query languages out there beyond = these, and we can support them just like we would support additional = claims query languages.=20 >>=20 >> Furthermore, as I=E2=80=99ve said before, XAuth doesn=E2=80=99t allow = a clean way to define the use of both OAuth 2 scopes and rich requests. = XYZ does this by allowing scope-style strings and full JSON objects to = be specified at the same level in the same data structure, so there=E2=80=99= s no confusion over how they=E2=80=99re grouped or applied. XAuth makes = me choose ahead of time to use one or the other, effectively at the API = level. So I can no longer easily call for, say, =E2=80=9Clogin = information=E2=80=9D (a general scope) along with =E2=80=9Ctransaction = history for a specific bank account=E2=80=9D (a rich data object) in the = same request. Even RAR handles this better than XAuth by simply letting = the =E2=80=9Cscope=E2=80=9D parameter also be passed along side the = authorization_details object, but there are significant complexity = issues with this as there isn=E2=80=99t a clear way to combine these = concepts in the OAuth 2 world. I think we can do so much better here, = and XYZ proposes one such consistent way to do that by defining the = scope-equivalent to be a pass-by-reference version of the rich object = that is passed-by-value. If clients have a shortcut (a scope), they can = use that; if they need the expressiveness of the resources structure, = they can do that.=20 >>=20 >> Once again it does not seem that you have read the latest draft. = XAuth allows existing OAuth 2 scopes, OR OAuth 2 scopes with RAR, OR a = new type authorization type that works differently. >=20 > I don=E2=80=99t think you read what I wrote here. I did read the new = XAuth draft before replying, and my complaint is that it is still an OR.=20= >=20 > It is an OR in that if the client is using the type "oauth_scope", = they cannot have an "authorization_details" attribute, they can only = have "scope" >=20 > If the client is using the type "oauth_rich", the client MUST include = "authorization_details", and MAY include "scope" > =20 > I have updated the the doc to better capture that: >=20 > = https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.4 = >=20 > and example 2 now is of type "oauth_rich" >=20 > https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.2 = >=20 It was not clear to me that both could be sent with that mode, so thank = you for updating that. But the client still has to choose one or the = other up front. Why not have a mechanism that it can send both at all = times? Why have a =E2=80=9Cmode=E2=80=9D type switch at all? XYZ allows = clients to make these combined requests with a single consistent syntax. And by completely externalizing this to OAuth 2, I would argue that we = lose an opportunity to more clearly define how resources are described = and used, and we inherit the same combination issues that are facing RAR = today. We can do better because we get to define the context. >=20 >>=20 >> =20 >>=20 >>>=20 >>> Summary >>>=20 >>> While concerns (3-7) can be addressed in XYZ, (1-2) look fundamental = to the XYZ architecture. >>>=20 >>> [1] = https://tools.ietf.org/html/draft-richer-transactional-authz-08#section-7 = >>>=20 >>> [2] https://w3c.github.io/vc-data-model/ = >> I=E2=80=99m not sure what you intended to bring up about VC=E2=80=99s = in your email, because I didn=E2=80=99t see a back-reference to this, = but I=E2=80=99m glad you did mention it. This is an example of a query, = assertion, and proofing data model for users that uses a structure and = language that is outside of the OIDC world, but existing parallel to it.=20= >>=20 >> I meant to include [2] as another claim schema in point (6) above. In = XAuth, you will see that "vc" is another object in the "claims" Object. >> =20 >> I believe our protocol needs to be flexible enough to allow this kind = of thing on input (the client presenting information about who the user = is, as well as requesting specific information about the user) and = output (the AS claiming information about the user), in addition to the = client being given something that it can then in turn use with another = service down the line to present user information. The world is moving = away from an IdP-driven identity model, and we need to keep moving with = it and enable it here. >>=20 >> We agree on the flexibility. The XAuth proposal is to namespace the = schemas so that adopting existing schemas, or using a new one is = straightforward. >=20 > The XYZ proposal is to have a core namespace for common elements and = additionally to allow other namespaces to be added in as needed. >=20 > I don't follow how this would work. Perhaps you could provide an = example in JSON? One method is defining a new value inside the XYZ =E2=80=9Cclaims=E2=80=9D= request object that maps to a specific sub-schema: claims: { =E2=80=9Csubject=E2=80=9D: true, =E2=80=9Cemail=E2=80=9D: true, =E2=80=9Coidc=E2=80=9D: { "userinfo": { "given_name": {"essential": true}, "nickname": null, "email": {"essential": true}, "email_verified": {"essential": true}, "picture": null, "http://example.info/claims/groups": null }, "id_token": { "auth_time": {"essential": true}, "acr": {"values": ["urn:mace:incommon:iap:silver"] } } } } That should look pretty familiar. Alternatively, this could be done with = a separate top-level request object field: claims: { =E2=80=9Csubject=E2=80=9D: true, =E2=80=9Cemail=E2=80=9D: true }, =E2=80=9Coidc_claims_request=E2=80=9D: { "userinfo": { "given_name": {"essential": true}, "nickname": null, "email": {"essential": true}, "email_verified": {"essential": true}, "picture": null, "http://example.info/claims/groups": null }, "id_token": { "auth_time": {"essential": true}, "acr": {"values": ["urn:mace:incommon:iap:silver"] } } } In both cases the AS is going to need to knit them together into a = sensible request policy, especially since the OIDC claims query language = has overlapping implications to one particular resource, the UserInfo = endpoint. My contention wasn=E2=80=99t with your proposed solution, my = contention was you claiming that XYZ has a fixed schema and is therefore = limited in extensibility. =E2=80=94 Justin= --Apple-Mail=_5769A679-9256-427C-9108-CF575FD3AA0D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 8, 2020, at 2:58 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Mon, Jun 8, 2020 at 5:29 AM Justin = Richer <jricher@mit.edu> wrote:
<snip>
 

XYZ vs = XAuth

The = remaining major differences between XYZ and XAuth are areas I have = concerns about. (I will continue to use XYZ and XAuth refer to each = draft). The concerns are:

1) API in JSON vs URI and HTTP = Verb

In XYZ, all calls are to the same endpoint as an HTTP = POST. The AS must parse the JSON to determine what to = do. 

XAuth = has a RESTful interface. A Grant Request starts at the GS URI, and = Grants and Authorizations are returned as URI resources. Creating a = Grant is done with a POST, reading a Grant is done with a GET. 

With URIs and HTTP = verbs, A large scale GS can easily implement independent services = for each  functionality as routing of requests can be done at = the HTTP layer based on the URI and HTTP verb. This allows a separation = of concerns, independent deployment, and = resiliency.

As I have said many, many times, both = on the list and in the documentation for XYZ, this is an area that is = worth discussing within the working group. It=E2=80=99s been tagged a = potential direction in XYZ from early days, but not something that = we=E2=80=99ve pursued because it hasn=E2=80=99t been needed in the = spaces we=E2=80=99ve used it.

So saying this is a fundamental aspect = of XYZ and implying that it=E2=80=99s a non-starter for it to not be = built that way is misdirection. I hope that the conversation here in = this group can continue without you ignoring or dismissing previous = statements like this as we discuss = things. 

I'm comparing the two drafts = we have today, not what the drafts could be. You have = consistently stated that there is just one end point in the XYZ model, = and that handles represent the transaction rather than URIs -- as you state again below in = your response to point 4.

I find it is much easier for people to understand a proposal = to write it up. I could not see how to easily modify XYZ to support the = models I envisioned, which is why I wrote = XAuth.

You and I both agree that things are = easier to understand when written up, and that=E2=80=99s why I have = produced significant write-ups of both the current state and the = potential future state of XYZ during its lifetime, and continue to do = so. The ID is only one of these artifacts, and I find it problematic = that you dismiss any and all additional = material.

An ID is submitted under the IETF IPR = regime. While you have written much about XYZ, what is before the group = are the IDs.
 

As both drafts are inputs to a proposed = working group, and not final systems, they should be compared not only = for what=E2=80=99s there but for what direction they could go. To do = otherwise is to ignore the changes that a working group can and will = make on its inputs in pursuit of a general solution. It is not my intent = that XYZ, as currently proposed, be simple accepted as-is. In fact, I = hope it=E2=80=99s not, as the entire point of me trying to start this = working group was to bring a community together to build something new, = useful, and powerful. My contention with your statement, if you read = what I said, is not that XYZ doesn=E2=80=99t do something today, but = that in your view it cannot do something. The entire purpose of this = exercise is to compare possibility.

The documents are text = and obviously can be edited to be anything. What we are debating are the = proposed approaches. 

Then please stop presenting things in XYZ as if it = cannot be changed. Thanks.

 

So then: let=E2=80=99s unpack that = possibility. Checking my notes on this topic, I see a pretty = straightforward way to do this kind of thing. Note that herein I=E2=80=99l= l be using the native terminology of XYZ, including =E2=80=9Ctransaction=E2= =80=9D and =E2=80=9Chandle=E2=80=9D, for consistency and to avoid = confusion. Currently, the spec has the Tx endpoint return a reference to = the ongoing transaction, known as a handle. This credential has a value = and a presentation method, and it=E2=80=99s returned at the top level of = the response:

    "handle": {
= "value": "80UPRY5NM33OMUKMKSKU",
= "type": "bearer"
    = }

It = would be very simple for this credential to also include a URI for it to = be used at:

    "handle": {
    =     "value": "80UPRY5NM33OMUKMKSKU",
  =       "type": =E2=80=9Cbearer=E2=80=9D,
        =E2=80=9Curi": =E2=80=9Chttps://server.example/tx/foo-123"
    }

Or if we wanted to, we could even break it out into a multi = part structure:

    =E2=80=9Ctransaction": {
        "handle": {
            =  "value": "80UPRY5NM33OMUKMKSKU",
    =          "type": =E2=80=9Cbearer=E2=80=9D
        }
        =E2=80=9Curi": =E2=80=9Chttps://server.example/tx/foo-123"
    }


This pattern of supplying both a credential and a URL for the = client to use in a tightly-coupled fashion is one that has been used = before and we know works. It=E2=80=99s the basis of RFC7592 and ODIC=E2=80= =99s Dynamic Registration, for example. What=E2=80=99s important here is = that the client is told exactly where to go. This URL could be the = transaction endpoint itself, it could be a RESTful style API, it could = be a graph API node, it could be a management service on another = cluster. The protocol quite frankly shouldn=E2=80=99t care about this, = and shouldn=E2=80=99t dictate to the AS how to deploy its parts. = Instead, the protocol should concern itself only with the = interconnection of well-defined components. By providing both a handle = and a target URL we allow the AS to decide whether it wants to dispatch = based on URL, handle, or something else that it gets to = decide. 

Note that this credential, the handle, still needs to be = presented in the context of the client=E2=80=99s key proofing that was = used to start things off, so it isn=E2=80=99t fully a bearer access = token. This makes it significantly harder for an attacker to do a = man-in-the-middle attack with a fake AS, since they can=E2=80=99t get a = client to use the attacker=E2=80=99s keys or vice versa. But this also = means that I don=E2=80=99t think we can use an access token here, = because the client needs to be able to present its keys in a consistent = manner and that might include its own use of an Authorization header, = depending on the key proofing method. We shouldn=E2=80=99t step on that = space. Additionally, the client is going to be providing additional = information in the follow-up requests anyway, such as a reference from = the front-channel callback, the signed response to a cryptographic = challenge, an identifier for a push endpoint, etc. Since we=E2=80=99re = in the back channel we=E2=80=99re not limited to just stuffing things = into URLs, and these can all be presented as part of the protocol = request. 

Furthermore, this handle should be independent from its use = in any follow-up requests because it should also be able to be used to = start a new transaction in a new context. This kind of step-up = authorization is something that people have long desired in OAuth 2 and = have hacked together in a  few different ways in the wild, but we = can do it here. Now of course we could hack around this by providing the = grant URL in a new transaction request, but that unnecessarily conflates = the identifier (the URL) with the access method. 

Additionally, the handle = in my implementations of XYZ have all been random values, but that = doesn=E2=80=99t need to be the case at all. For a distributed system, = the AS might want to pack information about the transaction into an = encrypted bundle and pass it to the handle in a more = stateless/serverless fashion. If we force the AS to put that information = into the URL itself, then we=E2=80=99re going to run into many of the = same problems that we do in the front channel of OAuth 2 today and end = up with some of the same workarounds and patches. This is the back = channel, and we should make use of the fact that the client can send = more than just a plain GET to a URL.

The front channel is = problematic as the Client is not communicating directly to an AS. I = don't see how those issues would apply to a Client doing a GET of a = URL.
 

As an aside, this approach of bundling = a target with the handle is something that=E2=80=99s been brought up on = this list already, and I know there=E2=80=99s appetite for addressing it = with regard to access tokens. Namely, there are a few different groups = that want to be able to indicate to the client where it should use an = access token. This has implications for multiple access tokens and = resource set descriptions, among other key aspects of the protocol. This = is a difficult and complex problem that fans out quickly, but thanks to = previous indication of interest from the members of this list, it is = within our proposed charter and I look forward to discussing this issue = as the group gets going.

Now with that said, there are still some good reasons to = define it as a single endpoint. Namely, the kinds of responses you get = from starting a transaction are the same as those returned from = continuing a transaction in progress. For example, with the = functionality split, you now have two places in your architecture that = could return an access token, depending on if the policies allow for the = token to be issued without user interaction (the client credentials = equivalent) or not (the auth code equivalent). Furthermore, the inputs = to the request on both sides are largely the same =E2=80=94 much of the = information that you might present in a follow-up could be presented in = an initial request. As such, this is not a purely restful process unless = you jump through some additional hoops to force it to be, like making = the client do a =E2=80=9CGET=E2=80=9D on the results of the request in = order to get its access token instead of returning it directly. However, = not even XAuth requires this, for what I hope are obvious reasons. This = is the kind of thing that needs to be balanced against the benefits of = splitting the endpoints, and something the group needs to debate and = come to terms with. 

A GS implementation can = decide to only return an authorization from doing a GET on the AZ URL. = Returning only an AZ URL is an option in XAuth. Similarly, we could do = the same for a Grant = URI. 

And that=E2=80=99s a lot of complex code paths for = both the GS and client to deal with. With more ways that it might = happen, the client has to be prepared for any of them =E2=80=94 and get = them all right. 

 

Using a different URI, optionally, = isn=E2=80=99t the problem, and that could easily be added to the. = Removal of the separate handle is the problem I have with the XAuth = approach.

In XAuth, the Grant URI is the GS = URI + TBD + handle

Given we have asymmetric crypto as = a requirement, it is unclear what having two pieces of random = signal provide.

Asymmetric crypto is an implementation requirement = in both the input drafts but it isn=E2=80=99t a requirement in the = charter, and there are likely symmetric use cases and key proofing = mechanisms that are going to be desirable for a lot of people.

 

 

Additionally, I find = XAuth=E2=80=99s restrictions on the structure of the Grant URI = potentially problematic, namely that it has to start with the server=E2=80= =99s URL. This will lead to deployments needing to bend their setups = with proxies or redirectors to make things fit, which you yourself have = said is going to be an issue for things like supporting a short redirect = URL vs. a long redirect URL. Your complaint there was one of latency and = complexity, why does that not apply here? But most fundamentally, I do = not see what value this restriction brings to the system. If the value = is coming back from the GS endpoint, and the client is getting all of = its pointers from there, what=E2=80=99s the point of dictating how that = has to look?

Requiring the Grant URI to start with = the GS URI is open to discussion. It is not clear to me why a deployment = would need to have a redirector. Large scale deployments I have worked = on have a router / proxy that routes requests to internal services. = Having all the URIs start with the GS URI enables all GNAP operations to = be routed in the same place.

You still haven=E2=80=99t = addressed why you think that this is a reasonable requirement or = assumption here but not when dealing with long/short URLs for QR codes. = What is the difference?

Short URLs generally use a short host = name as well as a short path. 

Most REST interfaces have the pattern I = am proposing. A mental model many developers are familiar = with. 

This is assuming a lot on the part of the GS = implementation, still, and all of my arguments stand. 

 


An advantage of starting = with the GS URI is that any software on the Client side knows which GS = it belongs to. A Grant URI passed to a Client in a GS = initiated login allows the Client to know if it trusts the GS = before operating on the Grant = URI. 

Is the client then required to make = this check for security purposes? Or can we protect against this kind of = confusion by building the system to be resilient to it in a different = way? I have opted for the latter in XYZ=E2=80=99s = design. 


If the Grant URI can be = any URI, then a Client could be tricked into operating on a Grant URI it = should not be operating = on. 

This is not true if the client also = needs to present its keys with the request, is it? Am I missing an = attack here?

An attacker being able to trick a = Client to authenticate somewhere it is not intending to go seems like = something worth preventing. 

The GS initiated login is easily = supported with the URI representing the Grant.

See https://tools.ietf.org/html/draft-hardt-gnap-advanced-00#sectio= n-5


 

 


2) = Handles for all Clients vs Client ID and Client Handle

In = XYZ, both pre-registered clients and dynamic clients use a = handle. 

In= XAuth, the Client ID refers to a pre-registered client, and the Client = Handle is specific to an instance of a dynamic client. Using separate = terms clearly differentiates which identifier is being presented to the = GS. 

This = allows a GS to use separate mechanisms for managing pre-registered = clients and dynamic clients, an important consideration as there can = easily be millions of instances of a single dynamic client.

Additionally, developers are already familiar with what = a Client ID is for pre-registered = clients.

I see the inconsistency in the XAuth = draft to be problematic. Under this proposed model, I now need to be = able to track clients using different kinds of identifiers depending on = what kind of registration they used? Why build in this = dichotomy?

A GS implementation is free to use the = same identifiers and storage system for Client IDs and Client = Handles. 
 

One of = the design goals of XYZ was to bring consistency to the haphazard world = of OAuth 2, where a client ID could mean a class of client software or = an individual client or a cluster of servers or any number of other = things. 

In XYZ a client handle refers to both = registered clients, and dynamic clients. That seems to continue to be = haphazard. 

Dynamic Registration needed to use Client ID as the rest of = OAuth only understood that identifier for a client.

XAuth allows each type = of client to have their own = identifier.

The key handle represents a set of = keying material that is passed by reference instead of by value. That = keying material is something that the server has seen before. It can be = associated with a piece of software that has either been statically = registered, or it could be a key that showed up dynamically and the = server is providing a shortcut to reference = it.

At the start of the protocol, the = server is either looking up the key from a handle / Client ID if it is a = pre-registered client. Correct?

Once the server has done that, it can = associate the key with the = Grant.

That is not entirely correct. A pre-registered = client can still pass its key by value, and a dynamic client can still = use a (dynamically-acquired) handle. In all cases, the client is = identifying itself by its key. The difference is how the server looks up = that key =E2=80=94 it=E2=80=99s either from the handle, or it=E2=80=99s = from the key value itself. 

There=E2=80=99s a parallelism between dynamic, = ephemeral, and static clients in XYZ that I think is very valuable and = it=E2=80=99s enabled by this feature. The ability to use a = =E2=80=9Cclient_id=E2=80=9D as a key handle still makes sense = semantically, because it=E2=80=99s a value that the AS can use to look = up the key material. But fundamentally in XYZ, the client is known by = its key not by a separate identifier. You can have internal identifiers = for developer-facing things, of course, but the protocol does not need = them.

 

In both cases, = static and dynamic clients can present their keys by value and = get expected behavior. Instead of a fuzzy definition where =E2=80=9Cclient= =E2=80=9D could mean an instance, a class, or a concept, = we 

You did not complete this = sentence.

I'm = confused by this 

I would think that the server would = require a pre-registered client to have a private key tied to the = public key the server has for the Client. = No?

My apologies for missing that sentence. All it = was going to say was =E2=80=9Cwe have a chance to define more clearly = what a client is and each part of the request separate from = that=E2=80=9D.

 

This is why I want to get away from a = =E2=80=9Cclient identifier=E2=80=9D because there is not a concrete and = consistent definition of what a =E2=80=9Cclient=E2=80=9D means across = the wide variety of use cases we already know we = have.

I would take a different approach. = Let's clarify what a Client is. We are using the term. Having it be = fuzzy and avoiding what a Client is seems the wrong = approach. 
 

 

And as I=E2=80=99ve = demonstrated with an implementation on top of the MITREid Connect OAuth = 2 server, it=E2=80=99s completely possible and well within-protocol to = pass in a static client ID within the XYZ=E2=80=99s =E2=80=9Ckey = handle=E2=80=9D field and have things work as expected. Yes, it=E2=80=99s = called something different =E2=80=94 but if that=E2=80=99s a problem, = then XAuth=E2=80=99s renaming of the Authorization Server to a Grant = Server is going to be significantly more confusing for developers, = don=E2=80=99t you think?
Nope. 

 


3) Transaction Handles are = One Time Use

In XYZ, transaction handles are one = time use [1]. In the OAuth WG discussion on one time use refresh tokens, = clients are often distributed across components, which complicates one = time use references. 

One time use transaction handles also makes them inconsistent = with the display, resource, user, and key = handles.

Transaction handles being one-time-use = is based on experience with a session fixation attack against = UMA (now patched):

https://kantarainitiative.org/confluence/display/uma/Understand= ing+the+Session+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+M= itigation

Clients with distributed components are going to have to be = considered in our core model, and so there are considerations and = tradeoffs in terms of security and deployability that we need to address = here. These are the same kinds of discussions that we=E2=80=99re having = in OAuth 2, as you point out, and so we can not only apply that = experience and knowledge to this, but we can build something that = behaves better than a refresh token for this = purpose.

The XAuth proposal is to use a URI to = represent the = authorization. 

I know what XAuth does, = and it does not help that kind of attack. Automatic credential rotation = on use is a well established mitigation mechanism that is impossible if = the only item you have is a URI that is given exactly once within the = protocol. This is in addition to the discussion above regarding issuing = the credential alongside the URI.

I don't see how that = attack is possible. The Grant URI has a random element in it that the GS = uses to retrieve information about the Grant, including the Client that = created it.
 

 


4) New User = Identifier

XYZ introduces a new identifier for the user, a User = Handle. Unclear why a new = type of user identifier is needed, except for the desire to have a = handle for everything.


This is based directly on the Persisted = Claims Token concept from UMA2, where a client (that is trusted to make = such a statement) can say that it reasonably believes that the current = user interacting with this client is the same user that it=E2=80=99s = been interacting with before, for use with a future request. An AS can = take this signal into consideration when processing the request, = potentially avoiding unnecessary interaction and = friction.

My statement is that it was unclear why it was needed. = Perhaps you can add a Rationale section to XYZ?
 

I=E2=80=99m not = surprised that you see this as =E2=80=9Cjust applying a handle for = everything=E2=80=9D considering you=E2=80=99ve previously objected to = the use of the pass-by-reference construct for other aspects of the = protocol in the past as well. Each component in XYZ that has a separate = handle has one for specific and documented reasons, and it=E2=80=99s = a core feature that = these are handled (pun intended) in a consistent and predictable = manner.

This is why I state that it seems hard to change (1) = above. 
 

5) Interaction Capabilities vs = Modes

In XYZ, the capabilities are = expressed by the client, and the GS states which capabilities it will = accept. This can make it difficult for the GS to enforce the interaction = choices as the client can mix and match which capabilities are returned. = For example, a GS may not want to support a redirect without a callback = to protect itself from session fixation attacks. In XAuth, the = interaction modes provide clarity on the mode of interaction and the = security properties. For example the GS may support both user_code and = redirect modes, but not the indirect mode which is subject to session = fixation attacks.


If the GS doesn=E2=80=99t want to = accept a redirect without a callback, it can because the request will = have a redirect, but not a callback, and it can reject the request. What = makes you believe that this is not detectable or not possible in = XYZ? 

I did not say it could not be done, I'm = saying it is more difficult in XYZ than in = XAuth

Can you explain to me how it=E2=80=99s = more difficult in XYZ? I have explained how it can be done and I am = failing to see why you think it=E2=80=99s = harder.

Having both a handle and a URI seems = more complicated than just a = URI.

You=E2=80=99re conflating things: This is a = separate discussion. Here we are talking about how it=E2=80=99s more = difficult for an AS to determine the presence or absence of the = =E2=80=9Ccallback=E2=80=9D field vs. detecting the presence or absence = of the =E2=80=9Cdirect=E2=80=9D and/or =E2=80=9Cindirect=E2=80=9D = fields.


If you think that having = a URI in addition to a handle makes sense, how about you put that into = your draft and see how it = works?

Because I haven=E2=80=99t had an opportunity to = implement it in this way yet, and I=E2=80=99m not yet convinced the = extra complexity is worth it. I said it MIGHT make sense and it=E2=80=99s = worth talking about, which has been my public stance since before you = proposed XAuth. That=E2=80=99s still the case, and I=E2=80=99ve gone to = length here on the list (which is under the IETF IPR rules) to discuss = it. Are you suggesting that I need to prove this to you in a particular = way, instead? As this is an individual draft, it should represent what = I, personally, think is the best approach. Part of my criteria for = adding things to my individual draft is making sure it at least makes = some amount of sense with real code. Your draft should likewise follow = your own convictions.

This is of = course a very different thing from being a working group editor, where = the editor=E2=80=99s role is to capture, express, and refine what the = desires of the WG are. I know the difference between these roles well, = and they serve different purposes in the process.


For example: 

How is a transaction = updated? 
How are separate access tokens = refreshed? 
Refreshing an access token in XYZ = returns a full transaction response per Section 9.3 which refers to = Section 8.


By using URIs and = methods, XAuth has an easy to understand API for CRUD operations on = Grants and Authorizations.

    =
+--------------+-----------+--------+-----------------------------+
    | request      | http verb | uri    | response                    |
    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
    | Create Grant | POST      | GS URI | interaction, wait, or grant |
    +--------------+-----------+--------+-----------------------------+
    | List Grants  | GET       | GS URI | grant list                  |
    +--------------+-----------+--------+-----------------------------+
    | Verify Grant | PATCH     | Grant  | grant                       |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read Grant   | GET       | Grant  | wait, or grant              |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Update Grant | PUT       | Grant  | interaction, wait, or grant |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Delete Grant | DELETE    | Grant  | success                     |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read AuthZ   | GET       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Update AuthZ | PUT       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Delete AuthZ | DELETE    | AZ URI | success                     |
    +--------------+-----------+--------+-----------------------------+
    | GS Options   | OPTIONS   | GS URI | metadata                    |
    +--------------+-----------+--------+-----------------------------+
    | Grant        | OPTIONS   | Grant  | metadata                    |
    | Options      |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | AuthZ        | OPTIONS   | AZ URI | metadata                    |
    | Options      |           |        |                             |
    =
+--------------+-----------+--------+-----------------------------+
<= /div>
 

While this looks good on paper, there are very = pragmatic reasons that many APIs have moved away from purely RESTful = patterns over the last decade, including limitations on what can be sent = with GET and DELETE requests, for example. I don=E2=80=99t think it=E2=80=99= s as clean a win as you=E2=80=99re presenting it, but I think it=E2=80=99s= worth checking out.


 

The modes in XAuth are = much more limiting, as the mixing of different interaction methods is = already something that we need to start figuring out. Let=E2=80=99s say, = for example, a client can do a redirect, accept a CIBA-style ping, or do = a direct app2app communication. There=E2=80=99s a natural preference the = client will have here: if it can talk to another app directly, it=E2=80=99= ll try that first. If that doesn=E2=80=99t work, it can get a push = notification sent, and if all that fails, it can pop open a browser. = If I have to = pick just one of those modes when I make the request, then the client = needs to make three different requests to the AS before I get anything = that works. 
Have you read the revised draft? As I = noted above, I have added negotiation. The Client can state all the = modes it wants, the GS can respond with the modes it will support, and = the Client can offer the User any modes returned from the = GS.

Yes, did you read what I wrote? I think = we=E2=80=99re talking past each = other.

This is not = how XAuth is written currently. The Client can list all of the modes it = wants to use. The Server will return all the modes that fit in its = policy for the Grant Request. Why would the Client need to make = different requests?

per

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-3.4.2  

The interaction object contains one or more interaction mode = objects per Section 5

Three modes are defined here:

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-5

More modes may defined in extensions, or in this = document.

Yes, this is an improvement, and I=E2=80=99m glad = you=E2=80=99re moving your thinking in this direction. However, it=E2=80=99= s still not as clear how things combine to solve different use cases, = and it conflates the means of getting the user TO the interaction page = with the way of getting them BACK from it. It=E2=80=99s these flexible = combinations that I think are important, and I don=E2=80=99t think XAuth = gets this quite right yet. 



 

This kind of mixing is = important to allow for different modalities of client. In fact, the = return callback could be tied to the entry of a user code, not just an = outbound redirect. How the client gets the user to the AS and how the = user gets back are separate questions, and we need flexibility in = both.

Yes, we need flexibility. We also need = the GS to be able to easily enforce what can happen.
 
XAuth ties them together in the same way that OAuth 2 does, = and this is an unnecessary restriction that does not add security or = simplicity.

6) = Claims at Top Level vs Namespaced 

In = XYZ, there is one schema for claims, and they are requested = as:

  =  "claims": {
       "subject": = true,
       "email": true
   }

Whereas in XAuth, claims are in their = own namespace:

    "claims": {
      =   "oidc": {
            = "id_token" : {
            =     "email"          : { "essential" = : true },
              =   "email_verified" : { "essential" : true }
  =           },
      =       "userinfo" : {
      =           "name"         =   : { "essential" : true },
      =           "picture"       =  : null
            = }
        }

In = this example, the client is requesting OIDC defined claims, the email to = be in an ID Token, and the name and picture to be as text. While the XYZ = schema may be extended, there are already numerous schemas being used. = The XAuth approach is to support existing and new schemas, rather = than pick one and/or create another one, and allows a Grant Request to = contain claims from multiple schemas at the same = time.

Again, as I have said many times, this = part of the request (as is the rest of the request) is extensible. The = goal of the =E2=80=9Cclaims=E2=80=9D object in XYZ was to propose a = simple, common core. Is this the best set? Probably not, but that=E2=80=99= s why nothing is final yet, = right? 

Yes, XYZ is extensible. It is not = namespaced as XAuth is.

It is, though, as I said = above.

Where? 
 

 

If we wanted to allow = for OIDC style claims objects, we have space to do exactly that, either = as a sub-component of the existing claims object or as a new top-level = object in the request. This flexibility is important, as there are other = schemas and other query languages that people might want to support, = including things like JWM:

https://tools.ietf.org/id/draft-looker-jwm-01.html

And at Mike Jones=E2=80=99= s request, I=E2=80=99ve added notes in the current draft of XYZ to the = places that will be extensible via registry or some other mechanism =E2=80= =94 but the goal was to have everything in there be extensible by = reasonable mechanisms in ways that will allow innovation to flourish = without breaking core and common functionality. 

I do not understand why = you insist on painting XYZ as a static, inflexible, and unbending model = when it is exactly the opposite. You don=E2=80=99t have to externalize = every piece of flexibility in order to have it, and I really hope that = these myths don=E2=80=99t keep getting repeated in the = group.

All I am doing is comparing what is = written. I'm not trying to paint XYZ = anything. 

Except that you are doing that =E2=80=94 = when I raise a concern on something in XAuth you often respond with = =E2=80=9Coh but that=E2=80=99s up for debate!=E2=80=9D while dismissing = the same counter-argument with =E2=80=9CI=E2=80=99m comparing what=E2=80=99= s written=E2=80=9D. 

Your comment was that I = was "insisting" on a specific feature (the Grant URI MUST start with the = GS URI). I think the requirement has many advantages, but I don't have a = strong conviction about it, and am open to debating = it. 

I open to debating everything in XYZ, including = things I have strong convictions about. This is why I=E2=80=99m bringing = it to a standards body and trying to start a standards process instead = of just launching it as a commercial solution.

 

These are input proposals, everything = is up for debate. That=E2=80=99s why we=E2=80=99re = debating.

Yes, we are debating the pros and cons = of each proposal. 
 

 


7) No Authorization Type

Similar to (6), XYZ has a single schema for how to request = access to a resource. While that schema is extensible, it requires = adaption from any system with an existing schema. XAuth has a type = for each authorization request (oauth2, rar), allowing existing schemas = and new schemas to be supported.

This is a ridiculous = claim because the RAR format is a back port of the XYZ format to an = OAuth 2 architecture. If you consider that RAR is extensible, then XYZ = is extensible by your same definitions. In addition, if there are other = resource query languages out there beyond these, and we can support them = just like we would support additional claims query = languages. 

Furthermore, as I=E2=80=99ve said before, XAuth doesn=E2=80=99t= allow a clean way to define the use of both OAuth 2 scopes and rich = requests. XYZ does this by allowing scope-style strings and full JSON = objects to be specified at the same level in the same data structure, so = there=E2=80=99s no confusion over how they=E2=80=99re grouped or = applied. XAuth makes me choose ahead of time to use one or the other, = effectively at the API level. So I can no longer easily call for, say, = =E2=80=9Clogin information=E2=80=9D (a general scope) along with = =E2=80=9Ctransaction history for a specific bank account=E2=80=9D (a = rich data object) in the same request. Even RAR handles this better than = XAuth by simply letting the =E2=80=9Cscope=E2=80=9D parameter also be = passed along side the authorization_details object, but there are = significant complexity issues with this as there isn=E2=80=99t a clear = way to combine these concepts in the OAuth 2 world. I think we can do so = much better here, and XYZ proposes one such consistent way to do that by = defining the scope-equivalent to be a pass-by-reference version of the = rich object that is passed-by-value. If clients have a shortcut (a = scope), they can use that; if they need the expressiveness of the = resources structure, they can do = that. 

Once again it does not seem that you = have read the latest draft. XAuth allows existing OAuth 2 scopes, OR = OAuth 2 scopes with RAR, OR a new type authorization type that works = differently.

I don=E2=80=99t think you read what I = wrote here. I did read the new XAuth draft before replying, and my = complaint is that it is still an = OR. 

It is an OR in that if the client is = using the type "oauth_scope", they cannot have an = "authorization_details" attribute, they can only have "scope"

If the client is using = the type "oauth_rich", the client MUST = include "authorization_details", and MAY include "scope"
 
I have updated the the doc to = better capture that:

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-3.4.4

and example 2 now is of type "oauth_rich"

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-3.2


It was not clear to me that both could be sent = with that mode, so thank you for updating that. But the client still has = to choose one or the other up front. Why not have a mechanism that it = can send both at all times? Why have a =E2=80=9Cmode=E2=80=9D type = switch at all? XYZ allows clients to make these combined requests with a = single consistent syntax.

And by = completely externalizing this to OAuth 2, I would argue that we lose an = opportunity to more clearly define how resources are described and used, = and we inherit the same combination issues that are facing RAR today. We = can do better because we get to define the context.



 


Summary

While concerns (3-7) can = be addressed in XYZ, (1-2) look fundamental to the XYZ = architecture.

[1] https://tools.ietf.org/html/draft-richer-transactional-authz-08= #section-7

[2] https://w3c.github.io/vc-data-model/

I=E2=80=99m = not sure what you intended to bring up about VC=E2=80=99s in your email, = because I didn=E2=80=99t see a back-reference to this, but I=E2=80=99m = glad you did mention it. This is an example of a query, assertion, and = proofing data model for users that uses a structure and language that is = outside of the OIDC world, but existing parallel to it. 
I meant to include [2] as another = claim schema in point (6) above. In XAuth, you will see that "vc" is = another object in the "claims" Object.
 
I believe our protocol needs to be flexible enough to allow = this kind of thing on input (the client presenting information about who = the user is, as well as requesting specific information about the user) = and output (the AS claiming information about the user), in addition to = the client being given something that it can then in turn use with = another service down the line to present user information. The world is = moving away from an IdP-driven identity model, and we need to keep = moving with it and enable it here.

We agree on the = flexibility. The XAuth proposal is to namespace the schemas so that = adopting existing schemas, or using a new one is = straightforward.

The XYZ proposal is to have a core = namespace for common elements and additionally to allow other namespaces = to be added in as needed.

I don't follow how this = would work. Perhaps you could provide an example in = JSON?

One method is defining a new value inside the XYZ = =E2=80=9Cclaims=E2=80=9D request object that maps to a specific = sub-schema:

claims: {
  =  =E2=80=9Csubject=E2=80=9D: true,
  =  =E2=80=9Cemail=E2=80=9D: true,
  =  =E2=80=9Coidc=E2=80=9D: {
  =      "userinfo":
  =       {
    =      "given_name": {"essential": = true},
        =  "nickname": null,
    =      "email": {"essential": true},
         "email_verified": = {"essential": true},
    =      "picture": null,
         "http://example.info/claims/groups": = null
        = },
      =  "id_token":
      =   {
        =  "auth_time": {"essential": true},
         "acr": {"values": = ["urn:mace:incommon:iap:silver"] }
  =       }
    =   }
}

That should look pretty familiar. Alternatively, = this could be done with a separate top-level request object = field:


claims: = {
   =E2=80=9Csubject=E2=80=9D: = true,
   =E2=80=9Cemail=E2=80=9D: = true
},
=E2=80=9Coidc_claims_request=E2=80=9D= : {
      =  "userinfo":
        = {
         "given_name": = {"essential": true},
        =  "nickname": null,
        =  "email": {"essential": true},
      =    "email_verified": {"essential": true},
  =        "picture": null,
    =      "http://example.info/claims/groups": null
  =       },
      =  "id_token":
        = {
         "auth_time": {"essential": = true},
         "acr": {"values": = ["urn:mace:incommon:iap:silver"] }
        = }
}

In both cases the AS is going to need to knit them = together into a sensible request policy, especially since the OIDC = claims query language has overlapping implications to one particular = resource, the UserInfo endpoint. My contention wasn=E2=80=99t with your = proposed solution, my contention was you claiming that XYZ has a fixed = schema and is therefore limited in extensibility.

 =E2=80=94 Justin
= --Apple-Mail=_5769A679-9256-427C-9108-CF575FD3AA0D-- From nobody Mon Jun 8 14:34:12 2020 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 7453E3A0788 for ; Mon, 8 Jun 2020 14:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 Yhdg1BR98TeJ for ; Mon, 8 Jun 2020 14:34:06 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89A83A0789 for ; Mon, 8 Jun 2020 14:34:05 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id j18so9345125lji.2 for ; Mon, 08 Jun 2020 14:34:05 -0700 (PDT) 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=M2kGDNdUuuFDVFeJrXtEBI5RC29QSIjXdtGUgKOXJRs=; b=Kvs+WMnu7ZvbZw6wPYPrGlObVps8d9/dCuaVFbIUQz35l2ioo6jen5XBXx8kZWgTeh W+cOAYQ23ko5ZRQ+7zRHFGvZNC81dLPvP46vQXNNYUuDADPC7FkNit2DNDznov8GtOsk 173tLb3Zu3559NqeKRo0pNi7aO2nceKcgvHXLPaz37FSC5/jcJlU8Y0lGz5uhd0o3Rdi Ilmr8USC/Yo0YO1gwb5gjAHn2H+5JOPS9/EsJYlsliGDgBxrWAdjdE6/QZuEl6sYP5+7 a7kGRIpFgXt9z+B84bgwe2qhBBGxoIOzdLO/Hwt4azgPGiR7rNHx3bvx8yG8za0QjZkQ l3Ew== 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=M2kGDNdUuuFDVFeJrXtEBI5RC29QSIjXdtGUgKOXJRs=; b=nfhm7+7LwKqlEtS54GZ9WMzv8NHcxpu2B1Hv3ct2VNM7W1IbmpA6Q7Ap0IKttZDk5T xaXw8lpUMjSgYzdEOfkT/nB+O9xclgfyt9/HnUtvpAKt9R8MnMd6DikTdiu9gJ+q/kd/ U3sUwjWH1Rzjgvnu7BvJfICa5PE/r7nlSTAATD8lyr+gF1fgZZX1LJnR2c/zw40Gz0rx KU00y8nE4qUlU/hMHGuwzXF4UZ0xKcGzxrcTMlB1cTGd847Siw3UGCak5R9MLvqo7/vT SgEvnotfqwu/rSi6DpddJla/yxcCvHMOhDU4i+vL7G8f9/dGoWRjIRK7ypQEpSEHSCzR OWYA== X-Gm-Message-State: AOAM533meXa1sdCM5Gv3tvc1rU60c4i9TMN8l0KL5wwOGMWvD58CHqgU JqqpAfTQTq3KLRB9pQpFsU95s46FIwweFWZCscg= X-Google-Smtp-Source: ABdhPJyypRoW3rKqwiwbX3tQSotjVnPvDdQ2T3ZgKT3xpbFCCuC2JqBp2N3hPGk+wXWj57XErO17Uyy4Aqb1NFImuRQ= X-Received: by 2002:a2e:9987:: with SMTP id w7mr11428672lji.215.1591652043912; Mon, 08 Jun 2020 14:34:03 -0700 (PDT) MIME-Version: 1.0 References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> In-Reply-To: <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> From: Dick Hardt Date: Mon, 8 Jun 2020 14:33:37 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000aefda705a7995e5a" Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 08 Jun 2020 21:34:11 -0000 --000000000000aefda705a7995e5a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 8, 2020 at 1:02 PM Justin Richer wrote: > A GS implementation can decide to only return an authorization from doing > a GET on the AZ URL. Returning only an AZ URL is an option in XAuth. > Similarly, we could do the same for a Grant URI. > > > And that=E2=80=99s a lot of complex code paths for both the GS and client= to deal > with. With more ways that it might happen, the client has to be prepared > for any of them =E2=80=94 and get them all right. > I don't see it being complex. The data either moves by reference or by value. Both parties will have to enable support by reference. Passing by value is an optimization so that the client does not have to make an additional call. > > > >> >> Using a different URI, optionally, isn=E2=80=99t the problem, and that c= ould >> easily be added to the. Removal of the separate handle is the problem I >> have with the XAuth approach. >> > > In XAuth, the Grant URI is the GS URI + TBD + handle > > Given we have asymmetric crypto as a requirement, it is unclear what > having two pieces of random signal provide. > > > Asymmetric crypto is an implementation requirement in both the input > drafts but it isn=E2=80=99t a requirement in the charter, and there are l= ikely > symmetric use cases and key proofing mechanisms that are going to be > desirable for a lot of people. > > > >> >> >> >>> >>> Additionally, I find XAuth=E2=80=99s restrictions on the structure of t= he Grant >>> URI potentially problematic, namely that it has to start with the serve= r=E2=80=99s >>> URL. This will lead to deployments needing to bend their setups with >>> proxies or redirectors to make things fit, which you yourself have said= is >>> going to be an issue for things like supporting a short redirect URL vs= . a >>> long redirect URL. Your complaint there was one of latency and complexi= ty, >>> why does that not apply here? But most fundamentally, I do not see what >>> value this restriction brings to the system. If the value is coming bac= k >>> from the GS endpoint, and the client is getting all of its pointers fro= m >>> there, what=E2=80=99s the point of dictating how that has to look? >>> >> >> Requiring the Grant URI to start with the GS URI is open to discussion. >> It is not clear to me why a deployment would need to have a redirector. >> Large scale deployments I have worked on have a router / proxy that rout= es >> requests to internal services. Having all the URIs start with the GS URI >> enables all GNAP operations to be routed in the same place. >> >> >> You still haven=E2=80=99t addressed why you think that this is a reasona= ble >> requirement or assumption here but not when dealing with long/short URLs >> for QR codes. What is the difference? >> > > Short URLs generally use a short host name as well as a short path. > > Most REST interfaces have the pattern I am proposing. A mental model many > developers are familiar with. > > > This is assuming a lot on the part of the GS implementation, still, and > all of my arguments stand. > > > That is not entirely correct. A pre-registered client can still pass its > key by value, and a dynamic client can still use a (dynamically-acquired) > handle. In all cases, the client is identifying itself by its key. The > difference is how the server looks up that key =E2=80=94 it=E2=80=99s eit= her from the > handle, or it=E2=80=99s from the key value itself. > I don't understand this. How is the Client authenticating that it is a specific pre-registered client? > >> >>> >>> *5) Interaction Capabilities vs Modes* >>> >>> In XYZ, the capabilities are expressed by the client, and the GS states >>> which capabilities it will accept. This can make it difficult for the G= S to >>> enforce the interaction choices as the client can mix and match which >>> capabilities are returned. For example, a GS may not want to support a >>> redirect without a callback to protect itself from session fixation >>> attacks. In XAuth, the interaction modes provide clarity on the mode of >>> interaction and the security properties. For example the GS may support >>> both user_code and redirect modes, but not the indirect mode which is >>> subject to session fixation attacks. >>> >>> >>> If the GS doesn=E2=80=99t want to accept a redirect without a callback,= it can >>> because the request will have a redirect, but not a callback, and it ca= n >>> reject the request. What makes you believe that this is not detectable = or >>> not possible in XYZ? >>> >> >> I did not say it could not be done, I'm saying it is more difficult in >> XYZ than in XAuth >> >> >> Can you explain to me how it=E2=80=99s more difficult in XYZ? I have exp= lained >> how it can be done and I am failing to see why you think it=E2=80=99s ha= rder. >> > > Having both a handle and a URI seems more complicated than just a URI. > > > You=E2=80=99re conflating things: This is a separate discussion. Here we = are > talking about how it=E2=80=99s more difficult for an AS to determine the = presence > or absence of the =E2=80=9Ccallback=E2=80=9D field vs. detecting the pres= ence or absence of > the =E2=80=9Cdirect=E2=80=9D and/or =E2=80=9Cindirect=E2=80=9D fields. > My bad. I got confused which topic we were on. In XAuth, if the server wants to protect itself from a session fixation attack in a given request, and it wants to support both "redirect" and "user_code" modes, the server will return only those two modes and not "indirect". The In XAuth, if the server wants to protect itself from a session fixation attack in a given request, and it wants to support both "redirect" and "user_code" modes, the server MUST return callback, redirect, and user_code. The client does not know that the "indirect" mode is not supported, and may try that. > > > If you think that having a URI in addition to a handle makes sense, how > about you put that into your draft and see how it works? > > > Because I haven=E2=80=99t had an opportunity to implement it in this way = yet, and > I=E2=80=99m not yet convinced the extra complexity is worth it. I said it= MIGHT > make sense and it=E2=80=99s worth talking about, which has been my public= stance > since before you proposed XAuth. That=E2=80=99s still the case, and I=E2= =80=99ve gone to > length here on the list (which is under the IETF IPR rules) to discuss it= . > Are you suggesting that I need to prove this to you in a particular way, > instead? > No. I'm saying that stating it could be done is different than writing it up. I would expect your draft to be the culmination of your convictions. > As this is an individual draft, it should represent what I, personally, > think is the best approach. Part of my criteria for adding things to my > individual draft is making sure it at least makes some amount of sense wi= th > real code. Your draft should likewise follow your own convictions. > Agreed. > > > For example: > > How is a transaction updated? > How are separate access tokens refreshed? > Refreshing an access token in XYZ returns a full transaction response per > Section 9.3 which refers to Section 8. > > > By using URIs and methods, XAuth has an easy to understand API for CRUD > operations on Grants and Authorizations. > > > +--------------+-----------+--------+-----------------------------+ > | request | http verb | uri | response | > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > | Create Grant | POST | GS URI | interaction, wait, or grant | > +--------------+-----------+--------+-----------------------------+ > | List Grants | GET | GS URI | grant list | > +--------------+-----------+--------+-----------------------------+ > | Verify Grant | PATCH | Grant | grant | > | | | URI | | > +--------------+-----------+--------+-----------------------------+ > | Read Grant | GET | Grant | wait, or grant | > | | | URI | | > +--------------+-----------+--------+-----------------------------+ > | Update Grant | PUT | Grant | interaction, wait, or grant | > | | | URI | | > +--------------+-----------+--------+-----------------------------+ > | Delete Grant | DELETE | Grant | success | > | | | URI | | > +--------------+-----------+--------+-----------------------------+ > | Read AuthZ | GET | AZ URI | authorization | > +--------------+-----------+--------+-----------------------------+ > | Update AuthZ | PUT | AZ URI | authorization | > +--------------+-----------+--------+-----------------------------+ > | Delete AuthZ | DELETE | AZ URI | success | > +--------------+-----------+--------+-----------------------------+ > | GS Options | OPTIONS | GS URI | metadata | > +--------------+-----------+--------+-----------------------------+ > | Grant | OPTIONS | Grant | metadata | > | Options | | URI | | > +--------------+-----------+--------+-----------------------------+ > | AuthZ | OPTIONS | AZ URI | metadata | > | Options | | | | > +--------------+-----------+--------+-----------------------------+ > > > > > While this looks good on paper, there are very pragmatic reasons that man= y > APIs have moved away from purely RESTful patterns over the last decade, > including limitations on what can be sent with GET and DELETE requests, f= or > example. I don=E2=80=99t think it=E2=80=99s as clean a win as you=E2=80= =99re presenting it, but I > think it=E2=80=99s worth checking out. > Agreed that RESTful does not work for everything. It does look like it maps well here. > > >> >> >>> >>> The modes in XAuth are much more limiting, as the mixing of different >>> interaction methods is already something that we need to start figuring >>> out. Let=E2=80=99s say, for example, a client can do a redirect, accept= a >>> CIBA-style ping, or do a direct app2app communication. There=E2=80=99s = a natural >>> preference the client will have here: if it can talk to another app >>> directly, it=E2=80=99ll try that first. If that doesn=E2=80=99t work, i= t can get a push >>> notification sent, and if all that fails, it can pop open a browser. If >>> I have to pick just one of those modes when I make the request, then th= e >>> client needs to make three different requests to the AS before I get >>> anything that works. >>> >> >> Have you read the revised draft? As I noted above, I have added >> negotiation. The Client can state all the modes it wants, the GS can >> respond with the modes it will support, and the Client can offer the Use= r >> any modes returned from the GS. >> >> >> Yes, did you read what I wrote? I think we=E2=80=99re talking past each = other. >> > > This is not how XAuth is written currently. The Client can list all of > the modes it wants to use. The Server will return all the modes that fit = in > its policy for the Grant Request. Why would the Client need to make > different requests? > > per > > https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.2 > > The interaction object contains one or more interaction mode objects per > Section 5 > > Three modes are defined here: > > https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-5 > > More modes may defined in extensions, or in this document. > > > Yes, this is an improvement, and I=E2=80=99m glad you=E2=80=99re moving y= our thinking in > this direction. However, it=E2=80=99s still not as clear how things combi= ne to > solve different use cases, and it conflates the means of getting the user > TO the interaction page with the way of getting them BACK from it. It=E2= =80=99s > these flexible combinations that I think are important, and I don=E2=80= =99t think > XAuth gets this quite right yet. > I think how the user gets to and from the server is CRITICAL to the server if it wants to protect itself from a session fixation attack. See above where the client does not know what it can actually do that the server will allow. > > It is an OR in that if the client is using the type "oauth_scope", they > cannot have an "authorization_details" attribute, they can only have "sco= pe" > > If the client is using the type "oauth_rich", the client MUST > include "authorization_details", and MAY include "scope" > > I have updated the the doc to better capture that: > > https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.4 > > and example 2 now is of type "oauth_rich" > > https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.2 > > > It was not clear to me that both could be sent with that mode, so thank > you for updating that. But the client still has to choose one or the othe= r > up front. Why not have a mechanism that it can send both at all times? Wh= y > have a =E2=80=9Cmode=E2=80=9D type switch at all? XYZ allows clients to m= ake these combined > requests with a single consistent syntax. > > And by completely externalizing this to OAuth 2, I would argue that we > lose an opportunity to more clearly define how resources are described an= d > used, and we inherit the same combination issues that are facing RAR toda= y. > We can do better because we get to define the context. > This group can define a new syntax if it wants, and it will be unencumbered by the OAuth 2 and RAR legacy if deployments that want to use the OAuth 2 and RAR syntax can use them directly. Ie, there can be a type "gnap" or some such. > I don't follow how this would work. Perhaps you could provide an example > in JSON? > > > One method is defining a new value inside the XYZ =E2=80=9Cclaims=E2=80= =9D request object > that maps to a specific sub-schema: > > claims: { > =E2=80=9Csubject=E2=80=9D: true, > =E2=80=9Cemail=E2=80=9D: true, > =E2=80=9Coidc=E2=80=9D: { > "userinfo": > { > "given_name": {"essential": true}, > "nickname": null, > "email": {"essential": true}, > "email_verified": {"essential": true}, > "picture": null, > "http://example.info/claims/groups": null > }, > "id_token": > { > "auth_time": {"essential": true}, > "acr": {"values": ["urn:mace:incommon:iap:silver"] } > } > } > } > > > That should look pretty familiar. Alternatively, this could be done with = a > separate top-level request object field: > > > claims: { > =E2=80=9Csubject=E2=80=9D: true, > =E2=80=9Cemail=E2=80=9D: true > }, > =E2=80=9Coidc_claims_request=E2=80=9D: { > "userinfo": > { > "given_name": {"essential": true}, > "nickname": null, > "email": {"essential": true}, > "email_verified": {"essential": true}, > "picture": null, > "http://example.info/claims/groups": null > }, > "id_token": > { > "auth_time": {"essential": true}, > "acr": {"values": ["urn:mace:incommon:iap:silver"] } > } > } > > > In both cases the AS is going to need to knit them together into a > sensible request policy, especially since the OIDC claims query language > has overlapping implications to one particular resource, the UserInfo > endpoint. My contention wasn=E2=80=99t with your proposed solution, my co= ntention > was you claiming that XYZ has a fixed schema and is therefore limited in > extensibility. > One of the objectives of this work is to have extension points. My point was that XAuth had a clear extension point for adding schemas. How to extend XYZ was not clear in your proposal. I think the XAuth proposal is better than the two examples you proposed. In your first example, the schema is a second class schema, and in your second example, claims are spread across to top level options. Both of these pollute other schemas. /Dick =E1=90=A7 --000000000000aefda705a7995e5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jun 8, 2020 at 1:02 PM Justin= Richer <jricher@mit.edu> wrot= e:

<snip>
=
A GS implementation can= decide to only return an authorization from doing a GET on the AZ URL. Ret= urning only an AZ URL is an option in XAuth. Similarly, we could do the sam= e for a Grant URI.=C2=A0

And that=E2=80=99s a lot of complex code paths for both the GS and cl= ient to deal with. With more ways that it might happen, the client has to b= e prepared for any of them =E2=80=94 and get them all right.=C2=A0

I don't see it being complex.= The data either moves by reference or by value. Both parties will have to = enable support by reference. Passing by value is an optimization so that th= e client does not have to make an additional call.

=C2=A0<snip>
=

=C2=A0

Using a different URI, optionally, isn=E2=80=99t the problem, and that co= uld easily be added to the. Removal of the separate handle is the problem I= have with the XAuth approach.

In XAuth, the Grant URI is the GS URI=C2=A0+ TBD=C2=A0+ handle
<= div>
Given we have asymmetric=C2=A0crypto as a requirement, i= t is unclear what having two pieces of random signal=C2=A0provide.

Asymmetric crypto is an imp= lementation requirement in both the input drafts but it isn=E2=80=99t a req= uirement in the charter, and there are likely symmetric use cases and key p= roofing mechanisms that are going to be desirable for a lot of people.
=C2=A0

=
=C2=A0

Additionally, I find XAuth= =E2=80=99s restrictions on the structure of the Grant URI potentially probl= ematic, namely that it has to start with the server=E2=80=99s URL. This wil= l lead to deployments needing to bend their setups with proxies or redirect= ors to make things fit, which you yourself have said is going to be an issu= e for things like supporting a short redirect URL vs. a long redirect URL. = Your complaint there was one of latency and complexity, why does that not a= pply here? But most fundamentally, I do not see what value this restriction= brings to the system. If the value is coming back from the GS endpoint, an= d the client is getting all of its pointers from there, what=E2=80=99s the = point of dictating how that has to look?

Requiring the Grant URI to start with the GS URI is open to= discussion. It is not clear to me why a deployment would need to have a re= director. Large scale deployments I have worked on have a router / proxy th= at routes requests to internal services. Having all the URIs start with the= GS URI enables all GNAP operations to be routed in the same place.

You still haven=E2=80=99t = addressed why you think that this is a reasonable requirement or assumption= here but not when dealing with long/short URLs for QR codes. What is the d= ifference?

Short URLs gen= erally use a short host name as well as a short path.=C2=A0

<= /div>
Most REST interfaces have the pattern I am proposing. A mental mo= del many developers are familiar with.=C2=A0

This is assuming a lot on the part of the GS impl= ementation, still, and all of my arguments stand.=C2=A0


<= /div>
<= div>That is not entirely correct. A pre-registered client can still pass its key by value, and = a dynamic client can still use a (dynamically-acquired) handle. In all case= s, the client is identifying itself by its key. The difference is how the s= erver looks up that key =E2=80=94 it=E2=80=99s either from the handle, or i= t=E2=80=99s from the key value itself.=C2=A0
=

I don'= ;t understand this.= =C2=A0

How is the Client authenticating that it is= a specific pre-registered client?
=C2=A0
<snip><= /div>
=
=C2=A0

5) Interaction Capabilities vs Modes

In XYZ, the capabilities are expressed by the= client, and the GS states which capabilities it will accept. This can make= it difficult for the GS to enforce the interaction choices as the client c= an mix and match which capabilities are returned. For example, a GS may not= want to support a redirect without a callback to protect itself from sessi= on fixation attacks. In XAuth, the interaction modes provide clarity on the= mode of interaction and the security properties. For example the GS may su= pport both user_code and redirect modes, but not the indirect mode which is= subject to session fixation attacks.


If the GS doesn=E2=80=99t want to accept= a redirect without a callback, it can because the request will have a redi= rect, but not a callback, and it can reject the request. What makes you bel= ieve that this is not detectable or not possible in XYZ?=C2=A0
<= /div>

I did not say it could not be done, I= 'm saying it is more difficult in XYZ than in XAuth

Can you explain to me how it=E2=80=99s= more difficult in XYZ? I have explained how it can be done and I am failin= g to see why you think it=E2=80=99s harder.
<= div>
Having both a handle and a URI seems more complicated th= an just a URI.

You= =E2=80=99re conflating things: This is a separate discussion. Here we are t= alking about how it=E2=80=99s more difficult for an AS to determine the pre= sence or absence of the =E2=80=9Ccallback=E2=80=9D field vs. detecting the = presence or absence of the =E2=80=9Cdirect=E2=80=9D and/or =E2=80=9Cindirec= t=E2=80=9D fields.

My bad= . I got confused which topic we were on.

In XAuth,= if the server wants to protect itself from a session fixation attack in a = given request, and it wants to support both "redirect" and "= user_code" modes,=C2=A0
the server will return only those tw= o modes and not "indirect". The=C2=A0

In XAuth, if the server wants to protect itself from a session fixation = attack in a given request, and it wants to support both "redirect"= ; and "user_code" modes,=C2=A0
the ser= ver MUST return=C2=A0callback, redirect, and user_code. The client does not= know that the "indirect" mode is not supported, and may try that= .

=C2=A0


=
If you think that having a URI in addition to a handle makes sense, ho= w about you put that into your draft and see how it works?

Because I haven=E2=80=99t had an op= portunity to implement it in this way yet, and I=E2=80=99m not yet convince= d the extra complexity is worth it. I said it MIGHT make sense and it=E2=80= =99s worth talking about, which has been my public stance since before you = proposed XAuth. That=E2=80=99s still the case, and I=E2=80=99ve gone to len= gth here on the list (which is under the IETF IPR rules) to discuss it. Are= you suggesting that I need to prove this to you in a particular way, inste= ad?

No. I'm saying that st= ating it could be done is different than writing it up. I would expect your= draft to be the culmination of your convictions.
=C2=A0
As this is an individual draft, it should represent what= I, personally, think is the best approach. Part of my criteria for adding = things to my individual draft is making sure it at least makes some amount = of sense with real code. Your draft should likewise follow your own convict= ions.

Agreed.=C2=A0
<= br>
=C2=A0

<= br>
For example:=C2=A0

How is a transact= ion updated?=C2=A0
How are separate access tokens refreshed?=C2= =A0
Refreshing an access token in XYZ returns a full transaction = response per Section 9.3 which refers to Section 8.


By using URIs and methods, XAuth has an easy to under= stand API for CRUD operations on Grants and Authorizations.

    +--------------+-----------=
+--------+-----------------------------+
    | request      | http verb | uri    | response                    |
    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
    | Create Grant | POST      | GS URI | interaction, wait, or grant |
    +--------------+-----------+--------+-----------------------------+
    | List Grants  | GET       | GS URI | grant list                  |
    +--------------+-----------+--------+-----------------------------+
    | Verify Grant | PATCH     | Grant  | grant                       |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read Grant   | GET       | Grant  | wait, or grant              |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Update Grant | PUT       | Grant  | interaction, wait, or grant |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Delete Grant | DELETE    | Grant  | success                     |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read AuthZ   | GET       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Update AuthZ | PUT       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Delete AuthZ | DELETE    | AZ URI | success                     |
    +--------------+-----------+--------+-----------------------------+
    | GS Options   | OPTIONS   | GS URI | metadata                    |
    +--------------+-----------+--------+-----------------------------+
    | Grant        | OPTIONS   | Grant  | metadata                    |
    | Options      |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | AuthZ        | OPTIONS   | AZ URI | metadata                    |
    | Options      |           |        |                             |
    +--------------+-----------+--------+-----------------------------+
=C2=A0

While this looks good on paper, there are very pragmatic reasons that many= APIs have moved away from purely RESTful patterns over the last decade, in= cluding limitations on what can be sent with GET and DELETE requests, for e= xample. I don=E2=80=99t think it=E2=80=99s as clean a win as you=E2=80=99re= presenting it, but I think it=E2=80=99s worth checking out.

Agreed that RESTful does not work for everyth= ing. It does look like it maps well here.
=C2=A0


=C2=A0

The modes in XAuth are much mor= e limiting, as the mixing of different interaction methods is already somet= hing that we need to start figuring out. Let=E2=80=99s say, for example, a = client can do a redirect, accept a CIBA-style ping, or do a direct app2app = communication. There=E2=80=99s a natural preference the client will have he= re: if it can talk to another app directly, it=E2=80=99ll try that first. I= f that doesn=E2=80=99t work, it can get a push notification sent, and if al= l that fails, it can pop open a browser. If I have to pick just one of those modes when I make the req= uest, then the client needs to make three different requests to the AS befo= re I get anything that works.=C2=A0

Have you read the revised draft? As I noted above, I have= added negotiation. The Client can state all the modes it wants, the GS can= respond with the modes it will support, and the Client can offer the User = any modes returned from the GS.
Yes, did you read what I wrote? I think we=E2=80=99re talking = past each other.

This is not how XAuth is wri= tten currently. The Client can list all of the modes it wants to use. The S= erver will return all the modes that fit in its policy for the Grant Reques= t. Why would the Client need to make different requests?

per


The interaction object contains one or more inter= action mode objects per Section 5

Three modes = are defined here:


More modes may defined in extensions, or in this document.=

Yes, this is an im= provement, and I=E2=80=99m glad you=E2=80=99re moving your thinking in this= direction. However, it=E2=80=99s still not as clear how things combine to = solve different use cases, and it conflates the means of getting the user T= O the interaction page with the way of getting them BACK from it. It=E2=80= =99s these flexible combinations that I think are important, and I don=E2= =80=99t think XAuth gets this quite right yet.=C2=A0

I think how the user gets to and from the serve= r is CRITICAL to the server if it wants to protect itself from a session fi= xation attack.
See above where the client does not know what it c= an actually do that the server will allow.
=C2=A0
<s= nip>

It is an OR in tha= t if the client is using the type "oauth_scope", they cannot have= an "authorization_details" attribute, they can only have "s= cope"

If the client is using the type "o= auth_rich", the client MUST include=C2=A0"authorization_details&q= uot;, and MAY include "scope"
=C2=A0
I have u= pdated the the doc to better capture that:


and example 2 now is of t= ype "oauth_rich"



It was not clear to me that both could be sent with that mode, so thank yo= u for updating that. But the client still has to choose one or the other up= front. Why not have a mechanism that it can send both at all times? Why ha= ve a =E2=80=9Cmode=E2=80=9D type switch at all? XYZ allows clients to make = these combined requests with a single consistent syntax.

And by completely externalizing this to OAuth 2, I would argue that = we lose an opportunity to more clearly define how resources are described a= nd used, and we inherit the same combination issues that are facing RAR tod= ay. We can do better because we get to define the context.

This group can define a new syntax if it = wants, and it will be unencumbered by the OAuth 2 and RAR legacy if deploym= ents that want to use the OAuth 2 and RAR syntax can use them directly. Ie,= there can be a type "gnap" or some such.

=C2=A0<snip>
<= div>
I don't follow how= this would work. Perhaps you could provide an example in JSON?
=

One method is defining a new v= alue inside the XYZ =E2=80=9Cclaims=E2=80=9D request object that maps to a = specific sub-schema:

claims: {
=C2=A0 =C2=A0=E2=80=9Csubject=E2=80=9D: true,
= =C2=A0 =C2=A0=E2=80=9Cemail=E2=80=9D: true,
=C2=A0 =C2= =A0=E2=80=9Coidc=E2=80=9D: {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0"userinfo":
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"given_name&qu= ot;: {"essential": true},
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0"nickname": null,
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0"email": {"essential": true}= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"email_verifi= ed": {"essential": true},
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0"picture": null,
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0"http://example.info/claims/groups": null
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2= =A0 =C2=A0 =C2=A0 =C2=A0"id_token":
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0"auth_time": {"essential": true},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"acr": {"values": = ["urn:mace:incommon:iap:silver"] }
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }
}

That should= look pretty familiar. Alternatively, this could be done with a separate to= p-level request object field:


= claims: {
=C2=A0 =C2=A0=E2=80=9Csubject=E2=80=9D: true= ,
=C2=A0 =C2=A0=E2=80=9Cemail=E2=80=9D: true
},
=E2=80=9Coidc_claims_request=E2=80=9D: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0"userinfo":
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"gi= ven_name": {"essential": true},
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0"nickname": null,
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0"email": {"essential": true},
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"email_verified": {"essent= ial": true},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"picture= ": null,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"http://example.info/cl= aims/groups": null
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0"id_token":
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"auth_= time": {"essential": true},
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0"acr": {"values": ["urn:mace:incommon= :iap:silver"] }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
}

In both cases the AS i= s going to need to knit them together into a sensible request policy, espec= ially since the OIDC claims query language has overlapping implications to = one particular resource, the UserInfo endpoint. My contention wasn=E2=80=99= t with your proposed solution, my contention was you claiming that XYZ has = a fixed schema and is therefore limited in extensibility.
=

One of the objectives of this work is to h= ave extension points. My point was that XAuth had a clear extension point f= or adding schemas. How to extend XYZ was not clear in=C2=A0your proposal.

I think the XAuth proposal is better than the two e= xamples you proposed. In your first example, the schema is a second class s= chema, and in your second example, claims are spread across to top level op= tions. Both of these pollute other schemas.

/Dick<= /div>

3D""=E1=90=A7
--000000000000aefda705a7995e5a-- From nobody Tue Jun 9 09:10:53 2020 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 050DE3A08FD for ; Tue, 9 Jun 2020 09:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 0ap5gyIO9c-s for ; Tue, 9 Jun 2020 09:10:48 -0700 (PDT) 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 051E33A08E7 for ; Tue, 9 Jun 2020 09:10:47 -0700 (PDT) Received: from [192.168.1.14] (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 059GAeXd006642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 9 Jun 2020 12:10:41 -0400 From: Justin Richer Message-Id: <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_E550DFD4-59B0-4B17-A802-15F7C9BC8C6A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 9 Jun 2020 12:10:40 -0400 In-Reply-To: Cc: txauth@ietf.org To: Dick Hardt References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 09 Jun 2020 16:10:52 -0000 --Apple-Mail=_E550DFD4-59B0-4B17-A802-15F7C9BC8C6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 8, 2020, at 5:33 PM, Dick Hardt wrote: >=20 >=20 >=20 > On Mon, Jun 8, 2020 at 1:02 PM Justin Richer > wrote: >=20 > >> A GS implementation can decide to only return an authorization from = doing a GET on the AZ URL. Returning only an AZ URL is an option in = XAuth. Similarly, we could do the same for a Grant URI.=20 >=20 > And that=E2=80=99s a lot of complex code paths for both the GS and = client to deal with. With more ways that it might happen, the client has = to be prepared for any of them =E2=80=94 and get them all right.=20 >=20 > I don't see it being complex. The data either moves by reference or by = value. Both parties will have to enable support by reference. Passing by = value is an optimization so that the client does not have to make an = additional call. =E2=80=9CBoth parties will have to enable=E2=80=9D is where the = complexity comes into play. It=E2=80=99s putting a requirement on the = client to anticipate several different ways to get the same information. >=20 > >=20 >> =20 >>=20 >> Using a different URI, optionally, isn=E2=80=99t the problem, and = that could easily be added to the. Removal of the separate handle is the = problem I have with the XAuth approach. >>=20 >> In XAuth, the Grant URI is the GS URI + TBD + handle >>=20 >> Given we have asymmetric crypto as a requirement, it is unclear what = having two pieces of random signal provide. >=20 > Asymmetric crypto is an implementation requirement in both the input = drafts but it isn=E2=80=99t a requirement in the charter, and there are = likely symmetric use cases and key proofing mechanisms that are going to = be desirable for a lot of people. >=20 >> =20 >>=20 >>> =20 >>>=20 >>> Additionally, I find XAuth=E2=80=99s restrictions on the structure = of the Grant URI potentially problematic, namely that it has to start = with the server=E2=80=99s URL. This will lead to deployments needing to = bend their setups with proxies or redirectors to make things fit, which = you yourself have said is going to be an issue for things like = supporting a short redirect URL vs. a long redirect URL. Your complaint = there was one of latency and complexity, why does that not apply here? = But most fundamentally, I do not see what value this restriction brings = to the system. If the value is coming back from the GS endpoint, and the = client is getting all of its pointers from there, what=E2=80=99s the = point of dictating how that has to look? >>>=20 >>> Requiring the Grant URI to start with the GS URI is open to = discussion. It is not clear to me why a deployment would need to have a = redirector. Large scale deployments I have worked on have a router / = proxy that routes requests to internal services. Having all the URIs = start with the GS URI enables all GNAP operations to be routed in the = same place. >>=20 >> You still haven=E2=80=99t addressed why you think that this is a = reasonable requirement or assumption here but not when dealing with = long/short URLs for QR codes. What is the difference? >>=20 >> Short URLs generally use a short host name as well as a short path.=20= >>=20 >> Most REST interfaces have the pattern I am proposing. A mental model = many developers are familiar with.=20 >=20 > This is assuming a lot on the part of the GS implementation, still, = and all of my arguments stand.=20 >=20 >=20 > That is not entirely correct. A pre-registered client can still pass = its key by value, and a dynamic client can still use a = (dynamically-acquired) handle. In all cases, the client is identifying = itself by its key. The difference is how the server looks up that key = =E2=80=94 it=E2=80=99s either from the handle, or it=E2=80=99s from the = key value itself.=20 >=20 > I don't understand this.=20 >=20 > How is the Client authenticating that it is a specific pre-registered = client? The client is identified by its key. There is no external client = identifier. I think you=E2=80=99re confused because you=E2=80=99re still = thinking in terms of OAuth 2=E2=80=99s client ID based model and I am = trying to move us past that. It took me time to realize that we really = can let it go, so hopefully this is helpful in explaining why. When a credential is cryptographically random enough to be unique, it = can be used as its own identifier, particularly when you don=E2=80=99t = need to identify the entity outside of the context that it can present = and prove its credential. To stretch a metaphor, passwords don=E2=80=99t = always need usernames. This is, after all, the driving design pattern = behind OAuth access tokens. An access token doesn=E2=80=99t have a = =E2=80=9Cusername=E2=80=9D portion to it, even though it would have been = trivial to require the client to send its client ID alongside the access = token. Why does that work? Because our model of what the RS does with = the access token is built around it answering the questions: is this = token valid and does it allow what=E2=80=99s being requested? If the RS = needs to know which client was issued the token, it can discover that = information without being told separately from the token -- perhaps = it=E2=80=99s in the token itself or it=E2=80=99s in an introspection = response. And in a lot of cases, the RS doesn=E2=80=99t care about the = client software, it just wants to know if the token=E2=80=99s any good. = Even in constrained tokens such as MTLS, PoP, and DPoP, we aren=E2=80=99t = really authenticating the client at the RS so much as making sure the = right key is presented alongside the right token.=20 XYZ takes that same approach with the client talking to the AS and uses = the credential (key) to identify the client as well as authenticate and = protect the request. We can=E2=80=99t just say =E2=80=9COAuth 2 had = client IDs and people are used to it so it must be good and we have to = keep using it=E2=80=9D. We need to ask WHY OAuth 2 needs client IDs and = if that still makes sense. I argue that it doesn=E2=80=99t make sense = anymore and we need to step back and look at a better model. OAuth 2 = needs a client ID because it gets passed in the front channel and the = client=E2=80=99s credentials can=E2=80=99t be used there. The access = token doesn=E2=80=99t need an equivalent because it=E2=80=99s passed in = the back channel and can be used directly. Now that the client no longer = needs to be identified, but not authenticated, through untrusted third = parties (such as the browser), we don=E2=80=99t need to have a separate = identifier as part of the protocol. With an intent-based protocol, that = starts in the back channel, you don=E2=80=99t need a client identifier = anymore. Once the AS finds that key, the AS can then figure out what = policies, rights, and restrictions are attached to that key. In many = implementations, there=E2=80=99s going to be some kind of =E2=80=9Cregiste= red client=E2=80=9D object in a database somewhere that drives those = policies. That=E2=80=99s the classical OAuth model, and it works in many = cases. But in other cases, the key is going to just be a value used to = protect the request chain (and possibly the token itself), and the = policy is going to be built up by other things like a device posture or = signature on the calling software or verified user information. It=E2=80=99= s not just about client authentication, even though it can be used for = it. DPoP, PKCE, and DynReg have shown us the value in dynamic systems, = in different ways.=20 On top of that, PAR is showing us that a lot of the constraints that we = have in OAuth 2 don=E2=80=99t really apply anymore. For instance, = Redirect URI restrictions can be relaxed because now you CAN identify = and authenticate the software sending it, which isn=E2=80=99t true with = a front-channel-first approach. All of the things that are required in = OAuth 2 start to become redundant, and it leads to things like requiring = that =E2=80=9Cclient_id=E2=80=9D still always be passed in the front = channel even though the information could be looked up from an internal = request_uri reference using PAR and JAR together. That=E2=80=99s why a key handle isn=E2=80=99t exactly the same as a = client ID and I did not call it a client ID in the XYZ protocol. It=E2=80=99= s a shortcut to refer to the key material for certain optimized cases, = but ultimately it=E2=80=99s pointing to a key. This has an interesting = and beneficial side effect =E2=80=94 if you HAVE a client ID as part of = your internal data model, it can FUNCTION as a key handle because it=E2=80= =99s a unique value the AS can use to look up key information. It=E2=80=99= s not =E2=80=9Cauthenticating the client=E2=80=9D, it=E2=80=99s pointing = to a key which in turn identifies and authenticates the software making = the call. The fact that it=E2=80=99s a =E2=80=9Cclient ID=E2=80=9D is an = artifact of the implementation, which in this case has an OAuth 2 legacy = to work with.=20 If we=E2=80=99re going to move past the constraints of OAuth 2 we need = to stop thinking so strictly in its terms and models. There are better = ways to approach this now and client IDs are not required by this = protocol model. > =20 > >>> =20 >>>=20 >>>> 5) Interaction Capabilities vs Modes >>>>=20 >>>> In XYZ, the capabilities are expressed by the client, and the GS = states which capabilities it will accept. This can make it difficult for = the GS to enforce the interaction choices as the client can mix and = match which capabilities are returned. For example, a GS may not want to = support a redirect without a callback to protect itself from session = fixation attacks. In XAuth, the interaction modes provide clarity on the = mode of interaction and the security properties. For example the GS may = support both user_code and redirect modes, but not the indirect mode = which is subject to session fixation attacks. >>>>=20 >>>=20 >>> If the GS doesn=E2=80=99t want to accept a redirect without a = callback, it can because the request will have a redirect, but not a = callback, and it can reject the request. What makes you believe that = this is not detectable or not possible in XYZ?=20 >>>=20 >>> I did not say it could not be done, I'm saying it is more difficult = in XYZ than in XAuth >>=20 >> Can you explain to me how it=E2=80=99s more difficult in XYZ? I have = explained how it can be done and I am failing to see why you think = it=E2=80=99s harder. >>=20 >> Having both a handle and a URI seems more complicated than just a = URI. >=20 > You=E2=80=99re conflating things: This is a separate discussion. Here = we are talking about how it=E2=80=99s more difficult for an AS to = determine the presence or absence of the =E2=80=9Ccallback=E2=80=9D = field vs. detecting the presence or absence of the =E2=80=9Cdirect=E2=80=9D= and/or =E2=80=9Cindirect=E2=80=9D fields. >=20 > My bad. I got confused which topic we were on. >=20 > In XAuth, if the server wants to protect itself from a session = fixation attack in a given request, and it wants to support both = "redirect" and "user_code" modes,=20 > the server will return only those two modes and not "indirect". The=20 >=20 > In XAuth, if the server wants to protect itself from a session = fixation attack in a given request, and it wants to support both = "redirect" and "user_code" modes,=20 > the server MUST return callback, redirect, and user_code. The client = does not know that the "indirect" mode is not supported, and may try = that. >=20 In XYZ, if the server wants to protect against a session fixation = attack, it will reject a request that doesn=E2=80=99t have a = =E2=80=9Ccallback=E2=80=9D field in it. The AS always gets to choose = which things it supports for any given request. If the client wants to = support both =E2=80=9Credirect=E2=80=9D and =E2=80=9Cuser_code=E2=80=99 = modes AND has the ability to handle session fixation issues, it sends = the =E2=80=9Credirect=E2=80=9D, =E2=80=9Cuser_code=E2=80=99, and = =E2=80=9Ccallback=E2=80=9D fields in its interaction request.=20 > =20 >=20 >>=20 >> If you think that having a URI in addition to a handle makes sense, = how about you put that into your draft and see how it works? >=20 > Because I haven=E2=80=99t had an opportunity to implement it in this = way yet, and I=E2=80=99m not yet convinced the extra complexity is worth = it. I said it MIGHT make sense and it=E2=80=99s worth talking about, = which has been my public stance since before you proposed XAuth. = That=E2=80=99s still the case, and I=E2=80=99ve gone to length here on = the list (which is under the IETF IPR rules) to discuss it. Are you = suggesting that I need to prove this to you in a particular way, = instead? >=20 > No. I'm saying that stating it could be done is different than writing = it up. I would expect your draft to be the culmination of your = convictions. My draft is exactly that, and as you can see I=E2=80=99m open to having = more discussions beyond it. > =20 > As this is an individual draft, it should represent what I, = personally, think is the best approach. Part of my criteria for adding = things to my individual draft is making sure it at least makes some = amount of sense with real code. Your draft should likewise follow your = own convictions. >=20 > Agreed.=20 >=20 > =20 >=20 >>=20 >> For example:=20 >>=20 >> How is a transaction updated?=20 >> How are separate access tokens refreshed?=20 >> Refreshing an access token in XYZ returns a full transaction response = per Section 9.3 which refers to Section 8. >>=20 >>=20 >> By using URIs and methods, XAuth has an easy to understand API for = CRUD operations on Grants and Authorizations. >>=20 >> = +--------------+-----------+--------+-----------------------------+ >> | request | http verb | uri | response = | >> = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> | Create Grant | POST | GS URI | interaction, wait, or grant = | >> = +--------------+-----------+--------+-----------------------------+ >> | List Grants | GET | GS URI | grant list = | >> = +--------------+-----------+--------+-----------------------------+ >> | Verify Grant | PATCH | Grant | grant = | >> | | | URI | = | >> = +--------------+-----------+--------+-----------------------------+ >> | Read Grant | GET | Grant | wait, or grant = | >> | | | URI | = | >> = +--------------+-----------+--------+-----------------------------+ >> | Update Grant | PUT | Grant | interaction, wait, or grant = | >> | | | URI | = | >> = +--------------+-----------+--------+-----------------------------+ >> | Delete Grant | DELETE | Grant | success = | >> | | | URI | = | >> = +--------------+-----------+--------+-----------------------------+ >> | Read AuthZ | GET | AZ URI | authorization = | >> = +--------------+-----------+--------+-----------------------------+ >> | Update AuthZ | PUT | AZ URI | authorization = | >> = +--------------+-----------+--------+-----------------------------+ >> | Delete AuthZ | DELETE | AZ URI | success = | >> = +--------------+-----------+--------+-----------------------------+ >> | GS Options | OPTIONS | GS URI | metadata = | >> = +--------------+-----------+--------+-----------------------------+ >> | Grant | OPTIONS | Grant | metadata = | >> | Options | | URI | = | >> = +--------------+-----------+--------+-----------------------------+ >> | AuthZ | OPTIONS | AZ URI | metadata = | >> | Options | | | = | >> = +--------------+-----------+--------+-----------------------------+ >> =20 >=20 > While this looks good on paper, there are very pragmatic reasons that = many APIs have moved away from purely RESTful patterns over the last = decade, including limitations on what can be sent with GET and DELETE = requests, for example. I don=E2=80=99t think it=E2=80=99s as clean a win = as you=E2=80=99re presenting it, but I think it=E2=80=99s worth checking = out. >=20 > Agreed that RESTful does not work for everything. It does look like it = maps well here. I disagree that it maps well. I think this is an over-application of a = design pattern and the details will be problematic in implementation. > =20 >=20 >>=20 >>> =20 >>>=20 >>> The modes in XAuth are much more limiting, as the mixing of = different interaction methods is already something that we need to start = figuring out. Let=E2=80=99s say, for example, a client can do a = redirect, accept a CIBA-style ping, or do a direct app2app = communication. There=E2=80=99s a natural preference the client will have = here: if it can talk to another app directly, it=E2=80=99ll try that = first. If that doesn=E2=80=99t work, it can get a push notification = sent, and if all that fails, it can pop open a browser. If I have to = pick just one of those modes when I make the request, then the client = needs to make three different requests to the AS before I get anything = that works.=20 >>>=20 >>> Have you read the revised draft? As I noted above, I have added = negotiation. The Client can state all the modes it wants, the GS can = respond with the modes it will support, and the Client can offer the = User any modes returned from the GS. >>=20 >> Yes, did you read what I wrote? I think we=E2=80=99re talking past = each other. >>=20 >> This is not how XAuth is written currently. The Client can list all = of the modes it wants to use. The Server will return all the modes that = fit in its policy for the Grant Request. Why would the Client need to = make different requests? >>=20 >> per >>=20 >> = https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.2 = = =20 >>=20 >> The interaction object contains one or more interaction mode objects = per Section 5 >>=20 >> Three modes are defined here: >>=20 >> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-5 = >>=20 >> More modes may defined in extensions, or in this document. >=20 > Yes, this is an improvement, and I=E2=80=99m glad you=E2=80=99re = moving your thinking in this direction. However, it=E2=80=99s still not = as clear how things combine to solve different use cases, and it = conflates the means of getting the user TO the interaction page with the = way of getting them BACK from it. It=E2=80=99s these flexible = combinations that I think are important, and I don=E2=80=99t think XAuth = gets this quite right yet.=20 >=20 > I think how the user gets to and from the server is CRITICAL to the = server if it wants to protect itself from a session fixation attack. > See above where the client does not know what it can actually do that = the server will allow. It is critical that the server knows how to protect itself, yes. It=E2=80=99= s not critical that the way there and the way back are tightly bound to = each other in this way. I think that model is limiting. > =20 > >>=20 >> It is an OR in that if the client is using the type "oauth_scope", = they cannot have an "authorization_details" attribute, they can only = have "scope" >>=20 >> If the client is using the type "oauth_rich", the client MUST include = "authorization_details", and MAY include "scope" >> =20 >> I have updated the the doc to better capture that: >>=20 >> = https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.4 = >>=20 >> and example 2 now is of type "oauth_rich" >>=20 >> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.2 = >>=20 >=20 > It was not clear to me that both could be sent with that mode, so = thank you for updating that. But the client still has to choose one or = the other up front. Why not have a mechanism that it can send both at = all times? Why have a =E2=80=9Cmode=E2=80=9D type switch at all? XYZ = allows clients to make these combined requests with a single consistent = syntax. >=20 > And by completely externalizing this to OAuth 2, I would argue that we = lose an opportunity to more clearly define how resources are described = and used, and we inherit the same combination issues that are facing RAR = today. We can do better because we get to define the context. >=20 > This group can define a new syntax if it wants, and it will be = unencumbered by the OAuth 2 and RAR legacy if deployments that want to = use the OAuth 2 and RAR syntax can use them directly. Ie, there can be a = type "gnap" or some such. >=20 > >> I don't follow how this would work. Perhaps you could provide an = example in JSON? >=20 > One method is defining a new value inside the XYZ =E2=80=9Cclaims=E2=80=9D= request object that maps to a specific sub-schema: >=20 > claims: { > =E2=80=9Csubject=E2=80=9D: true, > =E2=80=9Cemail=E2=80=9D: true, > =E2=80=9Coidc=E2=80=9D: { > "userinfo": > { > "given_name": {"essential": true}, > "nickname": null, > "email": {"essential": true}, > "email_verified": {"essential": true}, > "picture": null, > "http://example.info/claims/groups = ": null > }, > "id_token": > { > "auth_time": {"essential": true}, > "acr": {"values": ["urn:mace:incommon:iap:silver"] } > } > } > } >=20 > That should look pretty familiar. Alternatively, this could be done = with a separate top-level request object field: >=20 >=20 > claims: { > =E2=80=9Csubject=E2=80=9D: true, > =E2=80=9Cemail=E2=80=9D: true > }, > =E2=80=9Coidc_claims_request=E2=80=9D: { > "userinfo": > { > "given_name": {"essential": true}, > "nickname": null, > "email": {"essential": true}, > "email_verified": {"essential": true}, > "picture": null, > "http://example.info/claims/groups = ": null > }, > "id_token": > { > "auth_time": {"essential": true}, > "acr": {"values": ["urn:mace:incommon:iap:silver"] } > } > } >=20 > In both cases the AS is going to need to knit them together into a = sensible request policy, especially since the OIDC claims query language = has overlapping implications to one particular resource, the UserInfo = endpoint. My contention wasn=E2=80=99t with your proposed solution, my = contention was you claiming that XYZ has a fixed schema and is therefore = limited in extensibility. >=20 > One of the objectives of this work is to have extension points. My = point was that XAuth had a clear extension point for adding schemas. How = to extend XYZ was not clear in your proposal. >=20 I am sorry that the extensibility of the protocol was not clear. It is = stated in each section that additional items can be added, and I have = stated repeatedly that it=E2=80=99s extensible and demonstrated how, = here on this list.=20 > I think the XAuth proposal is better than the two examples you = proposed. In your first example, the schema is a second class schema, = and in your second example, claims are spread across to top level = options. Both of these pollute other schemas. >=20 Not surprisingly, I disagree about the cleanliness of XAuth=E2=80=99s = proposed approach. The proposal here adds external schemas as extensions = instead of relying on them internally.=20 If anything, I think that the OpenID Foundation would be the ones to = define how to make an OIDC claims request using this protocol, not us, = since they own and control that query syntax and everything it implies. = We can provide a means of extension. I also think there=E2=80=99s value in defining a set of core = interoperable identity fields, which themselves could also be extended.=20= All of these mechanisms should be controlled by some combination of = registries and collision-resistant namespaces, which is the approach = I=E2=80=99ve taken for extensibility throughout XYZ. =E2=80=94 Justin= --Apple-Mail=_E550DFD4-59B0-4B17-A802-15F7C9BC8C6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 8, 2020, at 5:33 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Mon, Jun 8, 2020 at 1:02 PM Justin = Richer <jricher@mit.edu> wrote:

<snip>
A GS implementation can decide to = only return an authorization from doing a GET on the AZ URL. Returning = only an AZ URL is an option in XAuth. Similarly, we could do the same = for a Grant URI. 

And that=E2=80=99s a lot = of complex code paths for both the GS and client to deal with. With more = ways that it might happen, the client has to be prepared for any of them = =E2=80=94 and get them all = right. 

I don't see it being complex. The data = either moves by reference or by value. Both parties will have to enable = support by reference. Passing by value is an optimization so that the = client does not have to make an additional = call.

=E2=80=9CBoth parties will have to enable=E2=80=9D = is where the complexity comes into play. It=E2=80=99s putting a = requirement on the client to anticipate several different ways to get = the same information.


 <snip>

 

Using a different URI, = optionally, isn=E2=80=99t the problem, and that could easily be added to = the. Removal of the separate handle is the problem I have with the XAuth = approach.

In XAuth, the Grant URI is the GS = URI + TBD + handle

Given we have asymmetric crypto as = a requirement, it is unclear what having two pieces of random = signal provide.

Asymmetric crypto is an = implementation requirement in both the input drafts but it isn=E2=80=99t = a requirement in the charter, and there are likely symmetric use cases = and key proofing mechanisms that are going to be desirable for a lot of = people.

 

 

Additionally, I find = XAuth=E2=80=99s restrictions on the structure of the Grant URI = potentially problematic, namely that it has to start with the server=E2=80= =99s URL. This will lead to deployments needing to bend their setups = with proxies or redirectors to make things fit, which you yourself have = said is going to be an issue for things like supporting a short redirect = URL vs. a long redirect URL. Your complaint there was one of latency and = complexity, why does that not apply here? But most fundamentally, I do = not see what value this restriction brings to the system. If the value = is coming back from the GS endpoint, and the client is getting all of = its pointers from there, what=E2=80=99s the point of dictating how that = has to look?

Requiring the Grant URI to start with = the GS URI is open to discussion. It is not clear to me why a deployment = would need to have a redirector. Large scale deployments I have worked = on have a router / proxy that routes requests to internal services. = Having all the URIs start with the GS URI enables all GNAP operations to = be routed in the same place.

You still haven=E2=80=99t = addressed why you think that this is a reasonable requirement or = assumption here but not when dealing with long/short URLs for QR codes. = What is the difference?

Short URLs generally use a short host = name as well as a short path. 

Most REST interfaces have the pattern I = am proposing. A mental model many developers are familiar = with. 

This is assuming a lot on the part of = the GS implementation, still, and all of my arguments = stand. 


That is not = entirely correct. A pre-registered client can still pass its key by = value, and a dynamic client can still use a = (dynamically-acquired) handle. In all cases, the client is identifying = itself by its key. The difference is how the server looks up that key = =E2=80=94 it=E2=80=99s either from the handle, or it=E2=80=99s from the = key value = itself. 

I don't understand this. 

How is the Client authenticating that = it is a specific pre-registered = client?

The client is identified by its = key. There is no external client identifier. I think you=E2=80=99re = confused because you=E2=80=99re still thinking in terms of OAuth 2=E2=80=99= s client ID based model and I am trying to move us past that. It took me = time to realize that we really can let it go, so hopefully this is = helpful in explaining why.

When a = credential is cryptographically random enough to be unique, it can be = used as its own identifier, particularly when you don=E2=80=99t need to = identify the entity outside of the context that it can present and prove = its credential. To stretch a metaphor, passwords don=E2=80=99t always = need usernames. This is, after all, the driving design pattern behind = OAuth access tokens. An access token doesn=E2=80=99t have a = =E2=80=9Cusername=E2=80=9D portion to it, even though it would have been = trivial to require the client to send its client ID alongside the access = token. Why does that work? Because our model of what the RS does with = the access token is built around it answering the questions: is this = token valid and does it allow what=E2=80=99s being requested? If the RS = needs to know which client was issued the token, it can discover that = information without being told separately from the token -- perhaps = it=E2=80=99s in the token itself or it=E2=80=99s in an introspection = response. And in a lot of cases, the RS doesn=E2=80=99t care about the = client software, it just wants to know if the token=E2=80=99s any good. = Even in constrained tokens such as MTLS, PoP, and DPoP, we aren=E2=80=99t = really authenticating the client at the RS so much as making sure the = right key is presented alongside the right token. 

XYZ takes that same approach with the client = talking to the AS and uses the credential (key) to identify the client = as well as authenticate and protect the request. We can=E2=80=99t just = say =E2=80=9COAuth 2 had client IDs and people are used to it so it must = be good and we have to keep using it=E2=80=9D. We need to ask WHY OAuth = 2 needs client IDs and if that still makes sense. I argue that it = doesn=E2=80=99t make sense anymore and we need to step back and look at = a better model. OAuth 2 needs a client ID because it gets passed in the = front channel and the client=E2=80=99s credentials can=E2=80=99t be used = there. The access token doesn=E2=80=99t need an equivalent because = it=E2=80=99s passed in the back channel and can be used directly. Now = that the client no longer needs to be identified, but not authenticated, = through untrusted third parties (such as the browser), we don=E2=80=99t = need to have a separate identifier as part of the protocol. With an = intent-based protocol, that starts in the back channel, you don=E2=80=99t = need a client identifier anymore. Once the AS finds that key, the AS can = then figure out what policies, rights, and restrictions are attached to = that key. In many implementations, there=E2=80=99s going to be some kind = of =E2=80=9Cregistered client=E2=80=9D object in a database somewhere = that drives those policies. That=E2=80=99s the classical OAuth model, = and it works in many cases. But in other cases, the key is going to just = be a value used to protect the request chain (and possibly the token = itself), and the policy is going to be built up by other things like a = device posture or signature on the calling software or verified user = information. It=E2=80=99s not just about client authentication, even = though it can be used for it. DPoP, PKCE, and DynReg have shown us the = value in dynamic systems, in different ways. 

On top of that, PAR is showing us that a lot of = the constraints that we have in OAuth 2 don=E2=80=99t really apply = anymore. For instance, Redirect URI restrictions can be relaxed because = now you CAN identify and authenticate the software sending it, which = isn=E2=80=99t true with a front-channel-first approach. All of the = things that are required in OAuth 2 start to become redundant, and it = leads to things like requiring that =E2=80=9Cclient_id=E2=80=9D still = always be passed in the front channel even though the information could = be looked up from an internal request_uri reference using PAR and JAR = together.

That=E2=80=99s why a key = handle isn=E2=80=99t exactly the same as a client ID and I did not call = it a client ID in the XYZ protocol. It=E2=80=99s a shortcut to refer to = the key material for certain optimized cases, but ultimately it=E2=80=99s = pointing to a key. This has an interesting and beneficial side effect = =E2=80=94 if you HAVE a client ID as part of your internal data model, = it can FUNCTION as a key handle because it=E2=80=99s a unique value the = AS can use to look up key information. It=E2=80=99s not = =E2=80=9Cauthenticating the client=E2=80=9D, it=E2=80=99s pointing to a = key which in turn identifies and authenticates the software making the = call. The fact that it=E2=80=99s a =E2=80=9Cclient ID=E2=80=9D is an = artifact of the implementation, which in this case has an OAuth 2 legacy = to work with. 

If we=E2=80=99re = going to move past the constraints of OAuth 2 we need to stop thinking = so strictly in its terms and models. There are better ways to approach = this now and client IDs are not required by this protocol = model.

 
<snip>
 

5) Interaction Capabilities vs Modes

In XYZ, the capabilities are = expressed by the client, and the GS states which capabilities it will = accept. This can make it difficult for the GS to enforce the interaction = choices as the client can mix and match which capabilities are returned. = For example, a GS may not want to support a redirect without a callback = to protect itself from session fixation attacks. In XAuth, the = interaction modes provide clarity on the mode of interaction and the = security properties. For example the GS may support both user_code and = redirect modes, but not the indirect mode which is subject to session = fixation attacks.


If the GS doesn=E2=80=99t want to = accept a redirect without a callback, it can because the request will = have a redirect, but not a callback, and it can reject the request. What = makes you believe that this is not detectable or not possible in = XYZ? 

I did not say it could not be done, I'm = saying it is more difficult in XYZ than in = XAuth

Can you explain to me how it=E2=80=99s = more difficult in XYZ? I have explained how it can be done and I am = failing to see why you think it=E2=80=99s = harder.

Having both a handle and a URI seems = more complicated than just a = URI.

You=E2=80=99re conflating things: This = is a separate discussion. Here we are talking about how it=E2=80=99s = more difficult for an AS to determine the presence or absence of the = =E2=80=9Ccallback=E2=80=9D field vs. detecting the presence or absence = of the =E2=80=9Cdirect=E2=80=9D and/or =E2=80=9Cindirect=E2=80=9D = fields.

My bad. I got confused which topic we = were on.

In = XAuth, if the server wants to protect itself from a session fixation = attack in a given request, and it wants to support both "redirect" and = "user_code" modes, 
the server will return = only those two modes and not "indirect". The 

In = XAuth, if the server wants to protect itself from a session fixation = attack in a given request, and it wants to support both "redirect" and = "user_code" modes, 
the server MUST return callback, redirect, and = user_code. The client does not know that the "indirect" mode is not = supported, and may try that.


In XYZ, if the server wants to protect against a = session fixation attack, it will reject a request that doesn=E2=80=99t = have a =E2=80=9Ccallback=E2=80=9D field in it. The AS always gets to = choose which things it supports for any given request. If the client = wants to support both =E2=80=9Credirect=E2=80=9D and =E2=80=9Cuser_code=E2= =80=99 modes AND has the ability to handle session fixation issues, it = sends the =E2=80=9Credirect=E2=80=9D, =E2=80=9Cuser_code=E2=80=99, and = =E2=80=9Ccallback=E2=80=9D fields in its interaction = request. 

 


If you think that having a URI in addition to a handle makes = sense, how about you put that into your draft and see how it = works?

Because I haven=E2=80=99t had an = opportunity to implement it in this way yet, and I=E2=80=99m not yet = convinced the extra complexity is worth it. I said it MIGHT make sense = and it=E2=80=99s worth talking about, which has been my public stance = since before you proposed XAuth. That=E2=80=99s still the case, and = I=E2=80=99ve gone to length here on the list (which is under the IETF = IPR rules) to discuss it. Are you suggesting that I need to prove this = to you in a particular way, instead?

No. I'm saying that = stating it could be done is different than writing it up. I would expect = your draft to be the culmination of your = convictions.

My draft is exactly that, and as you can see I=E2=80= =99m open to having more discussions beyond it.

 
As this is an individual draft, = it should represent what I, personally, think is the best approach. Part = of my criteria for adding things to my individual draft is making sure = it at least makes some amount of sense with real code. Your draft should = likewise follow your own convictions.

Agreed. 

 


For example: 

How is a transaction = updated? 
How are separate access tokens = refreshed? 
Refreshing an access token in XYZ = returns a full transaction response per Section 9.3 which refers to = Section 8.


By using URIs and = methods, XAuth has an easy to understand API for CRUD operations on = Grants and Authorizations.

    =
+--------------+-----------+--------+-----------------------------+
    | request      | http verb | uri    | response                    |
    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
    | Create Grant | POST      | GS URI | interaction, wait, or grant |
    +--------------+-----------+--------+-----------------------------+
    | List Grants  | GET       | GS URI | grant list                  |
    +--------------+-----------+--------+-----------------------------+
    | Verify Grant | PATCH     | Grant  | grant                       |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read Grant   | GET       | Grant  | wait, or grant              |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Update Grant | PUT       | Grant  | interaction, wait, or grant |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Delete Grant | DELETE    | Grant  | success                     |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read AuthZ   | GET       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Update AuthZ | PUT       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Delete AuthZ | DELETE    | AZ URI | success                     |
    +--------------+-----------+--------+-----------------------------+
    | GS Options   | OPTIONS   | GS URI | metadata                    |
    +--------------+-----------+--------+-----------------------------+
    | Grant        | OPTIONS   | Grant  | metadata                    |
    | Options      |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | AuthZ        | OPTIONS   | AZ URI | metadata                    |
    | Options      |           |        |                             |
    =
+--------------+-----------+--------+-----------------------------+
<= /div>
 

While this looks good on = paper, there are very pragmatic reasons that many APIs have moved away = from purely RESTful patterns over the last decade, including limitations = on what can be sent with GET and DELETE requests, for example. I don=E2=80= =99t think it=E2=80=99s as clean a win as you=E2=80=99re presenting it, = but I think it=E2=80=99s worth checking = out.

Agreed that RESTful does not work for everything. It does = look like it maps well = here.

I= disagree that it maps well. I think this is an over-application of a = design pattern and the details will be problematic in = implementation.

 


 

The modes in XAuth are = much more limiting, as the mixing of different interaction methods is = already something that we need to start figuring out. Let=E2=80=99s say, = for example, a client can do a redirect, accept a CIBA-style ping, or do = a direct app2app communication. There=E2=80=99s a natural preference the = client will have here: if it can talk to another app directly, it=E2=80=99= ll try that first. If that doesn=E2=80=99t work, it can get a push = notification sent, and if all that fails, it can pop open a browser. = If I have to = pick just one of those modes when I make the request, then the client = needs to make three different requests to the AS before I get anything = that works. 
Have you read the revised draft? As I = noted above, I have added negotiation. The Client can state all the = modes it wants, the GS can respond with the modes it will support, and = the Client can offer the User any modes returned from the = GS.

Yes, did you read what I wrote? I think = we=E2=80=99re talking past each = other.

This is not = how XAuth is written currently. The Client can list all of the modes it = wants to use. The Server will return all the modes that fit in its = policy for the Grant Request. Why would the Client need to make = different requests?

per

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-3.4.2  

The interaction object contains one or more interaction mode = objects per Section 5

Three modes are defined here:

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-5

More modes may defined in extensions, or in this = document.

Yes, this is an improvement, and I=E2=80=99= m glad you=E2=80=99re moving your thinking in this direction. However, = it=E2=80=99s still not as clear how things combine to solve different = use cases, and it conflates the means of getting the user TO the = interaction page with the way of getting them BACK from it. It=E2=80=99s = these flexible combinations that I think are important, and I don=E2=80=99= t think XAuth gets this quite right = yet. 

I think how the user gets to and from = the server is CRITICAL to the server if it wants to protect itself from = a session fixation attack.
See above where the = client does not know what it can actually do that the server will = allow.

It is critical that the server knows how to = protect itself, yes. It=E2=80=99s not critical that the way there and = the way back are tightly bound to each other in this way. I think that = model is limiting.

 
<snip>

It is an OR in that if the client is using the type = "oauth_scope", they cannot have an "authorization_details" attribute, = they can only have "scope"

If the client is using the type "oauth_rich", the client MUST = include "authorization_details", and MAY include "scope"
 
I have updated the the doc to = better capture that:

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-3.4.4

and example 2 now is of type "oauth_rich"

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-3.2


It was not clear to me that both could = be sent with that mode, so thank you for updating that. But the client = still has to choose one or the other up front. Why not have a mechanism = that it can send both at all times? Why have a =E2=80=9Cmode=E2=80=9D = type switch at all? XYZ allows clients to make these combined requests = with a single consistent syntax.

And by completely externalizing this to = OAuth 2, I would argue that we lose an opportunity to more clearly = define how resources are described and used, and we inherit the same = combination issues that are facing RAR today. We can do better because = we get to define the context.

This group can define a = new syntax if it wants, and it will be unencumbered by the OAuth 2 and = RAR legacy if deployments that want to use the OAuth 2 and RAR syntax = can use them directly. Ie, there can be a type "gnap" or some = such.

 <snip>
I don't follow how this would = work. Perhaps you could provide an example in = JSON?

One method is defining a new value = inside the XYZ =E2=80=9Cclaims=E2=80=9D request object that maps to a = specific sub-schema:

claims: {
  =  =E2=80=9Csubject=E2=80=9D: true,
   =E2=80=9Cemail=E2=80=9D: true,
   =E2=80=9Coidc=E2=80=9D: = {
      =  "userinfo":
  =       {
  =        "given_name": {"essential": = true},
      =    "nickname": null,
         "email": {"essential": = true},
      =    "email_verified": {"essential": true},
         "picture": = null,
      =    "http://example.info/claims/groups": = null
      =   },
    =    "id_token":
 =       {
  =        "auth_time": {"essential": = true},
      =    "acr": {"values": ["urn:mace:incommon:iap:silver"] = }
        = }
      = }
}

That should look pretty familiar. = Alternatively, this could be done with a separate top-level request = object field:


claims: {
   =E2=80=9Csubject=E2=80=9D: true,
   =E2=80=9Cemail=E2=80=9D: = true
},
=E2=80=9Coidc_claims_request=E2=80=9D: {
       "userinfo":
        {
  =        "given_name": {"essential": true},
         "nickname": null,
         "email": {"essential": = true},
        =  "email_verified": {"essential": true},
  =        "picture": null,
  =        "http://example.info/claims/groups": = null
        },
       "id_token":
        {
  =        "auth_time": {"essential": true},
         "acr": {"values": = ["urn:mace:incommon:iap:silver"] }
    =     }
}

In both cases the AS is going to need to knit them together = into a sensible request policy, especially since the OIDC claims query = language has overlapping implications to one particular resource, the = UserInfo endpoint. My contention wasn=E2=80=99t with your proposed = solution, my contention was you claiming that XYZ has a fixed schema and = is therefore limited in = extensibility.

One of the objectives of this work is = to have extension points. My point was that XAuth had a clear extension = point for adding schemas. How to extend XYZ was not clear in your = proposal.


I am sorry that the extensibility of the protocol = was not clear. It is stated in each section that additional items can be = added, and I have stated repeatedly that it=E2=80=99s extensible and = demonstrated how, here on this list. 

I think the XAuth proposal is = better than the two examples you proposed. In your first example, the = schema is a second class schema, and in your second example, claims are = spread across to top level options. Both of these pollute other = schemas.


Not surprisingly, I disagree about the cleanliness = of XAuth=E2=80=99s proposed approach. The proposal here adds external = schemas as extensions instead of relying on them = internally. 

If anything, I = think that the OpenID Foundation would be the ones to define how to make = an OIDC claims request using this protocol, not us, since they own and = control that query syntax and everything it implies. We can provide a = means of extension.

I also think = there=E2=80=99s value in defining a set of core interoperable identity = fields, which themselves could also be extended. 

All of these mechanisms should be controlled by = some combination of registries and collision-resistant namespaces, which = is the approach I=E2=80=99ve taken for extensibility throughout = XYZ.

 =E2=80=94 = Justin
= --Apple-Mail=_E550DFD4-59B0-4B17-A802-15F7C9BC8C6A-- From nobody Tue Jun 9 09:38:39 2020 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 852B43A097E for ; Tue, 9 Jun 2020 09:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Qm0TIh14GS2E for ; Tue, 9 Jun 2020 09:38:34 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 493EB3A08AD for ; Tue, 9 Jun 2020 09:38:34 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id n70so4667863ota.5 for ; Tue, 09 Jun 2020 09:38:34 -0700 (PDT) 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=ODSE0AElIypF8N4bJXj0s6YEUB0wIkhqzx4w7nS51Pk=; b=F6+P2kgnxuBrgs3k+bqk9OVn2g0mGyLjJS1b/xUilpjeln41Zkle/aa8fCTes75Xaw mNi4RQjzPCT/0g6HAVvtKIzdOIdu9e6YpjZkhCxob5isXIBPntAfTvetBTQkKSEQyKi7 scDbCjW2/ysn6dcOhAdxgiPvZQHfpUyPiEzLfGZUKEhB0wbdcPXqpoiXtvzAXsVTV8E3 /D6n6BsEVBffrhAgNfch2XzLRyIcGTXcEK8ENOzSCSL8/MVOW/rDTBUxz574EsN4PRD7 rhVGYve6HXCL0hmXVN7n+iF+VdGyXhPAUtth33oON7gAQqMtblkjZYZRB3tfjgCqfsVy FDAQ== 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=ODSE0AElIypF8N4bJXj0s6YEUB0wIkhqzx4w7nS51Pk=; b=SBtr4674hVxGPDAaveIgDA6tA9t9GcHZfl/8U7WyZjT+5B9Nf8d5WGIpAvDUuTbM6j Zn2Or1Tk8kdLZU18wzwGGWOI/k+QOTEcAxA37s64R+KY+y9qbEUpYAhtGtc/O3S2qDUF jzidpi+7FuPHyGffdlHMKGXZC0W/mIGVFjAcL3aEggc+0Ca3G/Oml6OcsdnaxN6Mmz2l UJhU5YG7fA7QStlBfVSgmnLQ9Y/WqD8bnSkwnH3ii7Mo3AejlMCdkl3RYdyYJKaMryHz nLko+v6PANFC2fhIycbJWUQfaAbrLsaU1ohSDghF9w32KcTqqmL8RJj5mKEANi7aFTm6 QVtQ== X-Gm-Message-State: AOAM532IoadVsqu7Sy0uFgNutdYIqBrOrW+Lz401Tjn8NP/JoS7xFXQ1 hdE+mcL/xcLzzFBLptuF9+gQf4HaoHZm/WgRMUU43foota8= X-Google-Smtp-Source: ABdhPJwsU8D29IImUiWJTt77xY++2dg9yAmMPv5vMk7GXtZ0/GTUtMWpda3pQT7Y9HzNgxtWt5r0gJEnkwKbBSjZzxw= X-Received: by 2002:a05:6830:3151:: with SMTP id c17mr23422005ots.143.1591720713117; Tue, 09 Jun 2020 09:38:33 -0700 (PDT) MIME-Version: 1.0 From: Tom Jones Date: Tue, 9 Jun 2020 09:38:21 -0700 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000afe66b05a7a95b4c" Archived-At: Subject: [Txauth] The client is identified by its key. 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, 09 Jun 2020 16:38:38 -0000 --000000000000afe66b05a7a95b4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *This needs to be its own thread. I see the same trend in OpenID for self-issued subject identification. I cannot imagine how key roll-over could possibly work without major disruption to ongoing activity. Someone must show that key rollover in a fully functioning system is possible before it is even considered.* *from justin* *The client is identified by its key.* There is no external client identifier. I think you=E2=80=99re confused because you=E2=80=99re still th= inking in terms of OAuth 2=E2=80=99s client ID based model and I am trying to move us past = that. It took me time to realize that we really can let it go, so hopefully this is helpful in explaining why. When a credential is cryptographically random enough to be unique, it can be used as its own identifier, particularly when you don=E2=80=99t need to = identify the entity outside of the context that it can present and prove its credential. To stretch a metaphor, passwords don=E2=80=99t always need user= names. This is, after all, the driving design pattern behind OAuth access tokens. An access token doesn=E2=80=99t have a =E2=80=9Cusername=E2=80=9D portion t= o it, even though it would have been trivial to require the client to send its client ID alongside the access token. Why does that work? Because our model of what the RS does with the access token is built around it answering the questions: is this token valid and does it allow what=E2=80=99s being reque= sted? If the RS needs to know which client was issued the token, it can discover that information without being told separately from the token -- perhaps it=E2=80=99s in the token itself or it=E2=80=99s in an introspection respon= se. And in a lot of cases, the RS doesn=E2=80=99t care about the client software, it just wa= nts to know if the token=E2=80=99s any good. Even in constrained tokens such as MT= LS, PoP, and DPoP, we aren=E2=80=99t really authenticating the client at the RS so m= uch as making sure the right key is presented alongside the right token. XYZ takes that same approach with the client talking to the AS and uses the credential (key) to identify the client as well as authenticate and protect the request. We can=E2=80=99t just say =E2=80=9COAuth 2 had client IDs and = people are used to it so it must be good and we have to keep using it=E2=80=9D. We need to = ask WHY OAuth 2 needs client IDs and if that still makes sense. I argue that it doesn=E2=80=99t make sense anymore and we need to step back and look at a b= etter model. OAuth 2 needs a client ID because it gets passed in the front channel and the client=E2=80=99s credentials can=E2=80=99t be used there. T= he access token doesn=E2=80=99t need an equivalent because it=E2=80=99s passed in the back = channel and can be used directly. Now that the client no longer needs to be identified, but not authenticated, through untrusted third parties (such as the browser), we don=E2=80=99t need to have a separate identifier as part of the protocol= . With an intent-based protocol, that starts in the back channel, you don=E2=80=99= t need a client identifier anymore. Once the AS finds that key, the AS can then figure out what policies, rights, and restrictions are attached to that key. In many implementations, there=E2=80=99s going to be some kind of =E2= =80=9Cregistered client=E2=80=9D object in a database somewhere that drives those policies. = That=E2=80=99s the classical OAuth model, and it works in many cases. But in other cases, the key is going to just be a value used to protect the request chain (and possibly the token itself), and the policy is going to be built up by other things like a device posture or signature on the calling software or verified user information. It=E2=80=99s not just about client authenticatio= n, even though it can be used for it. DPoP, PKCE, and DynReg have shown us the value in dynamic systems, in different ways. On top of that, PAR is showing us that a lot of the constraints that we have in OAuth 2 don=E2=80=99t really apply anymore. For instance, Redirect = URI restrictions can be relaxed because now you CAN identify and authenticate the software sending it, which isn=E2=80=99t true with a front-channel-firs= t approach. All of the things that are required in OAuth 2 start to become redundant, and it leads to things like requiring that =E2=80=9Cclient_id=E2= =80=9D still always be passed in the front channel even though the information could be looked up from an internal request_uri reference using PAR and JAR together= . That=E2=80=99s why a key handle isn=E2=80=99t exactly the same as a client = ID and I did not call it a client ID in the XYZ protocol. It=E2=80=99s a shortcut to refer t= o the key material for certain optimized cases, but ultimately it=E2=80=99s point= ing to a key. This has an interesting and beneficial side effect =E2=80=94 if you HA= VE a client ID as part of your internal data model, it can FUNCTION as a key handle because it=E2=80=99s a unique value the AS can use to look up key information. It=E2=80=99s not =E2=80=9Cauthenticating the client=E2=80=9D, = it=E2=80=99s pointing to a key which in turn identifies and authenticates the software making the call. The fact that it=E2=80=99s a =E2=80=9Cclient ID=E2=80=9D is an artifact of = the implementation, which in this case has an OAuth 2 legacy to work with. If we=E2=80=99re going to move past the constraints of OAuth 2 we need to s= top thinking so strictly in its terms and models. There are better ways to approach this now and client IDs are not required by this protocol model. Peace ..tom --000000000000afe66b05a7a95b4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This needs=C2=A0to be its own thread. I see the sa= me trend in OpenID for self-issued subject=C2=A0identification. I cannot im= agine how key roll-over could possibly work without major disruption to ong= oing activity.=C2=A0 Someone must show that key rollover in a fully functio= ning system is possible before it is even considered.

=
from justin

The cl= ient is identified by its key.=C2=A0There is no external client identif= ier. I think you=E2=80=99re confused because you=E2=80=99re still thinking = in terms of OAuth 2=E2=80=99s client ID based model and I am trying to move= us past that. It took me time to realize that we really can let it go, so = hopefully this is helpful in explaining why.

When = a credential is cryptographically random enough to be unique, it can be use= d as its own identifier, particularly when you don=E2=80=99t need to identi= fy the entity outside of the context that it can present and prove its cred= ential. To stretch a metaphor, passwords don=E2=80=99t always need username= s. This is, after all, the driving design pattern behind OAuth access token= s. An access token doesn=E2=80=99t have a =E2=80=9Cusername=E2=80=9D portio= n to it, even though it would have been trivial to require the client to se= nd its client ID alongside the access token. Why does that work? Because ou= r model of what the RS does with the access token is built around it answer= ing the questions: is this token valid and does it allow what=E2=80=99s bei= ng requested? If the RS needs to know which client was issued the token, it= can discover that information without being told separately from the token= -- perhaps it=E2=80=99s in the token itself or it=E2=80=99s in an introspe= ction response. And in a lot of cases, the RS doesn=E2=80=99t care about th= e client software, it just wants to know if the token=E2=80=99s any good. E= ven in constrained tokens such as MTLS, PoP, and DPoP, we aren=E2=80=99t re= ally authenticating the client at the RS so much as making sure the right k= ey is presented alongside the right token.=C2=A0

X= YZ takes that same approach with the client talking to the AS and uses the = credential (key) to identify the client as well as authenticate and protect= the request. We can=E2=80=99t just say =E2=80=9COAuth 2 had client IDs and= people are used to it so it must be good and we have to keep using it=E2= =80=9D. We need to ask WHY OAuth 2 needs client IDs and if that still makes= sense. I argue that it doesn=E2=80=99t make sense anymore and we need to s= tep back and look at a better model. OAuth 2 needs a client ID because it g= ets passed in the front channel and the client=E2=80=99s credentials can=E2= =80=99t be used there. The access token doesn=E2=80=99t need an equivalent = because it=E2=80=99s passed in the back channel and can be used directly. N= ow that the client no longer needs to be identified, but not authenticated,= through untrusted third parties (such as the browser), we don=E2=80=99t ne= ed to have a separate identifier as part of the protocol. With an intent-ba= sed protocol, that starts in the back channel, you don=E2=80=99t need a cli= ent identifier anymore. Once the AS finds that key, the AS can then figure = out what policies, rights, and restrictions are attached to that key. In ma= ny implementations, there=E2=80=99s going to be some kind of =E2=80=9Cregis= tered client=E2=80=9D object in a database somewhere that drives those poli= cies. That=E2=80=99s the classical OAuth model, and it works in many cases.= But in other cases, the key is going to just be a value used to protect th= e request chain (and possibly the token itself), and the policy is going to= be built up by other things like a device posture or signature on the call= ing software or verified user information. It=E2=80=99s not just about clie= nt authentication, even though it can be used for it. DPoP, PKCE, and DynRe= g have shown us the value in dynamic systems, in different ways.=C2=A0

On top of that, PAR is showing us that a lot of the co= nstraints that we have in OAuth 2 don=E2=80=99t really apply anymore. For i= nstance, Redirect URI restrictions can be relaxed because now you CAN ident= ify and authenticate the software sending it, which isn=E2=80=99t true with= a front-channel-first approach. All of the things that are required in OAu= th 2 start to become redundant, and it leads to things like requiring that = =E2=80=9Cclient_id=E2=80=9D still always be passed in the front channel eve= n though the information could be looked up from an internal request_uri re= ference using PAR and JAR together.

That=E2=80=99s= why a key handle isn=E2=80=99t exactly the same as a client ID and I did n= ot call it a client ID in the XYZ protocol. It=E2=80=99s a shortcut to refe= r to the key material for certain optimized cases, but ultimately it=E2=80= =99s pointing to a key. This has an interesting and beneficial side effect = =E2=80=94 if you HAVE a client ID as part of your internal data model, it c= an FUNCTION as a key handle because it=E2=80=99s a unique value the AS can = use to look up key information. It=E2=80=99s not =E2=80=9Cauthenticating th= e client=E2=80=9D, it=E2=80=99s pointing to a key which in turn identifies = and authenticates the software making the call. The fact that it=E2=80=99s = a =E2=80=9Cclient ID=E2=80=9D is an artifact of the implementation, which i= n this case has an OAuth 2 legacy to work with.=C2=A0

<= div>If we=E2=80=99re going to move past the constraints of OAuth 2 we need = to stop thinking so strictly in its terms and models. There are better ways= to approach this now and client IDs are not required by this protocol mode= l.
Peace ..tom
--000000000000afe66b05a7a95b4c-- From nobody Tue Jun 9 10:38:06 2020 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 CF8AA3A0B26 for ; Tue, 9 Jun 2020 10:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 zcI04xFAW6rY for ; Tue, 9 Jun 2020 10:38:02 -0700 (PDT) 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 8F5BD3A0988 for ; Tue, 9 Jun 2020 10:38:02 -0700 (PDT) Received: from [192.168.1.14] (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 059HbwER004839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 9 Jun 2020 13:37:59 -0400 From: Justin Richer Message-Id: <41E7211B-6599-463F-896C-A88EFF904921@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_55A6AAEB-414B-497E-94C2-3FF13840D4B5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 9 Jun 2020 13:37:58 -0400 In-Reply-To: Cc: txauth@ietf.org To: Tom Jones References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] The client is identified by its key. 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, 09 Jun 2020 17:38:05 -0000 --Apple-Mail=_55A6AAEB-414B-497E-94C2-3FF13840D4B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Key rollover is really important. When I say that the client is = identified by the key, I do not mean that a client is DEFINED by its = key. And with that, it is important to know that it=E2=80=99s the AS = that decides what any particular key represents at any time. So long as = the AS knows which key to map to which set of policies that govern the = actions of a client, everything is fine. That mapping can change and the = AS can keep the new key tied to the same internal entity. The AS could = even have multiple keys tied to that entity, and accept any of those = keys during a request.=20 It=E2=80=99s exactly the same as changing a deployed OAuth 2 client=E2=80=99= s client_secret today. You change the secret on the AS and change it in = the client and it just keeps working like you=E2=80=99d expect.=20 Oh, but you might be thinking =E2=80=94 there we have the client ID to = tie it all together! Don=E2=80=99t we need that! Well, we actually = don=E2=80=99t. The AS can keep whatever internal identifier it wants to = during a client rollover. The protocol, and importantly the client = itself, need never be aware of that identifier. It might still be there = but you are no longer forced to expose it.=20 Removing an external and explicit client identifier enables this kind of = deployment behavior, it doesn=E2=80=99t hamper it. =E2=80=94 Justin > On Jun 9, 2020, at 12:38 PM, Tom Jones = wrote: >=20 > This needs to be its own thread. I see the same trend in OpenID for = self-issued subject identification. I cannot imagine how key roll-over = could possibly work without major disruption to ongoing activity. = Someone must show that key rollover in a fully functioning system is = possible before it is even considered. >=20 > from justin >=20 > The client is identified by its key. There is no external client = identifier. I think you=E2=80=99re confused because you=E2=80=99re still = thinking in terms of OAuth 2=E2=80=99s client ID based model and I am = trying to move us past that. It took me time to realize that we really = can let it go, so hopefully this is helpful in explaining why. >=20 > When a credential is cryptographically random enough to be unique, it = can be used as its own identifier, particularly when you don=E2=80=99t = need to identify the entity outside of the context that it can present = and prove its credential. To stretch a metaphor, passwords don=E2=80=99t = always need usernames. This is, after all, the driving design pattern = behind OAuth access tokens. An access token doesn=E2=80=99t have a = =E2=80=9Cusername=E2=80=9D portion to it, even though it would have been = trivial to require the client to send its client ID alongside the access = token. Why does that work? Because our model of what the RS does with = the access token is built around it answering the questions: is this = token valid and does it allow what=E2=80=99s being requested? If the RS = needs to know which client was issued the token, it can discover that = information without being told separately from the token -- perhaps = it=E2=80=99s in the token itself or it=E2=80=99s in an introspection = response. And in a lot of cases, the RS doesn=E2=80=99t care about the = client software, it just wants to know if the token=E2=80=99s any good. = Even in constrained tokens such as MTLS, PoP, and DPoP, we aren=E2=80=99t = really authenticating the client at the RS so much as making sure the = right key is presented alongside the right token.=20 >=20 > XYZ takes that same approach with the client talking to the AS and = uses the credential (key) to identify the client as well as authenticate = and protect the request. We can=E2=80=99t just say =E2=80=9COAuth 2 had = client IDs and people are used to it so it must be good and we have to = keep using it=E2=80=9D. We need to ask WHY OAuth 2 needs client IDs and = if that still makes sense. I argue that it doesn=E2=80=99t make sense = anymore and we need to step back and look at a better model. OAuth 2 = needs a client ID because it gets passed in the front channel and the = client=E2=80=99s credentials can=E2=80=99t be used there. The access = token doesn=E2=80=99t need an equivalent because it=E2=80=99s passed in = the back channel and can be used directly. Now that the client no longer = needs to be identified, but not authenticated, through untrusted third = parties (such as the browser), we don=E2=80=99t need to have a separate = identifier as part of the protocol. With an intent-based protocol, that = starts in the back channel, you don=E2=80=99t need a client identifier = anymore. Once the AS finds that key, the AS can then figure out what = policies, rights, and restrictions are attached to that key. In many = implementations, there=E2=80=99s going to be some kind of =E2=80=9Cregiste= red client=E2=80=9D object in a database somewhere that drives those = policies. That=E2=80=99s the classical OAuth model, and it works in many = cases. But in other cases, the key is going to just be a value used to = protect the request chain (and possibly the token itself), and the = policy is going to be built up by other things like a device posture or = signature on the calling software or verified user information. It=E2=80=99= s not just about client authentication, even though it can be used for = it. DPoP, PKCE, and DynReg have shown us the value in dynamic systems, = in different ways.=20 >=20 > On top of that, PAR is showing us that a lot of the constraints that = we have in OAuth 2 don=E2=80=99t really apply anymore. For instance, = Redirect URI restrictions can be relaxed because now you CAN identify = and authenticate the software sending it, which isn=E2=80=99t true with = a front-channel-first approach. All of the things that are required in = OAuth 2 start to become redundant, and it leads to things like requiring = that =E2=80=9Cclient_id=E2=80=9D still always be passed in the front = channel even though the information could be looked up from an internal = request_uri reference using PAR and JAR together. >=20 > That=E2=80=99s why a key handle isn=E2=80=99t exactly the same as a = client ID and I did not call it a client ID in the XYZ protocol. It=E2=80=99= s a shortcut to refer to the key material for certain optimized cases, = but ultimately it=E2=80=99s pointing to a key. This has an interesting = and beneficial side effect =E2=80=94 if you HAVE a client ID as part of = your internal data model, it can FUNCTION as a key handle because it=E2=80= =99s a unique value the AS can use to look up key information. It=E2=80=99= s not =E2=80=9Cauthenticating the client=E2=80=9D, it=E2=80=99s pointing = to a key which in turn identifies and authenticates the software making = the call. The fact that it=E2=80=99s a =E2=80=9Cclient ID=E2=80=9D is an = artifact of the implementation, which in this case has an OAuth 2 legacy = to work with.=20 >=20 > If we=E2=80=99re going to move past the constraints of OAuth 2 we need = to stop thinking so strictly in its terms and models. There are better = ways to approach this now and client IDs are not required by this = protocol model. > Peace ..tom > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_55A6AAEB-414B-497E-94C2-3FF13840D4B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Key = rollover is really important. When I say that the client is identified = by the key, I do not mean that a client is DEFINED by its key. And with = that, it is important to know that it=E2=80=99s the AS that decides what = any particular key represents at any time. So long as the AS knows which = key to map to which set of policies that govern the actions of a client, = everything is fine. That mapping can change and the AS can keep the new = key tied to the same internal entity. The AS could even have multiple = keys tied to that entity, and accept any of those keys during a = request. 

It=E2=80= =99s exactly the same as changing a deployed OAuth 2 client=E2=80=99s = client_secret today. You change the secret on the AS and change it in = the client and it just keeps working like you=E2=80=99d = expect. 

Oh, but you might be thinking =E2=80=94 there we have the = client ID to tie it all together! Don=E2=80=99t we need that! Well, we = actually don=E2=80=99t. The AS can keep whatever internal identifier it = wants to during a client rollover. The protocol, and importantly the = client itself, need never be aware of that identifier. It might still be = there but you are no longer forced to expose it. 

Removing an external and = explicit client identifier enables this kind of deployment behavior, it = doesn=E2=80=99t hamper it.

 =E2=80=94 Justin

On Jun = 9, 2020, at 12:38 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

This = needs to be its own thread. I see the same trend in OpenID for = self-issued subject identification. I cannot imagine how key = roll-over could possibly work without major disruption to ongoing = activity.  Someone must show that key rollover in a fully = functioning system is possible before it is even = considered.

from = justin

The client is = identified by its key. There is no external client identifier. = I think you=E2=80=99re confused because you=E2=80=99re still thinking in = terms of OAuth 2=E2=80=99s client ID based model and I am trying to move = us past that. It took me time to realize that we really can let it go, = so hopefully this is helpful in explaining why.

When a credential is cryptographically = random enough to be unique, it can be used as its own identifier, = particularly when you don=E2=80=99t need to identify the entity outside = of the context that it can present and prove its credential. To stretch = a metaphor, passwords don=E2=80=99t always need usernames. This is, = after all, the driving design pattern behind OAuth access tokens. An = access token doesn=E2=80=99t have a =E2=80=9Cusername=E2=80=9D portion = to it, even though it would have been trivial to require the client to = send its client ID alongside the access token. Why does that work? = Because our model of what the RS does with the access token is built = around it answering the questions: is this token valid and does it allow = what=E2=80=99s being requested? If the RS needs to know which client was = issued the token, it can discover that information without being told = separately from the token -- perhaps it=E2=80=99s in the token itself or = it=E2=80=99s in an introspection response. And in a lot of cases, the RS = doesn=E2=80=99t care about the client software, it just wants to know if = the token=E2=80=99s any good. Even in constrained tokens such as MTLS, = PoP, and DPoP, we aren=E2=80=99t really authenticating the client at the = RS so much as making sure the right key is presented alongside the right = token. 

XYZ= takes that same approach with the client talking to the AS and uses the = credential (key) to identify the client as well as authenticate and = protect the request. We can=E2=80=99t just say =E2=80=9COAuth 2 had = client IDs and people are used to it so it must be good and we have to = keep using it=E2=80=9D. We need to ask WHY OAuth 2 needs client IDs and = if that still makes sense. I argue that it doesn=E2=80=99t make sense = anymore and we need to step back and look at a better model. OAuth 2 = needs a client ID because it gets passed in the front channel and the = client=E2=80=99s credentials can=E2=80=99t be used there. The access = token doesn=E2=80=99t need an equivalent because it=E2=80=99s passed in = the back channel and can be used directly. Now that the client no longer = needs to be identified, but not authenticated, through untrusted third = parties (such as the browser), we don=E2=80=99t need to have a separate = identifier as part of the protocol. With an intent-based protocol, that = starts in the back channel, you don=E2=80=99t need a client identifier = anymore. Once the AS finds that key, the AS can then figure out what = policies, rights, and restrictions are attached to that key. In many = implementations, there=E2=80=99s going to be some kind of =E2=80=9Cregiste= red client=E2=80=9D object in a database somewhere that drives those = policies. That=E2=80=99s the classical OAuth model, and it works in many = cases. But in other cases, the key is going to just be a value used to = protect the request chain (and possibly the token itself), and the = policy is going to be built up by other things like a device posture or = signature on the calling software or verified user information. It=E2=80=99= s not just about client authentication, even though it can be used for = it. DPoP, PKCE, and DynReg have shown us the value in dynamic systems, = in different ways. 

On top of that, PAR is showing us that a lot of the = constraints that we have in OAuth 2 don=E2=80=99t really apply anymore. = For instance, Redirect URI restrictions can be relaxed because now you = CAN identify and authenticate the software sending it, which isn=E2=80=99t= true with a front-channel-first approach. All of the things that are = required in OAuth 2 start to become redundant, and it leads to things = like requiring that =E2=80=9Cclient_id=E2=80=9D still always be passed = in the front channel even though the information could be looked up from = an internal request_uri reference using PAR and JAR together.

That=E2=80=99s why a key = handle isn=E2=80=99t exactly the same as a client ID and I did not call = it a client ID in the XYZ protocol. It=E2=80=99s a shortcut to refer to = the key material for certain optimized cases, but ultimately it=E2=80=99s = pointing to a key. This has an interesting and beneficial side effect = =E2=80=94 if you HAVE a client ID as part of your internal data model, = it can FUNCTION as a key handle because it=E2=80=99s a unique value the = AS can use to look up key information. It=E2=80=99s not = =E2=80=9Cauthenticating the client=E2=80=9D, it=E2=80=99s pointing to a = key which in turn identifies and authenticates the software making the = call. The fact that it=E2=80=99s a =E2=80=9Cclient ID=E2=80=9D is an = artifact of the implementation, which in this case has an OAuth 2 legacy = to work with. 

If we=E2=80=99re going to move past the constraints of OAuth = 2 we need to stop thinking so strictly in its terms and models. There = are better ways to approach this now and client IDs are not required by = this protocol model.
Peace = ..tom
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_55A6AAEB-414B-497E-94C2-3FF13840D4B5-- From nobody Tue Jun 9 10:52:16 2020 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 3394B3A0C79 for ; Tue, 9 Jun 2020 10:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 6BzchbqmDo7X for ; Tue, 9 Jun 2020 10:52:13 -0700 (PDT) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0: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 19EF43A0C6F for ; Tue, 9 Jun 2020 10:52:13 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id 25so18642758oiy.13 for ; Tue, 09 Jun 2020 10:52:13 -0700 (PDT) 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=5GRvfJHVe8P5ilpFrMGfjThmb3PuN25iTMJCF0OgqYM=; b=sC0LrDfBmA2/DbqikxaLIEz5sgkzpQ9ppBQZwBajszJ8bSmnxGeuQK8R3Fj9slb1BY OL6OE3NAnLMRn/Z7hfP7qFjkEhGB1MkcRwHx3yGjEX1wcrkzUYCxHrifQjQ1sYCI17jV VbXXwNMCNS9FAKiByIyZn7aY1uvGXpY1j231CzVzcqCQBWVDVz6Bc8VGw9GeTZKY0AnE mXz0kwJMGnLYofwket9h/XkRvwQ9EzF0xE1Nzgq8w+AzO+qGLlhVc28MW4vpj4z9Pwdh eY2BBkmO1YbGA66fxAqZxd6C5DMWAaIvDre+qeRq5+r9wgjHwNLEjTrstQL7wb9RkS9B yJoQ== 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=5GRvfJHVe8P5ilpFrMGfjThmb3PuN25iTMJCF0OgqYM=; b=fyMM6WAi80wnzrDVtAXTlqgUiQQXIq6l+QRYIDrnNazBd4x3LaBhk4ajIdWpy5lEmL +lQ9c0Xr1Rs2os5/6SvhY658aSt5DaQx9FbBIntzcy63NL+EkEyTetNZjR49daom1zyS ZhSnquuvdmfdd7pzjupxM1MM9YqzCEelXb/bKUKyRgGKJAtkAfzuKYkUhBH8SSZu2uXP +VOalsdAIXwrPhPdLQxphUb+A9S+1toHY3XKXe6MDvXZjCphkxx8QqTvwT6ySy/+N5XH LjuZflK9br374WR5d8WF4Umntu+V8NlagMqJB9Z3Jf9CCuzoBEZvUAC9P1foqujEbGsP r3oA== X-Gm-Message-State: AOAM532yGhXQlXQZ06yBCC+Zt4IiJz2rn4+Xx+Q66XK/TeI0rHJE/vJr GgV7lzwsXaPKzn4NJKEMm+bDDnbt6TETsKWUYmY= X-Google-Smtp-Source: ABdhPJzpjw6qMd/CNrFU5PrXpps03vw8LRZcRznPmQfp/7l2Ex7IcQTx724Qu5cUPDZhCj646+JxVQ2kytddo3rP5V0= X-Received: by 2002:aca:554c:: with SMTP id j73mr4677246oib.172.1591725132219; Tue, 09 Jun 2020 10:52:12 -0700 (PDT) MIME-Version: 1.0 References: <41E7211B-6599-463F-896C-A88EFF904921@mit.edu> In-Reply-To: <41E7211B-6599-463F-896C-A88EFF904921@mit.edu> From: Tom Jones Date: Tue, 9 Jun 2020 10:51:59 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000160a1705a7aa6303" Archived-At: Subject: Re: [Txauth] The client is identified by its key. 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, 09 Jun 2020 17:52:15 -0000 --000000000000160a1705a7aa6303 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That is feel good description. I am skeptical until a full description of the protocol exists. Even then i don't believe it works until i see it work for myself. If the roll-over is to be in the IETF spec then it requires two implementations. If it is not in the spec, then I would oppose adoption of the spec. Until i see some evidence that it works, I would not like to see it adopted. Otherwise we will get deployments that work fine for a year and then all start to fai. I've been there, that is not fun. Peace ..tom On Tue, Jun 9, 2020 at 10:38 AM Justin Richer wrote: > Key rollover is really important. When I say that the client is identifie= d > by the key, I do not mean that a client is DEFINED by its key. And with > that, it is important to know that it=E2=80=99s the AS that decides what = any > particular key represents at any time. So long as the AS knows which key = to > map to which set of policies that govern the actions of a client, > everything is fine. That mapping can change and the AS can keep the new k= ey > tied to the same internal entity. The AS could even have multiple keys ti= ed > to that entity, and accept any of those keys during a request. > > It=E2=80=99s exactly the same as changing a deployed OAuth 2 client=E2=80= =99s > client_secret today. You change the secret on the AS and change it in the > client and it just keeps working like you=E2=80=99d expect. > > Oh, but you might be thinking =E2=80=94 there we have the client ID to ti= e it all > together! Don=E2=80=99t we need that! Well, we actually don=E2=80=99t. Th= e AS can keep > whatever internal identifier it wants to during a client rollover. The > protocol, and importantly the client itself, need never be aware of that > identifier. It might still be there but you are no longer forced to expos= e > it. > > Removing an external and explicit client identifier enables this kind of > deployment behavior, it doesn=E2=80=99t hamper it. > > =E2=80=94 Justin > > On Jun 9, 2020, at 12:38 PM, Tom Jones > wrote: > > *This needs to be its own thread. I see the same trend in OpenID for > self-issued subject identification. I cannot imagine how key roll-over > could possibly work without major disruption to ongoing activity. Someon= e > must show that key rollover in a fully functioning system is possible > before it is even considered.* > > *from justin* > > *The client is identified by its key.* There is no external client > identifier. I think you=E2=80=99re confused because you=E2=80=99re still = thinking in terms > of OAuth 2=E2=80=99s client ID based model and I am trying to move us pas= t that. It > took me time to realize that we really can let it go, so hopefully this i= s > helpful in explaining why. > > When a credential is cryptographically random enough to be unique, it can > be used as its own identifier, particularly when you don=E2=80=99t need t= o identify > the entity outside of the context that it can present and prove its > credential. To stretch a metaphor, passwords don=E2=80=99t always need us= ernames. > This is, after all, the driving design pattern behind OAuth access tokens= . > An access token doesn=E2=80=99t have a =E2=80=9Cusername=E2=80=9D portion= to it, even though it > would have been trivial to require the client to send its client ID > alongside the access token. Why does that work? Because our model of what > the RS does with the access token is built around it answering the > questions: is this token valid and does it allow what=E2=80=99s being req= uested? If > the RS needs to know which client was issued the token, it can discover > that information without being told separately from the token -- perhaps > it=E2=80=99s in the token itself or it=E2=80=99s in an introspection resp= onse. And in a lot > of cases, the RS doesn=E2=80=99t care about the client software, it just = wants to > know if the token=E2=80=99s any good. Even in constrained tokens such as = MTLS, PoP, > and DPoP, we aren=E2=80=99t really authenticating the client at the RS so= much as > making sure the right key is presented alongside the right token. > > XYZ takes that same approach with the client talking to the AS and uses > the credential (key) to identify the client as well as authenticate and > protect the request. We can=E2=80=99t just say =E2=80=9COAuth 2 had clien= t IDs and people > are used to it so it must be good and we have to keep using it=E2=80=9D. = We need to > ask WHY OAuth 2 needs client IDs and if that still makes sense. I argue > that it doesn=E2=80=99t make sense anymore and we need to step back and l= ook at a > better model. OAuth 2 needs a client ID because it gets passed in the fro= nt > channel and the client=E2=80=99s credentials can=E2=80=99t be used there.= The access token > doesn=E2=80=99t need an equivalent because it=E2=80=99s passed in the bac= k channel and can > be used directly. Now that the client no longer needs to be identified, b= ut > not authenticated, through untrusted third parties (such as the browser), > we don=E2=80=99t need to have a separate identifier as part of the protoc= ol. With > an intent-based protocol, that starts in the back channel, you don=E2=80= =99t need a > client identifier anymore. Once the AS finds that key, the AS can then > figure out what policies, rights, and restrictions are attached to that > key. In many implementations, there=E2=80=99s going to be some kind of = =E2=80=9Cregistered > client=E2=80=9D object in a database somewhere that drives those policies= . That=E2=80=99s > the classical OAuth model, and it works in many cases. But in other cases= , > the key is going to just be a value used to protect the request chain (an= d > possibly the token itself), and the policy is going to be built up by oth= er > things like a device posture or signature on the calling software or > verified user information. It=E2=80=99s not just about client authenticat= ion, even > though it can be used for it. DPoP, PKCE, and DynReg have shown us the > value in dynamic systems, in different ways. > > On top of that, PAR is showing us that a lot of the constraints that we > have in OAuth 2 don=E2=80=99t really apply anymore. For instance, Redirec= t URI > restrictions can be relaxed because now you CAN identify and authenticate > the software sending it, which isn=E2=80=99t true with a front-channel-fi= rst > approach. All of the things that are required in OAuth 2 start to become > redundant, and it leads to things like requiring that =E2=80=9Cclient_id= =E2=80=9D still > always be passed in the front channel even though the information could b= e > looked up from an internal request_uri reference using PAR and JAR togeth= er. > > That=E2=80=99s why a key handle isn=E2=80=99t exactly the same as a clien= t ID and I did > not call it a client ID in the XYZ protocol. It=E2=80=99s a shortcut to r= efer to > the key material for certain optimized cases, but ultimately it=E2=80=99s= pointing > to a key. This has an interesting and beneficial side effect =E2=80=94 if= you HAVE > a client ID as part of your internal data model, it can FUNCTION as a key > handle because it=E2=80=99s a unique value the AS can use to look up key > information. It=E2=80=99s not =E2=80=9Cauthenticating the client=E2=80=9D= , it=E2=80=99s pointing to a key > which in turn identifies and authenticates the software making the call. > The fact that it=E2=80=99s a =E2=80=9Cclient ID=E2=80=9D is an artifact o= f the implementation, > which in this case has an OAuth 2 legacy to work with. > > If we=E2=80=99re going to move past the constraints of OAuth 2 we need to= stop > thinking so strictly in its terms and models. There are better ways to > approach this now and client IDs are not required by this protocol model. > Peace ..tom > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --000000000000160a1705a7aa6303 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That is feel good description.=C2=A0 I am skeptical until = a full description of the protocol exists. Even then i don't believe it= works until i see it work for myself. If the=C2=A0roll-over is to be in th= e IETF spec then it requires two implementations. If it is not in the spec,= then I would oppose adoption of the spec. Until i see some evidence that i= t works, I would not like to see it adopted. Otherwise we will get deployme= nts that work fine for a year and then all start to fai. I've been ther= e, that is not fun.

Pea= ce ..tom


On Tue, Jun 9, 2020 at 10:38 AM J= ustin Richer <jricher@mit.edu>= wrote:
Key rollover is really important. When I = say that the client is identified by the key, I do not mean that a client i= s DEFINED by its key. And with that, it is important to know that it=E2=80= =99s the AS that decides what any particular key represents at any time. So= long as the AS knows which key to map to which set of policies that govern= the actions of a client, everything is fine. That mapping can change and t= he AS can keep the new key tied to the same internal entity. The AS could e= ven have multiple keys tied to that entity, and accept any of those keys du= ring a request.=C2=A0

It=E2=80=99s exactly the same as c= hanging a deployed OAuth 2 client=E2=80=99s client_secret today. You change= the secret on the AS and change it in the client and it just keeps working= like you=E2=80=99d expect.=C2=A0

Oh, but you migh= t be thinking =E2=80=94 there we have the client ID to tie it all together!= Don=E2=80=99t we need that! Well, we actually don=E2=80=99t. The AS can ke= ep whatever internal identifier it wants to during a client rollover. The p= rotocol, and importantly the client itself, need never be aware of that ide= ntifier. It might still be there but you are no longer forced to expose it.= =C2=A0

Removing an external and explicit client id= entifier enables this kind of deployment behavior, it doesn=E2=80=99t hampe= r it.

=C2=A0=E2=80=94 Justin

On Jun 9, 2020, at 12:38 PM, Tom Jones <thomasclinganjones@= gmail.com> wrote:

This needs= =C2=A0to be its own thread. I see the same trend in OpenID for self-issued = subject=C2=A0identification. I cannot imagine how key roll-over could possi= bly work without major disruption to ongoing activity.=C2=A0 Someone must s= how that key rollover in a fully functioning system is possible before it i= s even considered.

from justin

The client is identified by its key.= =C2=A0There is no external client identifier. I think you=E2=80=99re confus= ed because you=E2=80=99re still thinking in terms of OAuth 2=E2=80=99s clie= nt ID based model and I am trying to move us past that. It took me time to = realize that we really can let it go, so hopefully this is helpful in expla= ining why.

When a credential is cryptographically = random enough to be unique, it can be used as its own identifier, particula= rly when you don=E2=80=99t need to identify the entity outside of the conte= xt that it can present and prove its credential. To stretch a metaphor, pas= swords don=E2=80=99t always need usernames. This is, after all, the driving= design pattern behind OAuth access tokens. An access token doesn=E2=80=99t= have a =E2=80=9Cusername=E2=80=9D portion to it, even though it would have= been trivial to require the client to send its client ID alongside the acc= ess token. Why does that work? Because our model of what the RS does with t= he access token is built around it answering the questions: is this token v= alid and does it allow what=E2=80=99s being requested? If the RS needs to k= now which client was issued the token, it can discover that information wit= hout being told separately from the token -- perhaps it=E2=80=99s in the to= ken itself or it=E2=80=99s in an introspection response. And in a lot of ca= ses, the RS doesn=E2=80=99t care about the client software, it just wants t= o know if the token=E2=80=99s any good. Even in constrained tokens such as = MTLS, PoP, and DPoP, we aren=E2=80=99t really authenticating the client at = the RS so much as making sure the right key is presented alongside the righ= t token.=C2=A0

XYZ takes that same approach with t= he client talking to the AS and uses the credential (key) to identify the c= lient as well as authenticate and protect the request. We can=E2=80=99t jus= t say =E2=80=9COAuth 2 had client IDs and people are used to it so it must = be good and we have to keep using it=E2=80=9D. We need to ask WHY OAuth 2 n= eeds client IDs and if that still makes sense. I argue that it doesn=E2=80= =99t make sense anymore and we need to step back and look at a better model= . OAuth 2 needs a client ID because it gets passed in the front channel and= the client=E2=80=99s credentials can=E2=80=99t be used there. The access t= oken doesn=E2=80=99t need an equivalent because it=E2=80=99s passed in the = back channel and can be used directly. Now that the client no longer needs = to be identified, but not authenticated, through untrusted third parties (s= uch as the browser), we don=E2=80=99t need to have a separate identifier as= part of the protocol. With an intent-based protocol, that starts in the ba= ck channel, you don=E2=80=99t need a client identifier anymore. Once the AS= finds that key, the AS can then figure out what policies, rights, and rest= rictions are attached to that key. In many implementations, there=E2=80=99s= going to be some kind of =E2=80=9Cregistered client=E2=80=9D object in a d= atabase somewhere that drives those policies. That=E2=80=99s the classical = OAuth model, and it works in many cases. But in other cases, the key is goi= ng to just be a value used to protect the request chain (and possibly the t= oken itself), and the policy is going to be built up by other things like a= device posture or signature on the calling software or verified user infor= mation. It=E2=80=99s not just about client authentication, even though it c= an be used for it. DPoP, PKCE, and DynReg have shown us the value in dynami= c systems, in different ways.=C2=A0

On top of that= , PAR is showing us that a lot of the constraints that we have in OAuth 2 d= on=E2=80=99t really apply anymore. For instance, Redirect URI restrictions = can be relaxed because now you CAN identify and authenticate the software s= ending it, which isn=E2=80=99t true with a front-channel-first approach. Al= l of the things that are required in OAuth 2 start to become redundant, and= it leads to things like requiring that =E2=80=9Cclient_id=E2=80=9D still a= lways be passed in the front channel even though the information could be l= ooked up from an internal request_uri reference using PAR and JAR together.=

That=E2=80=99s why a key handle isn=E2=80=99t exa= ctly the same as a client ID and I did not call it a client ID in the XYZ p= rotocol. It=E2=80=99s a shortcut to refer to the key material for certain o= ptimized cases, but ultimately it=E2=80=99s pointing to a key. This has an = interesting and beneficial side effect =E2=80=94 if you HAVE a client ID as= part of your internal data model, it can FUNCTION as a key handle because = it=E2=80=99s a unique value the AS can use to look up key information. It= =E2=80=99s not =E2=80=9Cauthenticating the client=E2=80=9D, it=E2=80=99s po= inting to a key which in turn identifies and authenticates the software mak= ing the call. The fact that it=E2=80=99s a =E2=80=9Cclient ID=E2=80=9D is a= n artifact of the implementation, which in this case has an OAuth 2 legacy = to work with.=C2=A0

If we=E2=80=99re going to move= past the constraints of OAuth 2 we need to stop thinking so strictly in it= s terms and models. There are better ways to approach this now and client I= Ds are not required by this protocol model.
Peace ..tom
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth=

--000000000000160a1705a7aa6303-- From nobody Tue Jun 9 12:13:01 2020 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 6D8F03A0D1A for ; Tue, 9 Jun 2020 12:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 FminUNNZu8B9 for ; Tue, 9 Jun 2020 12:12:57 -0700 (PDT) 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 9C9613A0D0F for ; Tue, 9 Jun 2020 12:12:56 -0700 (PDT) Received: from [192.168.1.14] (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 059JCrDl005119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 9 Jun 2020 15:12:54 -0400 From: Justin Richer Message-Id: <172AD6B4-06BF-4762-A45B-E8ABEBE81799@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_56E67C89-19E4-4F34-B116-F3736340585F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 9 Jun 2020 15:12:53 -0400 In-Reply-To: Cc: txauth@ietf.org To: Tom Jones References: <41E7211B-6599-463F-896C-A88EFF904921@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] The client is identified by its key. 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, 09 Jun 2020 19:13:00 -0000 --Apple-Mail=_56E67C89-19E4-4F34-B116-F3736340585F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My explanation below isn=E2=80=99t based on speculation, but on many = years of experience in dealing with these kinds of things in real = systems. I=E2=80=99m with you in the importance of implementation, which = is why there are already several independent implementations of XYZ out = there. Specifications are just ideas until someone puts it into = practice! I=E2=80=99m eager to hear what kinds of solutions you have in mind for = supporting key rollover in this protocol, and how we can best enable it.=20= =E2=80=94 Justin > On Jun 9, 2020, at 1:51 PM, Tom Jones = wrote: >=20 > That is feel good description. I am skeptical until a full = description of the protocol exists. Even then i don't believe it works = until i see it work for myself. If the roll-over is to be in the IETF = spec then it requires two implementations. If it is not in the spec, = then I would oppose adoption of the spec. Until i see some evidence that = it works, I would not like to see it adopted. Otherwise we will get = deployments that work fine for a year and then all start to fai. I've = been there, that is not fun. >=20 > Peace ..tom >=20 >=20 > On Tue, Jun 9, 2020 at 10:38 AM Justin Richer > wrote: > Key rollover is really important. When I say that the client is = identified by the key, I do not mean that a client is DEFINED by its = key. And with that, it is important to know that it=E2=80=99s the AS = that decides what any particular key represents at any time. So long as = the AS knows which key to map to which set of policies that govern the = actions of a client, everything is fine. That mapping can change and the = AS can keep the new key tied to the same internal entity. The AS could = even have multiple keys tied to that entity, and accept any of those = keys during a request.=20 >=20 > It=E2=80=99s exactly the same as changing a deployed OAuth 2 = client=E2=80=99s client_secret today. You change the secret on the AS = and change it in the client and it just keeps working like you=E2=80=99d = expect.=20 >=20 > Oh, but you might be thinking =E2=80=94 there we have the client ID to = tie it all together! Don=E2=80=99t we need that! Well, we actually = don=E2=80=99t. The AS can keep whatever internal identifier it wants to = during a client rollover. The protocol, and importantly the client = itself, need never be aware of that identifier. It might still be there = but you are no longer forced to expose it.=20 >=20 > Removing an external and explicit client identifier enables this kind = of deployment behavior, it doesn=E2=80=99t hamper it. >=20 > =E2=80=94 Justin >=20 >> On Jun 9, 2020, at 12:38 PM, Tom Jones > wrote: >>=20 >> This needs to be its own thread. I see the same trend in OpenID for = self-issued subject identification. I cannot imagine how key roll-over = could possibly work without major disruption to ongoing activity. = Someone must show that key rollover in a fully functioning system is = possible before it is even considered. >>=20 >> from justin >>=20 >> The client is identified by its key. There is no external client = identifier. I think you=E2=80=99re confused because you=E2=80=99re still = thinking in terms of OAuth 2=E2=80=99s client ID based model and I am = trying to move us past that. It took me time to realize that we really = can let it go, so hopefully this is helpful in explaining why. >>=20 >> When a credential is cryptographically random enough to be unique, it = can be used as its own identifier, particularly when you don=E2=80=99t = need to identify the entity outside of the context that it can present = and prove its credential. To stretch a metaphor, passwords don=E2=80=99t = always need usernames. This is, after all, the driving design pattern = behind OAuth access tokens. An access token doesn=E2=80=99t have a = =E2=80=9Cusername=E2=80=9D portion to it, even though it would have been = trivial to require the client to send its client ID alongside the access = token. Why does that work? Because our model of what the RS does with = the access token is built around it answering the questions: is this = token valid and does it allow what=E2=80=99s being requested? If the RS = needs to know which client was issued the token, it can discover that = information without being told separately from the token -- perhaps = it=E2=80=99s in the token itself or it=E2=80=99s in an introspection = response. And in a lot of cases, the RS doesn=E2=80=99t care about the = client software, it just wants to know if the token=E2=80=99s any good. = Even in constrained tokens such as MTLS, PoP, and DPoP, we aren=E2=80=99t = really authenticating the client at the RS so much as making sure the = right key is presented alongside the right token.=20 >>=20 >> XYZ takes that same approach with the client talking to the AS and = uses the credential (key) to identify the client as well as authenticate = and protect the request. We can=E2=80=99t just say =E2=80=9COAuth 2 had = client IDs and people are used to it so it must be good and we have to = keep using it=E2=80=9D. We need to ask WHY OAuth 2 needs client IDs and = if that still makes sense. I argue that it doesn=E2=80=99t make sense = anymore and we need to step back and look at a better model. OAuth 2 = needs a client ID because it gets passed in the front channel and the = client=E2=80=99s credentials can=E2=80=99t be used there. The access = token doesn=E2=80=99t need an equivalent because it=E2=80=99s passed in = the back channel and can be used directly. Now that the client no longer = needs to be identified, but not authenticated, through untrusted third = parties (such as the browser), we don=E2=80=99t need to have a separate = identifier as part of the protocol. With an intent-based protocol, that = starts in the back channel, you don=E2=80=99t need a client identifier = anymore. Once the AS finds that key, the AS can then figure out what = policies, rights, and restrictions are attached to that key. In many = implementations, there=E2=80=99s going to be some kind of =E2=80=9Cregiste= red client=E2=80=9D object in a database somewhere that drives those = policies. That=E2=80=99s the classical OAuth model, and it works in many = cases. But in other cases, the key is going to just be a value used to = protect the request chain (and possibly the token itself), and the = policy is going to be built up by other things like a device posture or = signature on the calling software or verified user information. It=E2=80=99= s not just about client authentication, even though it can be used for = it. DPoP, PKCE, and DynReg have shown us the value in dynamic systems, = in different ways.=20 >>=20 >> On top of that, PAR is showing us that a lot of the constraints that = we have in OAuth 2 don=E2=80=99t really apply anymore. For instance, = Redirect URI restrictions can be relaxed because now you CAN identify = and authenticate the software sending it, which isn=E2=80=99t true with = a front-channel-first approach. All of the things that are required in = OAuth 2 start to become redundant, and it leads to things like requiring = that =E2=80=9Cclient_id=E2=80=9D still always be passed in the front = channel even though the information could be looked up from an internal = request_uri reference using PAR and JAR together. >>=20 >> That=E2=80=99s why a key handle isn=E2=80=99t exactly the same as a = client ID and I did not call it a client ID in the XYZ protocol. It=E2=80=99= s a shortcut to refer to the key material for certain optimized cases, = but ultimately it=E2=80=99s pointing to a key. This has an interesting = and beneficial side effect =E2=80=94 if you HAVE a client ID as part of = your internal data model, it can FUNCTION as a key handle because it=E2=80= =99s a unique value the AS can use to look up key information. It=E2=80=99= s not =E2=80=9Cauthenticating the client=E2=80=9D, it=E2=80=99s pointing = to a key which in turn identifies and authenticates the software making = the call. The fact that it=E2=80=99s a =E2=80=9Cclient ID=E2=80=9D is an = artifact of the implementation, which in this case has an OAuth 2 legacy = to work with.=20 >>=20 >> If we=E2=80=99re going to move past the constraints of OAuth 2 we = need to stop thinking so strictly in its terms and models. There are = better ways to approach this now and client IDs are not required by this = protocol model. >> Peace ..tom >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=20 --Apple-Mail=_56E67C89-19E4-4F34-B116-F3736340585F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = explanation below isn=E2=80=99t based on speculation, but on many years = of experience in dealing with these kinds of things in real systems. = I=E2=80=99m with you in the importance of implementation, which is why = there are already several independent implementations of XYZ out there. = Specifications are just ideas until someone puts it into practice!

I=E2=80=99m eager to = hear what kinds of solutions you have in mind for supporting key = rollover in this protocol, and how we can best enable = it. 

 = =E2=80=94 Justin

On Jun 9, 2020, at 1:51 PM, Tom = Jones <thomasclinganjones@gmail.com> wrote:

That is feel good = description.  I am skeptical until a full description of the = protocol exists. Even then i don't believe it works until i see it work = for myself. If the roll-over is to be in the IETF spec then it = requires two implementations. If it is not in the spec, then I would = oppose adoption of the spec. Until i see some evidence that it works, I = would not like to see it adopted. Otherwise we will get deployments that = work fine for a year and then all start to fai. I've been there, that is = not fun.

Peace ..tom


On Tue, Jun 9, 2020 at 10:38 AM Justin = Richer <jricher@mit.edu> wrote:
Key rollover is really important. When I say = that the client is identified by the key, I do not mean that a client is = DEFINED by its key. And with that, it is important to know that it=E2=80=99= s the AS that decides what any particular key represents at any time. So = long as the AS knows which key to map to which set of policies that = govern the actions of a client, everything is fine. That mapping can = change and the AS can keep the new key tied to the same internal entity. = The AS could even have multiple keys tied to that entity, and accept any = of those keys during a request. 

It=E2=80=99s exactly the same as = changing a deployed OAuth 2 client=E2=80=99s client_secret today. You = change the secret on the AS and change it in the client and it just = keeps working like you=E2=80=99d expect. 

Oh, but you might be thinking =E2=80=94 = there we have the client ID to tie it all together! Don=E2=80=99t we = need that! Well, we actually don=E2=80=99t. The AS can keep whatever = internal identifier it wants to during a client rollover. The protocol, = and importantly the client itself, need never be aware of that = identifier. It might still be there but you are no longer forced to = expose it. 

Removing an external and explicit client identifier enables = this kind of deployment behavior, it doesn=E2=80=99t hamper = it.

 =E2=80= =94 Justin

On Jun 9, 2020, at 12:38 PM, = Tom Jones <thomasclinganjones@gmail.com> = wrote:

This needs to be its own = thread. I see the same trend in OpenID for self-issued = subject identification. I cannot imagine how key roll-over could = possibly work without major disruption to ongoing activity.  = Someone must show that key rollover in a fully functioning system is = possible before it is even considered.

from = justin

The client is = identified by its key. There is no external client identifier. = I think you=E2=80=99re confused because you=E2=80=99re still thinking in = terms of OAuth 2=E2=80=99s client ID based model and I am trying to move = us past that. It took me time to realize that we really can let it go, = so hopefully this is helpful in explaining why.

When a credential is cryptographically = random enough to be unique, it can be used as its own identifier, = particularly when you don=E2=80=99t need to identify the entity outside = of the context that it can present and prove its credential. To stretch = a metaphor, passwords don=E2=80=99t always need usernames. This is, = after all, the driving design pattern behind OAuth access tokens. An = access token doesn=E2=80=99t have a =E2=80=9Cusername=E2=80=9D portion = to it, even though it would have been trivial to require the client to = send its client ID alongside the access token. Why does that work? = Because our model of what the RS does with the access token is built = around it answering the questions: is this token valid and does it allow = what=E2=80=99s being requested? If the RS needs to know which client was = issued the token, it can discover that information without being told = separately from the token -- perhaps it=E2=80=99s in the token itself or = it=E2=80=99s in an introspection response. And in a lot of cases, the RS = doesn=E2=80=99t care about the client software, it just wants to know if = the token=E2=80=99s any good. Even in constrained tokens such as MTLS, = PoP, and DPoP, we aren=E2=80=99t really authenticating the client at the = RS so much as making sure the right key is presented alongside the right = token. 

XYZ= takes that same approach with the client talking to the AS and uses the = credential (key) to identify the client as well as authenticate and = protect the request. We can=E2=80=99t just say =E2=80=9COAuth 2 had = client IDs and people are used to it so it must be good and we have to = keep using it=E2=80=9D. We need to ask WHY OAuth 2 needs client IDs and = if that still makes sense. I argue that it doesn=E2=80=99t make sense = anymore and we need to step back and look at a better model. OAuth 2 = needs a client ID because it gets passed in the front channel and the = client=E2=80=99s credentials can=E2=80=99t be used there. The access = token doesn=E2=80=99t need an equivalent because it=E2=80=99s passed in = the back channel and can be used directly. Now that the client no longer = needs to be identified, but not authenticated, through untrusted third = parties (such as the browser), we don=E2=80=99t need to have a separate = identifier as part of the protocol. With an intent-based protocol, that = starts in the back channel, you don=E2=80=99t need a client identifier = anymore. Once the AS finds that key, the AS can then figure out what = policies, rights, and restrictions are attached to that key. In many = implementations, there=E2=80=99s going to be some kind of =E2=80=9Cregiste= red client=E2=80=9D object in a database somewhere that drives those = policies. That=E2=80=99s the classical OAuth model, and it works in many = cases. But in other cases, the key is going to just be a value used to = protect the request chain (and possibly the token itself), and the = policy is going to be built up by other things like a device posture or = signature on the calling software or verified user information. It=E2=80=99= s not just about client authentication, even though it can be used for = it. DPoP, PKCE, and DynReg have shown us the value in dynamic systems, = in different ways. 

On top of that, PAR is showing us that a lot of the = constraints that we have in OAuth 2 don=E2=80=99t really apply anymore. = For instance, Redirect URI restrictions can be relaxed because now you = CAN identify and authenticate the software sending it, which isn=E2=80=99t= true with a front-channel-first approach. All of the things that are = required in OAuth 2 start to become redundant, and it leads to things = like requiring that =E2=80=9Cclient_id=E2=80=9D still always be passed = in the front channel even though the information could be looked up from = an internal request_uri reference using PAR and JAR together.

That=E2=80=99s why a key = handle isn=E2=80=99t exactly the same as a client ID and I did not call = it a client ID in the XYZ protocol. It=E2=80=99s a shortcut to refer to = the key material for certain optimized cases, but ultimately it=E2=80=99s = pointing to a key. This has an interesting and beneficial side effect = =E2=80=94 if you HAVE a client ID as part of your internal data model, = it can FUNCTION as a key handle because it=E2=80=99s a unique value the = AS can use to look up key information. It=E2=80=99s not = =E2=80=9Cauthenticating the client=E2=80=9D, it=E2=80=99s pointing to a = key which in turn identifies and authenticates the software making the = call. The fact that it=E2=80=99s a =E2=80=9Cclient ID=E2=80=9D is an = artifact of the implementation, which in this case has an OAuth 2 legacy = to work with. 

If we=E2=80=99re going to move past the constraints of OAuth = 2 we need to stop thinking so strictly in its terms and models. There = are better ways to approach this now and client IDs are not required by = this protocol model.
Peace = ..tom
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth


= --Apple-Mail=_56E67C89-19E4-4F34-B116-F3736340585F-- From nobody Tue Jun 9 13:08:27 2020 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 F04223A03ED for ; Tue, 9 Jun 2020 13:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 uCCxEIqUdGix for ; Tue, 9 Jun 2020 13:08:24 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 C9CB53A040F for ; Tue, 9 Jun 2020 13:08:22 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id x93so17356662ede.9 for ; Tue, 09 Jun 2020 13:08:22 -0700 (PDT) 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=kvnfaEmLgdGf5GUZ5eGneq46axbnEbuhcUq5IDxeuAQ=; b=XsrTpwE50zJIBCMJFnNy+6KwoahTTMpRaB6JZkmAW/QDXwiIsMWFDWrwrmUuEeLT/g SqYUgwXMjEXO6aUcE8N1DTeZk53DkVmQ/LB645o97+9fnLpfDKDi8xys0p77Pr+8tCOT tnmcO7pPSgcMfBkUYj4+uyK//fW9MakZ/4XLF6krYafA1yFulb2R0hqJ4J086QJ2aLc4 zBbXmimsVin0oKzHqXIZ3MJg9js76gCxJNczobOm9X9UVvIYD6JBXawQceSNco3v6FfR Hd5pcoK4qAMu0Rn5YkLTVqq8E47eaWqz+RpM/zmcA79fvNEi4j/GiDnLVyUs305HWXyJ lBMA== 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=kvnfaEmLgdGf5GUZ5eGneq46axbnEbuhcUq5IDxeuAQ=; b=n8P7VvAZ44OKdNpG6hrvQbIXfInBPYUwYMXJtXd5yCmDrK2mX3FWdoAlBmMBUwpd34 Vr/KRGxFevLjHmU0rEZDumoKyXu40NELPXM1pHhgI2g8mFuwHZ+CyMrjoIG90nEWSJqz bdYdZdwd0BbMR3Saq5wVegEI5mla6arz6cSypEje4sRaHnrjmrT5C5xkdJ8owX4fWC8i VeIiOp6LvpUd787g9V6fBow8yHIeIUyc/QnRRvgphtfCwueTSJdbp21wqg32RX0f2i+6 /x6/Y493+Gq04gmuE4uMZy0TVFLi0xXqZzrQkzH8XiPXFDfmf5b/pxnTMkFNryY03NaM /i/g== X-Gm-Message-State: AOAM533TjoYytB6k2azj6ZGRcv/nxKoMHe24Efg8IZefICSzEh6KMRqe +PWnX8teSQ5x7LY/O/PvrfR5TZw2X/HZO+DE45g= X-Google-Smtp-Source: ABdhPJyADXk57DD3OqAejhGbUW7C6yVUq7HtfnyeWewQnMq2Kg3DoWiuawqjAEaV41gMMYeRxGJNG8HdNaz+GZEs+08= X-Received: by 2002:a50:e14e:: with SMTP id i14mr27276850edl.279.1591733301316; Tue, 09 Jun 2020 13:08:21 -0700 (PDT) MIME-Version: 1.0 References: <399d74e9-96d8-4f61-b01e-df9a8ee972d2@www.fastmail.com> In-Reply-To: From: David Skaife Date: Tue, 9 Jun 2020 21:08:12 +0100 Message-ID: To: Dick Hardt Cc: Amanjeev Sethi , Fabien Imbault , Jared Jennings , txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000000936805a7ac4acf" Archived-At: Subject: Re: [Txauth] GNAP it is 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, 09 Jun 2020 20:08:26 -0000 --00000000000000936805a7ac4acf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for recommending pronunciation with a silent 'g'. On Sun, Jun 7, 2020 at 8:45 PM Dick Hardt wrote: > Anyone have objection to the recommended pronunciation being the English > word "nap", as in "gnaw"? > > If not, then we could add a pronunciation recommendation to the Charter. > > =E1=90=A7 > > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi wrote: > >> Vote for 'G' silent, as in 'lagnappe' ;) >> >> On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote: >> >> I vote for G silent. For the reason it's most common to pronounce, >> especially for those not familiar with open source usages. >> >> On Sat, Jun 6, 2020, 08:45 Dick Hardt wrote: >> >> The obvious pronunciation choices are: >> >> nap (silent g as in gnaw) >> >> guh-nap (as in the GNU OS - >> https://www.gnu.org/gnu/pronunciation.en..html >> ) >> >> gee-nap (as in G-man - government man - >> https://en.wikipedia.org/wiki/G-man) >> >> >> >> =E1=90=A7 >> >> On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault >> wrote: >> >> So, let's adopt a GNAP! We can even come with a little mascot (a bit lik= e >> go gopher) as imagined by http://elisegravel.com/blog/adopte-un-gnap/, >> loved by little Canadians :-) >> >> Just to be sure, how do you recommand we pronounce it? >> >> Looking forward to the next steps too.. >> >> Thxs >> Fabien >> -- >> 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 >> >> >> -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000000936805a7ac4acf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for recommending pronunciation with a silent 'g'= ;.

On Sun, Jun 7, 2020 at 8:45 PM Dick Hardt <dick.hardt@gmail.com> wrote:
Anyone have objection= to the recommended pronunciation=C2=A0being the English word "nap&quo= t;, as in "gnaw"?

If not, then we could add a = pronunciation=C2=A0recommendation to the Charter.

3D""=E1=90=A7

On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Set= hi <aj@amanjeev.com= > wrote:
=
Vote for 'G' silent, as in 'lagnappe' ;)

On Sat, Jun 6, 2020, at 10:52 AM, Jared Jenning= s wrote:
I vote for G silent. Fo= r the reason it's most common to pronounce, especially for those not fa= miliar with open source usages.

On Sat, Jun 6, 2020, 08:45 Dick Hardt <dick.hardt@gmail.com> wrote:
The obvious pronunciation = choices are:

nap (silent g as in gnaw)

guh-nap (as in the GNU OS -=C2=A0= https://www.gnu.org/gnu/pronunciation.en..html)

gee-nap (as in G-man - government man -=C2=A0https://en.wik= ipedia.org/wiki/G-man)



=
3D""=E1=90=A7
<= br>
On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbaul= t <fabien.imbault@gmail.com> wrote:
So, let's adopt a GNA= P! We can even come with a little mascot (a bit like go gopher) as imagined= by=C2=A0http://elisegravel.com/blog/adopte-un= -gnap/, loved by little Canadians :-)=C2=A0
=
Just to be sure, how do you recommand we pronou= nce it?=C2=A0

Lookin= g forward to the next steps too..=C2=A0

Thxs
Fabien
<= div>--
Txauth mailing list
--
Txaut= h mailing list
=
--=C2=A0

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000000936805a7ac4acf-- From nobody Tue Jun 9 13:11:44 2020 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 0394E3A0528 for ; Tue, 9 Jun 2020 13:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 NZ3B9RP3ebbb for ; Tue, 9 Jun 2020 13:11:39 -0700 (PDT) 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 4D6723A0477 for ; Tue, 9 Jun 2020 13:11:39 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id a25so26712146ljp.3 for ; Tue, 09 Jun 2020 13:11:39 -0700 (PDT) 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=pWoPR5VBSJPJ0Xd2J2PnA3Ml4vY4b6xRwAzmIGtBX00=; b=Ln112j250h9cFGJ1e3Hl3kbSazQuz7VYzbE/ONlny4Eq6T7d6pIEhFdy0iGj/VTSwB rZbpMcZgYgbq/L8O+qoLc91Owq3y/5NMdDDUz7FDyVOdnU6KU+bPpNCnLW2pziGe9/MP 89cYUIIhp1Sz9RvCBnwRXZRZXoaCcj5jLAnzDndbxWudeqRwRjHzBJRVITaKvNnRGelC auHuzIRvHpcjJn7akCnASxbkELOCKyorGKHRMcwd5nevblG3Bex2xPotLzh+Gg0xg+MM d91+VXWS+cLh2Qs/Pm7GAP1uSMbZCu4jQxAccUC/TUmZv2UxQUgI2uKc0kvlchS2vFE+ /g7g== 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=pWoPR5VBSJPJ0Xd2J2PnA3Ml4vY4b6xRwAzmIGtBX00=; b=rS5Q9vjnlHB+zL8t+SjPechYnAZMjFlotqE4MeBh3hPgfHxSoE6CCnWqk/DbE2/+dZ 1E2VgmhJ+wDJEYKJ9lZEsyxV5IrnuNW6Lr/qzXFE3q3N/rBPFeZJQq4uahmvuwJLo9li q7JmkefbqUjicyVR/p2iX7Chf35bWFQfgKnJEjrAKoDBiReh2ApuT4KtORc4FQhk7VnU LbNV4/hAsiAp/8nqjIULd86OftcoHr9THjkl0GW7UNX15ZNMgynqpNJWIg/oLgG7F64N jQ5NdvNRJ6QopXbAdUL3HlLgOUMC7vcPRDK8pVD+oTC9zG1QDUDSWOW6qbZqgyxxq8Ta SfIw== X-Gm-Message-State: AOAM531SBKj0gNNQXsZbpuDRZRjC0iBvihCmFx8QCyE3Rc4IYYZ0jw8M 2J0WWzo/izIroT+LnxgnIiZK310lk1ySc1PV/iK6hk6+ X-Google-Smtp-Source: ABdhPJzHFud8AmhgVj1mYobZ/YRyEF259KS1HXnxxnzdbE8XgQikJpZ6sT9s3znWFRJ3Bcfzb2ZaQTRjwL/ZsLhye4g= X-Received: by 2002:a2e:97ce:: with SMTP id m14mr10029ljj.216.1591733495712; Tue, 09 Jun 2020 13:11:35 -0700 (PDT) MIME-Version: 1.0 References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> In-Reply-To: <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> From: Dick Hardt Date: Tue, 9 Jun 2020 13:11:08 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000096d0ef05a7ac5503" Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 09 Jun 2020 20:11:43 -0000 --00000000000096d0ef05a7ac5503 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Comments inline Last item will be broken out to new thread. On Tue, Jun 9, 2020 at 9:10 AM Justin Richer wrote: > > > On Jun 8, 2020, at 5:33 PM, Dick Hardt wrote: > > > > On Mon, Jun 8, 2020 at 1:02 PM Justin Richer wrote: > > > >> A GS implementation can decide to only return an authorization from doin= g >> a GET on the AZ URL. Returning only an AZ URL is an option in XAuth. >> Similarly, we could do the same for a Grant URI. >> >> >> And that=E2=80=99s a lot of complex code paths for both the GS and clien= t to deal >> with. With more ways that it might happen, the client has to be prepared >> for any of them =E2=80=94 and get them all right. >> > > I don't see it being complex. The data either moves by reference or by > value. Both parties will have to enable support by reference. Passing by > value is an optimization so that the client does not have to make an > additional call. > > > =E2=80=9CBoth parties will have to enable=E2=80=9D is where the complexit= y comes into > play. It=E2=80=99s putting a requirement on the client to anticipate seve= ral > different ways to get the same information. > As I understand it, XYZ works the same way. The client may get a handle to the transaction in an Interaction Response or a Wait Response, or the client receives a transaction response. There could be only one way in XAuth (pass by reference), but I expect that people will prefer an optimization of pass by value when it can be done and deal with the complexity that they may get the data in two different ways, just as in XYZ. > > > > >> >> >> >>> >>> Using a different URI, optionally, isn=E2=80=99t the problem, and that = could >>> easily be added to the. Removal of the separate handle is the problem I >>> have with the XAuth approach. >>> >> >> In XAuth, the Grant URI is the GS URI + TBD + handle >> >> Given we have asymmetric crypto as a requirement, it is unclear what >> having two pieces of random signal provide. >> >> >> Asymmetric crypto is an implementation requirement in both the input >> drafts but it isn=E2=80=99t a requirement in the charter, and there are = likely >> symmetric use cases and key proofing mechanisms that are going to be >> desirable for a lot of people. >> >> >> >>> >>> >>> >>>> >>>> Additionally, I find XAuth=E2=80=99s restrictions on the structure of = the Grant >>>> URI potentially problematic, namely that it has to start with the serv= er=E2=80=99s >>>> URL. This will lead to deployments needing to bend their setups with >>>> proxies or redirectors to make things fit, which you yourself have sai= d is >>>> going to be an issue for things like supporting a short redirect URL v= s. a >>>> long redirect URL. Your complaint there was one of latency and complex= ity, >>>> why does that not apply here? But most fundamentally, I do not see wha= t >>>> value this restriction brings to the system. If the value is coming ba= ck >>>> from the GS endpoint, and the client is getting all of its pointers fr= om >>>> there, what=E2=80=99s the point of dictating how that has to look? >>>> >>> >>> Requiring the Grant URI to start with the GS URI is open to discussion. >>> It is not clear to me why a deployment would need to have a redirector. >>> Large scale deployments I have worked on have a router / proxy that rou= tes >>> requests to internal services. Having all the URIs start with the GS UR= I >>> enables all GNAP operations to be routed in the same place. >>> >>> >>> You still haven=E2=80=99t addressed why you think that this is a reason= able >>> requirement or assumption here but not when dealing with long/short URL= s >>> for QR codes. What is the difference? >>> >> >> Short URLs generally use a short host name as well as a short path. >> >> Most REST interfaces have the pattern I am proposing. A mental model man= y >> developers are familiar with. >> >> >> This is assuming a lot on the part of the GS implementation, still, and >> all of my arguments stand. >> >> >> That is not entirely correct. A pre-registered client can still pass its >> key by value, and a dynamic client can still use a >> (dynamically-acquired) handle. In all cases, the client is identifying >> itself by its key. The difference is how the server looks up that key = =E2=80=94 >> it=E2=80=99s either from the handle, or it=E2=80=99s from the key value = itself. >> > > I don't understand this. > > How is the Client authenticating that it is a specific pre-registered > client? > > > *The client is identified by its key.* > And you think that will be an easy concept for developers to migrate to from the mental model they have now? And what is the value? I believe your proposal for other pre-registered clients to migrate was to use the Client ID as the Key Handle. So the Key Handle may represent any of the pre-registered clients, but represents each instance of a dynamic client. Does not seem like it is any different than how a Client ID is used today. Tom has started a new thread on other aspects of this section. > In XAuth, if the server wants to protect itself from a session fixation > attack in a given request, and it wants to support both "redirect" and > "user_code" modes, > the server will return only those two modes and not "indirect". The > > In XAuth, if the server wants to protect itself from a session fixation > attack in a given request, and it wants to support both "redirect" and > "user_code" modes, > the server MUST return callback, redirect, and user_code. The client does > not know that the "indirect" mode is not supported, and may try that. > > > In XYZ, if the server wants to protect against a session fixation attack, > it will reject a request that doesn=E2=80=99t have a =E2=80=9Ccallback=E2= =80=9D field in it. The AS > always gets to choose which things it supports for any given request. If > the client wants to support both =E2=80=9Credirect=E2=80=9D and =E2=80=9C= user_code=E2=80=99 modes AND has > the ability to handle session fixation issues, it sends the =E2=80=9Credi= rect=E2=80=9D, > =E2=80=9Cuser_code=E2=80=99, and =E2=80=9Ccallback=E2=80=9D fields in its= interaction request. > If the client chooses to present the interaction_url as a scannable barcode, which is an option if it receives one, it will then get an error when it tries to do a transaction continue request as the AS protects itself. Unfortunately the user has scanned the barcode and is now at the AS. I don't see how the client learns it is not able to do what I call an "indirect" mode interaction. Would you explain how this situation is prevented in XYZ? > > >> >> >> For example: >> >> How is a transaction updated? >> How are separate access tokens refreshed? >> Refreshing an access token in XYZ returns a full transaction response pe= r >> Section 9.3 which refers to Section 8. >> >> Would you address these questions? > >> >> By using URIs and methods, XAuth has an easy to understand API for CRUD >> operations on Grants and Authorizations. >> >> >> +--------------+-----------+--------+-----------------------------+ >> | request | http verb | uri | response | >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> | Create Grant | POST | GS URI | interaction, wait, or grant | >> +--------------+-----------+--------+-----------------------------+ >> | List Grants | GET | GS URI | grant list | >> +--------------+-----------+--------+-----------------------------+ >> | Verify Grant | PATCH | Grant | grant | >> | | | URI | | >> +--------------+-----------+--------+-----------------------------+ >> | Read Grant | GET | Grant | wait, or grant | >> | | | URI | | >> +--------------+-----------+--------+-----------------------------+ >> | Update Grant | PUT | Grant | interaction, wait, or grant | >> | | | URI | | >> +--------------+-----------+--------+-----------------------------+ >> | Delete Grant | DELETE | Grant | success | >> | | | URI | | >> +--------------+-----------+--------+-----------------------------+ >> | Read AuthZ | GET | AZ URI | authorization | >> +--------------+-----------+--------+-----------------------------+ >> | Update AuthZ | PUT | AZ URI | authorization | >> +--------------+-----------+--------+-----------------------------+ >> | Delete AuthZ | DELETE | AZ URI | success | >> +--------------+-----------+--------+-----------------------------+ >> | GS Options | OPTIONS | GS URI | metadata | >> +--------------+-----------+--------+-----------------------------+ >> | Grant | OPTIONS | Grant | metadata | >> | Options | | URI | | >> +--------------+-----------+--------+-----------------------------+ >> | AuthZ | OPTIONS | AZ URI | metadata | >> | Options | | | | >> +--------------+-----------+--------+-----------------------------+ >> >> >> >> >> While this looks good on paper, there are very pragmatic reasons that >> many APIs have moved away from purely RESTful patterns over the last >> decade, including limitations on what can be sent with GET and DELETE >> requests, for example. I don=E2=80=99t think it=E2=80=99s as clean a win= as you=E2=80=99re >> presenting it, but I think it=E2=80=99s worth checking out. >> > > Agreed that RESTful does not work for everything. It does look like it > maps well here. > > > I disagree that it maps well. I think this is an over-application of a > design pattern and the details will be problematic in implementation. > What aspect does not map well? What do you think will be problematic? It seems much simpler to route a request based on URI and verb(XAuth), then parse and inspect a JSON payload (XYZ) > > > >> >> >>> >>> >>>> >>>> The modes in XAuth are much more limiting, as the mixing of different >>>> interaction methods is already something that we need to start figurin= g >>>> out. Let=E2=80=99s say, for example, a client can do a redirect, accep= t a >>>> CIBA-style ping, or do a direct app2app communication. There=E2=80=99s= a natural >>>> preference the client will have here: if it can talk to another app >>>> directly, it=E2=80=99ll try that first. If that doesn=E2=80=99t work, = it can get a push >>>> notification sent, and if all that fails, it can pop open a browser. I= f >>>> I have to pick just one of those modes when I make the request, then t= he >>>> client needs to make three different requests to the AS before I get >>>> anything that works. >>>> >>> >>> Have you read the revised draft? As I noted above, I have added >>> negotiation. The Client can state all the modes it wants, the GS can >>> respond with the modes it will support, and the Client can offer the Us= er >>> any modes returned from the GS. >>> >>> >>> Yes, did you read what I wrote? I think we=E2=80=99re talking past each= other. >>> >> >> This is not how XAuth is written currently. The Client can list all of >> the modes it wants to use. The Server will return all the modes that fit= in >> its policy for the Grant Request. Why would the Client need to make >> different requests? >> >> per >> >> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.2 >> >> The interaction object contains one or more interaction mode objects per >> Section 5 >> >> Three modes are defined here: >> >> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-5 >> >> More modes may defined in extensions, or in this document. >> >> >> Yes, this is an improvement, and I=E2=80=99m glad you=E2=80=99re moving = your thinking in >> this direction. However, it=E2=80=99s still not as clear how things comb= ine to >> solve different use cases, and it conflates the means of getting the use= r >> TO the interaction page with the way of getting them BACK from it. It=E2= =80=99s >> these flexible combinations that I think are important, and I don=E2=80= =99t think >> XAuth gets this quite right yet. >> > > I think how the user gets to and from the server is CRITICAL to the serve= r > if it wants to protect itself from a session fixation attack. > See above where the client does not know what it can actually do that the > server will allow. > > > It is critical that the server knows how to protect itself, yes. It=E2=80= =99s not > critical that the way there and the way back are tightly bound to each > other in this way. I think that model is limiting. > What other way back are you envisioning there could be besides a URI redirect? Rolling between mobile apps is a URI redirect. What else could happen? I expect there will be new ways of transferring control to a GS, or that the GS will reach out to the user directly. > > > > >> >> It is an OR in that if the client is using the type "oauth_scope", they >> cannot have an "authorization_details" attribute, they can only have "sc= ope" >> >> If the client is using the type "oauth_rich", the client MUST >> include "authorization_details", and MAY include "scope" >> >> I have updated the the doc to better capture that: >> >> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.4 >> >> and example 2 now is of type "oauth_rich" >> >> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.2 >> >> >> It was not clear to me that both could be sent with that mode, so thank >> you for updating that. But the client still has to choose one or the oth= er >> up front. Why not have a mechanism that it can send both at all times? W= hy >> have a =E2=80=9Cmode=E2=80=9D type switch at all? XYZ allows clients to = make these combined >> requests with a single consistent syntax. >> >> And by completely externalizing this to OAuth 2, I would argue that we >> lose an opportunity to more clearly define how resources are described a= nd >> used, and we inherit the same combination issues that are facing RAR tod= ay. >> We can do better because we get to define the context. >> > > This group can define a new syntax if it wants, and it will be > unencumbered by the OAuth 2 and RAR legacy if deployments that want to us= e > the OAuth 2 and RAR syntax can use them directly. Ie, there can be a type > "gnap" or some such. > > You did not respond to this response. The next section I have put into a separate email. /Dick =E1=90=A7 --00000000000096d0ef05a7ac5503 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments inline

Last item wi= ll be broken out to new thread.

On Tue, Jun 9, 2020 at 9:10 AM Justin Richer= <jricher@mit.edu> wrote:
<= /div>
<= /div>

As I understand=C2=A0it, XYZ works th= e same way. The client may get a handle to the transaction in an Interactio= n Response or a Wait Response, or the client receives a transaction respons= e.

There could be only one way in XAuth (pass by r= eference), but I expect that people will prefer an optimization of pass by = value when it can be done and deal with the complexity that they may get th= e data in two different ways, just as in XYZ.
=C2=A0


=C2=A0<snip>

=C2=A0

Using a different URI, optionally, isn=E2=80=99t the problem, and that c= ould easily be added to the. Removal of the separate handle is the problem = I have with the XAuth approach.

In XAuth, the Grant URI is the GS URI=C2=A0+ TBD=C2=A0+ handle
=

Given we have asymmetric=C2=A0crypto as a requirement, = it is unclear what having two pieces of random signal=C2=A0provide.

Asymmetric crypto is an im= plementation requirement in both the input drafts but it isn=E2=80=99t a re= quirement in the charter, and there are likely symmetric use cases and key = proofing mechanisms that are going to be desirable for a lot of people.
=C2=A0

=C2=A0

Additionally, I find XAut= h=E2=80=99s restrictions on the structure of the Grant URI potentially prob= lematic, namely that it has to start with the server=E2=80=99s URL. This wi= ll lead to deployments needing to bend their setups with proxies or redirec= tors to make things fit, which you yourself have said is going to be an iss= ue for things like supporting a short redirect URL vs. a long redirect URL.= Your complaint there was one of latency and complexity, why does that not = apply here? But most fundamentally, I do not see what value this restrictio= n brings to the system. If the value is coming back from the GS endpoint, a= nd the client is getting all of its pointers from there, what=E2=80=99s the= point of dictating how that has to look?

Requiring the Grant URI to start with the GS URI is open t= o discussion. It is not clear to me why a deployment would need to have a r= edirector. Large scale deployments I have worked on have a router / proxy t= hat routes requests to internal services. Having all the URIs start with th= e GS URI enables all GNAP operations to be routed in the same place.
<= /div>

You still haven=E2=80=99t= addressed why you think that this is a reasonable requirement or assumptio= n here but not when dealing with long/short URLs for QR codes. What is the = difference?

Short URLs ge= nerally use a short host name as well as a short path.=C2=A0

=
Most REST interfaces have the pattern I am proposing. A mental m= odel many developers are familiar with.=C2=A0

This is assuming a lot on the part of the GS imp= lementation, still, and all of my arguments stand.=C2=A0


=
That is not entirely corre= ct. A pre-registered client= can still pass its key by value, and a dynamic client can still use= a (dynamically-acquired) handle. In all cases, the client is identifying i= tself by its key. The difference is how the server looks up that key =E2=80= =94 it=E2=80=99s either from the handle, or it=E2=80=99s from the key value= itself.=C2=A0

I don't understand this.=C2=A0

How is the Client authenticating that it is a specific pre-registered cli= ent?







    +--------------+-----------+--------+-----------------------------+
    | request      | http verb | uri    | response                    |
    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
    | Create Grant | POST      | GS URI | interaction, wait, or grant |
    +--------------+-----------+--------+-----------------------------+
    | List Grants  | GET       | GS URI | grant list                  |
    +--------------+-----------+--------+-----------------------------+
    | Verify Grant | PATCH     | Grant  | grant                       |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read Grant   | GET       | Grant  | wait, or grant              |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Update Grant | PUT       | Grant  | interaction, wait, or grant |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Delete Grant | DELETE    | Grant  | success                     |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read AuthZ   | GET       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Update AuthZ | PUT       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Delete AuthZ | DELETE    | AZ URI | success                     |
    +--------------+-----------+--------+-----------------------------+
    | GS Options   | OPTIONS   | GS URI | metadata                    |
    +--------------+-----------+--------+-----------------------------+
    | Grant        | OPTIONS   | Grant  | metadata                    |
    | Options      |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | AuthZ        | OPTIONS   | AZ URI | metadata                    |
    | Options      |           |        |                             |
    +--------------+-----------+--------+-----------------------------+

While this looks good on paper, there are very pragmatic reasons that many= APIs have moved away from purely RESTful patterns over the last decade, in= cluding limitations on what can be sent with GET and DELETE requests, for e= xample. I don=E2=80=99t think it=E2=80=99s as clean a win as you=E2=80=99re= presenting it, but I think it=E2=80=99s worth checking out.





It seems much simpler to route a request = based on URI and verb(XAuth), then parse and inspect a JSON payload (XYZ)
=C2=A0

=C2=A0


=C2=A0
=

=
The modes in XAuth are much more limiting, as the mixing of different = interaction methods is already something that we need to start figuring out= . Let=E2=80=99s say, for example, a client can do a redirect, accept a CIBA= -style ping, or do a direct app2app communication. There=E2=80=99s a natura= l preference the client will have here: if it can talk to another app direc= tly, it=E2=80=99ll try that first. If that doesn=E2=80=99t work, it can get= a push notification sent, and if all that fails, it can pop open a browser= . If I have to pick just on= e of those modes when I make the request, then the client needs to make thr= ee different requests to the AS before I get anything that works.=C2=A0

Have you read the rev= ised draft? As I noted above, I have added negotiation. The Client can stat= e all the modes it wants, the GS can respond with the modes it will support= , and the Client can offer the User any modes returned from the GS.

Yes, did you read what I w= rote? I think we=E2=80=99re talking past each other.

This is not how XAuth is written currently. The Client can list all= of the modes it wants to use. The Server will return all the modes that fi= t in its policy for the Grant Request. Why would the Client need to make di= fferent requests?

per



More modes may defined= in extensions, or in this document.

Yes, this is an improvement, and I=E2=80=99m glad you=E2= =80=99re moving your thinking in this direction. However, it=E2=80=99s stil= l not as clear how things combine to solve different use cases, and it conf= lates the means of getting the user TO the interaction page with the way of= getting them BACK from it. It=E2=80=99s these flexible combinations that I= think are important, and I don=E2=80=99t think XAuth gets this quite right= yet.=C2=A0

I think how t= he user gets to and from the server is CRITICAL to the server if it wants t= o protect itself from a session fixation attack.
See above where = the client does not know what it can actually do that the server will allow= .

It is critical th= at the server knows how to protect itself, yes. It=E2=80=99s not critical t= hat the way there and the way back are tightly bound to each other in this = way. I think that model is limiting.
What other way back are you envisioning there could be besides = a URI redirect?

Rolling between mobile apps is a U= RI redirect. What else could happen?

I expect ther= e will be new ways of transferring control to a GS, or that the GS will rea= ch out to the user directly.

=C2=A0

=C2=A0
<snip>
<= div dir=3D"ltr">

It is an OR = in that if the client is using the type "oauth_scope", they canno= t have an "authorization_details" attribute, they can only have &= quot;scope"

If the client is using the type &= quot;oauth_rich", the client MUST include=C2=A0"authorization_det= ails", and MAY include "scope"
=C2=A0
I = have updated the the doc to better capture that:

<= a href=3D"https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section= -3.4.4" target=3D"_blank">https://tools.ietf.org/html/draft-hardt-xauth-pro= tocol-10#section-3.4.4

and example 2 now i= s of type "oauth_rich"



It was not clear to me that both could be sent with that mode, so th= ank you for updating that. But the client still has to choose one or the ot= her up front. Why not have a mechanism that it can send both at all times? = Why have a =E2=80=9Cmode=E2=80=9D type switch at all? XYZ allows clients to= make these combined requests with a single consistent syntax.
And by completely externalizing this to OAuth 2, I would argue= that we lose an opportunity to more clearly define how resources are descr= ibed and used, and we inherit the same combination issues that are facing R= AR today. We can do better because we get to define the context.

This group can define a new syntax = if it wants, and it will be unencumbered by the OAuth 2 and RAR legacy if d= eployments that want to use the OAuth 2 and RAR syntax can use them directl= y. Ie, there can be a type "gnap" or some such.
=

You did not= respond to this response.=C2=A0

The next section = I have put into a separate email.

/Dick
=
--00000000000096d0ef05a7ac5503-- From nobody Tue Jun 9 13:15:15 2020 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 55ECB3A0789 for ; Tue, 9 Jun 2020 13:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 6H1-YN23HtVq for ; Tue, 9 Jun 2020 13:15:12 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 EBE7A3A0477 for ; Tue, 9 Jun 2020 13:15:11 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id c21so97588lfb.3 for ; Tue, 09 Jun 2020 13:15:11 -0700 (PDT) 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=LqVLK5LZKN8rMg6hhDRLURDedAuIcapQzfTF7nzpi5k=; b=r1hYxNIFjmpCBOOpCHnVhARknINl/e7pv2EHcVay0Je0Fz3eAHBPP0Bkp/x4Hgn0NT oPc7Vt2hWnWG5G82RkAGxXNpeFe1swkoEAQ28NAs86AxJZn0I5VKmf5Rj9br7s3Lq7RW o7IpKLkHANW7kNoNJJOOzusXT686f5GvrW9+mABeP1PzWAs4UgluqKFXq+xc5GZ4Nc9B tu//Xek1eg4aOqYYKbp9Rj8CLWJ+03eukbU2yIpA984E5Ot/tq3PbFz1qZgP9HXnja+T A1kHgpm6XccqJh2mOc/h202dg0Ym6t0YCgEIO52KF3yHYzaf6EasvwGAV+VCrGk00PJj ryNA== 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=LqVLK5LZKN8rMg6hhDRLURDedAuIcapQzfTF7nzpi5k=; b=LQswdjNWXvINQgH5iHnGii5Gw3hCnqy8YoZL5iz5usC+YH2wNWYURGLJVvS1bWoMLd oOHCygTDPOknqoNTKpiG4/AUmRdYZ9xVB7mn+4JyK3CkgZFTsVueVLQ56JvdX/NiaPBd FoEJSj1mPnol4sEhMee18vTfa32JkphEm5EAsK21NO7c1fV5AWl0NEEGyxXZiRY2f5w4 lA/L3jK3W4HD5wg0IbTzR9/t0opE7TuQuBQzB90Viux1WY1aAHKmSlUNP6PZLUbdOdz0 hcqfHkKhoXQwgWgHLClWaynnEptQbtvA+nmgtF0cyX6DOLsbJTLbZhxgI9xbrjOv8mZe RPlw== X-Gm-Message-State: AOAM532l4OFd74mcApphH0zM2wWlFttMTPgcQGDXhUR150V/DDG7DMJW 25ErsBNz9nMBFyaKtDt1tVep7oqJj0+MYKmwzY01n2tU5r8= X-Google-Smtp-Source: ABdhPJxqXh7tKWKMeYtYWBNZ/ZJY51kOEzkJYellfhj+oFzYhQ5TtxVbN61BYWmoCC8yoejKjcPfg7CM9CRVxG1uHKs= X-Received: by 2002:ac2:489a:: with SMTP id x26mr16384259lfc.111.1591733709910; Tue, 09 Jun 2020 13:15:09 -0700 (PDT) MIME-Version: 1.0 References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> In-Reply-To: <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> From: Dick Hardt Date: Tue, 9 Jun 2020 13:14:43 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org, Mike Jones Content-Type: multipart/alternative; boundary="0000000000005b37e505a7ac62e7" Archived-At: Subject: Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs XAuth-08) 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, 09 Jun 2020 20:15:14 -0000 --0000000000005b37e505a7ac62e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Forking this topic to a new thread +Mike as he has expressed concern about creating new identity claims On Tue, Jun 9, 2020 at 9:10 AM Justin Richer wrote: > > > On Jun 8, 2020, at 5:33 PM, Dick Hardt wrote: > > > > On Mon, Jun 8, 2020 at 1:02 PM Justin Richer wrote: > > > I don't follow how this would work. Perhaps you could provide an example >> in JSON? >> >> >> One method is defining a new value inside the XYZ =E2=80=9Cclaims=E2=80= =9D request object >> that maps to a specific sub-schema: >> >> claims: { >> =E2=80=9Csubject=E2=80=9D: true, >> =E2=80=9Cemail=E2=80=9D: true, >> =E2=80=9Coidc=E2=80=9D: { >> "userinfo": >> { >> "given_name": {"essential": true}, >> "nickname": null, >> "email": {"essential": true}, >> "email_verified": {"essential": true}, >> "picture": null, >> "http://example.info/claims/groups": null >> }, >> "id_token": >> { >> "auth_time": {"essential": true}, >> "acr": {"values": ["urn:mace:incommon:iap:silver"] } >> } >> } >> } >> >> >> That should look pretty familiar. Alternatively, this could be done with >> a separate top-level request object field: >> >> >> claims: { >> =E2=80=9Csubject=E2=80=9D: true, >> =E2=80=9Cemail=E2=80=9D: true >> }, >> =E2=80=9Coidc_claims_request=E2=80=9D: { >> "userinfo": >> { >> "given_name": {"essential": true}, >> "nickname": null, >> "email": {"essential": true}, >> "email_verified": {"essential": true}, >> "picture": null, >> "http://example.info/claims/groups": null >> }, >> "id_token": >> { >> "auth_time": {"essential": true}, >> "acr": {"values": ["urn:mace:incommon:iap:silver"] } >> } >> } >> >> >> In both cases the AS is going to need to knit them together into a >> sensible request policy, especially since the OIDC claims query language >> has overlapping implications to one particular resource, the UserInfo >> endpoint. My contention wasn=E2=80=99t with your proposed solution, my c= ontention >> was you claiming that XYZ has a fixed schema and is therefore limited in >> extensibility. >> > > One of the objectives of this work is to have extension points. My point > was that XAuth had a clear extension point for adding schemas. How to > extend XYZ was not clear in your proposal. > > > I am sorry that the extensibility of the protocol was not clear. It is > stated in each section that additional items can be added, and I have > stated repeatedly that it=E2=80=99s extensible and demonstrated how, here= on this > list. > > I think the XAuth proposal is better than the two examples you proposed. > In your first example, the schema is a second class schema, and in your > second example, claims are spread across to top level options. Both of > these pollute other schemas. > > > Not surprisingly, I disagree about the cleanliness of XAuth=E2=80=99s pro= posed > approach. The proposal here adds external schemas as extensions instead o= f > relying on them internally. > > If anything, I think that the OpenID Foundation would be the ones to > define how to make an OIDC claims request using this protocol, not us, > since they own and control that query syntax and everything it implies. W= e > can provide a means of extension. > > I also think there=E2=80=99s value in defining a set of core interoperabl= e > identity fields, which themselves could also be extended. > > All of these mechanisms should be controlled by some combination of > registries and collision-resistant namespaces, which is the approach I=E2= =80=99ve > taken for extensibility throughout XYZ. > JSON by its nature is extensible. Adding new members to an object is straight forward. XYZ is not unique here. It sounds like your idea of extensibility is telling people that they can add new members to JSON. Of course they can. That is like saying you can add new query parameters to a front channel OAuth 2 request. My concern was that XYZ does not have a clear way to add new identity claim schemas. You have two examples, add a schema as a member of the claims object, which is mixing claims with schema extensions, or adding a root member, which is then putting claims into more than one place. It is not clear where to add a new schema, so we could easily end up with new schemas in both places. That sounds confusing. In XAuth, the members of the claims object are the schema. Adding a new schema is done one, consistent way. wrt. "defining a set of core interoperable identity fields", the charter says we should be NOT develop a new schema: The group is chartered to develop mechanisms for conveying identity information within the protocol including identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available. wrt. OIDC claims, the charter explicitly calls out developing mechanisms for conveying ... OIDC ID Tokens. =E1=90=A7 --0000000000005b37e505a7ac62e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forking this topic to a new thread

+Mike as he has expressed concern about = creating new identity claims

On Tue, Jun 9, 2020 at 9:10 AM J= ustin Richer <jricher@mit.edu>= wrote:


On Jun 8, 2020, at 5:33 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

<= div>


On Mon, Jun 8, 2020 at 1:02 PM Ju= stin Richer <jriche= r@mit.edu> wrote:

<snip>= ;=C2=A0
=
I don't follow how this would work. Perhaps = you could provide an example in JSON?
<= div>
One method is defining a new value inside the XYZ =E2=80= =9Cclaims=E2=80=9D request object that maps to a specific sub-schema:
=

claims: {
=C2=A0 =C2=A0=E2= =80=9Csubject=E2=80=9D: true,
=C2=A0 =C2=A0=E2=80=9Cem= ail=E2=80=9D: true,
=C2=A0 =C2=A0=E2=80=9Coidc=E2=80= =9D: {
=C2=A0 =C2=A0 =C2=A0 =C2=A0"userinfo"= :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"given_name": {"essential&= quot;: true},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"= nickname": null,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0"email": {"essential": true},
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"email_verified": {"essent= ial": true},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&q= uot;picture": null,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"http://example.info/claims/groups": null
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2= =A0"id_token":
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"auth_time&quo= t;: {"essential": true},
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0"acr": {"values": ["urn:mace:inco= mmon:iap:silver"] }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }=
=C2=A0 =C2=A0 =C2=A0 }
}

That should look pretty familiar.= Alternatively, this could be done with a separate top-level request object= field:


claims: {
<= div>
=C2=A0 =C2=A0=E2=80=9Csubject=E2=80=9D: true,
=C2=A0 =C2=A0=E2=80=9Cemail=E2=80=9D: true
},
=E2=80=9Coidc_claims_request=E2=80=9D: {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0"userinfo":
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"given_name": {"= essential": true},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"n= ickname": null,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"emai= l": {"essential": true},
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0"email_verified": {"essential": true},
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"picture": null,
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"http://example.info/claims/groups": n= ull
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0= =C2=A0"id_token":
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"auth_time": {"essenti= al": true},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"acr"= ;: {"values": ["urn:mace:incommon:iap:silver"] }
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
}
=

In both cases the AS is going to need to knit the= m together into a sensible request policy, especially since the OIDC claims= query language has overlapping implications to one particular resource, th= e UserInfo endpoint. My contention wasn=E2=80=99t with your proposed soluti= on, my contention was you claiming that XYZ has a fixed schema and is there= fore limited in extensibility.

One of the objectives of this work is to have extension points. My po= int was that XAuth had a clear extension point for adding schemas. How to e= xtend XYZ was not clear in=C2=A0your proposal.


I am sorry that the extensibilit= y of the protocol was not clear. It is stated in each section that addition= al items can be added, and I have stated repeatedly that it=E2=80=99s exten= sible and demonstrated how, here on this list.=C2=A0

I think = the XAuth proposal is better than the two examples you proposed. In your fi= rst example, the schema is a second class schema, and in your second exampl= e, claims are spread across to top level options. Both of these pollute oth= er schemas.


Not surprisingly, I disagree about the cleanliness of XAuth=E2=80= =99s proposed approach. The proposal here adds external schemas as extensio= ns instead of relying on them internally.=C2=A0

If= anything, I think that the OpenID Foundation would be the ones to define h= ow to make an OIDC claims request using this protocol, not us, since they o= wn and control that query syntax and everything it implies. We can provide = a means of extension.

I also think there=E2=80=99s= value in defining a set of core interoperable identity fields, which thems= elves could also be extended.=C2=A0

All of these m= echanisms should be controlled by some combination of registries and collis= ion-resistant namespaces, which is the approach I=E2=80=99ve taken for exte= nsibility throughout XYZ.


JSON by its nature is extensible. Adding new members to an = object is straight forward. XYZ is not unique here. It sounds like your ide= a of extensibility=C2=A0is telling people that they can add new members to = JSON. Of course they can. That is like saying you can add new query paramet= ers to a front channel OAuth 2 request.

My concern= was that XYZ does not have a clear way to add new identity claim schemas. = You have two examples, add a schema as a member of the claims object, which= is mixing claims with schema extensions, or adding a root member, which is= then putting claims into more than one place. It is not clear where to add= a new schema, so we could easily end up with new schemas in both places. T= hat sounds confusing.

In XAuth, the members of the= claims object are the schema. Adding a new schema is done one, consistent = way.

wrt. "defining a set of core interoperab= le identity fields", the charter says we should be NOT develop a new schema:
The group is chartered to develop mechanisms for conveying identity in= formation within the protocol including identifiers (such as email a= ddresses, phone numbers, usernames, and subject identifiers) and assertions= (such as OpenID Connect ID T= okens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new = formats for identifiers or assertions, nor is the group chartered to develo= p schemas for user information, profiles, or other identity attributes, unl= ess a viable existing format is not available.

wrt. OIDC claims, the cha= rter explicitly calls out dev= eloping mechanisms for conveying ... OIDC ID Tokens.

<= /div>
=E1=90=A7
--0000000000005b37e505a7ac62e7-- From nobody Tue Jun 9 13:47:14 2020 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 B34043A0861 for ; Tue, 9 Jun 2020 13:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMgnwdUVdCPc for ; Tue, 9 Jun 2020 13:47:10 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640097.outbound.protection.outlook.com [40.107.64.97]) (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 5EDD53A0853 for ; Tue, 9 Jun 2020 13:47:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N1D2ntvxlwladVjCV/DvK/IKgXp4Q2hR3mNW22pgWaEQz8h4rf/1JLUZOLZSkbWJXqV0pM2v3ris5aIxdmBx9uQSI9+vDIH2t3s//7S7SZjFqkCGLSShRFCnQbIDJPPrIotrJSxMYMFFZP2vc9HGygRpaVEFRECTsknBZFJMbfiMTl0xJWjMthMJK46zEqKetNVbE57g37cKXzjNBG22XszriE3NlnYtMJv0vsuab8HmzgNcDpcFQ2/PwF7tEbhgWP85n0t+DBqrIIJB3aTBQpO8apLbbrBitWUtPmI0DZlVxsFf1RRCjnDQdhNt758JutSPgyjAOCM9JE8dwkBYWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wVlk+bUAjqKHNuH/JpRazSm3OiIszNGPSrUUvFR+tK4=; b=D+JB2oVvo8RmzxLA2ciKVoGcxiKjEMasfT7eZtJDkctOhqVD8ZMg88KfN/bHx08kwMk0rnraorVTfhxA2RgDGPlg8uf3Re4u6a7vEM1+t1Q2EXXgWbtT4n7y4Yut0bUVPjXF3gKDG8agWT+SAbJ9oaOk0gNaDmp0WiLgk33DgKaOqdV7bZymj122CIAE/lLg8fUMuwXRP2K3G25Hc9qfvZwrjHJTl7hsP5JO2EiQ5Fq86wGbalY120VoENqjKTwFjDrY8vHTL65Co87jpLxuYMaLFaoIbUTJF+Q85gK+J+Si6Wagt+FrpsrqhjqkxgEvYozzpGhbFjezPxc9/dZSsA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wVlk+bUAjqKHNuH/JpRazSm3OiIszNGPSrUUvFR+tK4=; b=jRqYs02pvWtkrXCXFNWWbx4dt1sc4+3EzpqWWwontImPw2G0v4FNxYFkp6u1OLDgJT/gmVNtYnCV7LBog/U13sIgrBzQFh93/ZU8xkN1m5IwQ0uiyhckQF+rq4CcA4tvvfgQrnXZGSJQ7A5oWYUbNh1e31V5YWwuFG8dzWzQKjc= Received: from DM6PR00MB0684.namprd00.prod.outlook.com (2603:10b6:5:21c::8) by DM6PR00MB0714.namprd00.prod.outlook.com (2603:10b6:5:21c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3124.0; Tue, 9 Jun 2020 20:47:08 +0000 Received: from DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::21bc:a480:7957:24c6]) by DM6PR00MB0684.namprd00.prod.outlook.com ([fe80::21bc:a480:7957:24c6%7]) with mapi id 15.20.3124.000; Tue, 9 Jun 2020 20:47:08 +0000 From: Mike Jones To: Dick Hardt , Justin Richer CC: "txauth@ietf.org" Thread-Topic: [Txauth] adding identity claim schemas (was: XYZ-08 vs XAuth-08) Thread-Index: AdY+nyDE+KAM8Ye6Tze6NUG0x+iTOg== Date: Tue, 9 Jun 2020 20:47:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=2f7d37fb-6ada-4ed0-8f30-0000f715672b; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-09T20:33:12Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8ceef798-3e84-4960-48b4-08d80cb646c2 x-ms-traffictypediagnostic: DM6PR00MB0714: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 042957ACD7 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BDCA2aoxcSWS2Wut1yKuItJf9R2oA2Ey9+1fR1ilmmoZDcElOXB1R83UGS035jKne22foB+ithu9C2heVrqYAaV38CcW0JClorQHyPGn2Wglx+xf9BNfyRfi+wnfbzwHNOFv5P6n7TXbEP3JoF6Klv4zGuK8BGMuQwcb3Oz9Epbaff9msk/bEvs3ULf09NUUxdj0gtTCnYzbfGtsBlPOzAyL9KdSk5DX3I/YnOm4woe67tlGqCrCa+N0AOtjmA01FybYEB0FFKBqvNkFmVTl9hQgfF6kciEsTrXGypubf15Qo7VOZ4Xaf4QikkEgUcWfVviUEetZT8fEI4/ibrKsMzI2HI5NmtbfdVpXT02IBa4bPQPY1/XC/EHEOIpH0yKq8SyIZ3drYu2jDUtaUvfs6tGrggSFB4UARm54U+hQP8hU4AnDXcihHwiopdOcFmZIvqiZ8fPGX/6OfbRG6Eq6qGtSYs9s4zFM6VO1ZHHs+tHmOfzeJN7NH6JFfwpfbU+P x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR00MB0684.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(136003)(376002)(366004)(39860400002)(209900001)(8936002)(82950400001)(166002)(55016002)(66446008)(64756008)(66556008)(66946007)(76116006)(83080400001)(110136005)(8990500004)(82960400001)(76236002)(71200400001)(478600001)(66476007)(53546011)(52536014)(26005)(33656002)(186003)(4326008)(7696005)(86362001)(6506007)(316002)(8676002)(9686003)(83380400001)(5660300002)(19273905006)(2906002)(10290500003)(99710200001)(563064011)(6606295002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: +6xPujP3Xayf63u3I9u12sfRkNUlFpQlX/qqbFYE2OF3jR9F2DLXmLT9JL30VKPkKjQCmGVrYlULq89DEE2Z5yQfZtVYoKn0K5adJdIYSUwvXyt3oUrKt8c0JekHaJEn4Rb1EbU3mqiC+MR86Qis5xDkI7XViiXt74dZ9IVqfCv80dxB+pSWPnztjpOVWdxbh3sv0IYrm6wTYcOFT3GwDJCN/++6QZb1nm9sWhzMPoMkCcAwdw8xTyymYfaRC8eBJ8FY200S9HOAlMYoNXQSP27FAfZhpxQN+L8cvYfBNfaDeBeitmN+K07cXSwrDgMRLnkHQSt6PQXeB3crd1HmZ7gteOlZ/HIJg6LcDOBHUCF8heVb1DdUyb1/Xq1z/HgcZXQd3TLGOnKpOmLH+h0b7veae3KE5TrbJHKUuLbYsqxsiI1cERuiXJKYAbtc2YpjYzQKQZLnadWrHg500ekNNC6PKnwLET41SpYoMjW/zM4= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR00MB06846ED1BA34EBC8E3D31266F5820DM6PR00MB0684namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8ceef798-3e84-4960-48b4-08d80cb646c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2020 20:47:08.3335 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vWakqas3FPJC9htL3gbFBqocZ4Y4aSAJ0J78CdGvl2CMznqF/YV2Oq7LOtOeSsNzh7SEX4VlwhHHYMckT6yrFw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR00MB0714 Archived-At: Subject: Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs XAuth-08) 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, 09 Jun 2020 20:47:13 -0000 --_000_DM6PR00MB06846ED1BA34EBC8E3D31266F5820DM6PR00MB0684namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IGV4cGxpY2l0bHkgcmV1c2luZyBleGlzdGluZyBjbGFpbXMgc2NoZW1hcywg cmF0aGVyIHRoYW4gaW52ZW50aW5nIG5ldyBvbmVzLCBpcyBvbmUgb2YgdGhlIGNsZWFyIGFuZCBj b21wZWxsaW5nIGFkdmFudGFnZXMgb2YgWEF1dGggb3ZlciBYWVouICBJ4oCZZCBwcmV2aW91c2x5 IHN1Z2dlc3RlZCB0aGF0IHRoZSBDbGFpbXMgc2VjdGlvbiBvZiBYWVo8aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci10cmFuc2FjdGlvbmFsLWF1dGh6LTA4I3NlY3Rpb24t Mi43PiBiZSByZXZpc2VkIHRvIG5vdCBkZWZpbmUgbmV3IOKAnGVtYWls4oCdIGFuZCDigJxzdWJq ZWN04oCdIGNsYWltcyB3aXRoIGFuIHVua25vd24gc2NoZW1hIGJ1dCB0aGF0IGhhc27igJl0IGJl ZW4gZG9uZS4gIE90aGVyIGluc3RhbmNlcyBvZiB0aGlzIHByb2JsZW0gb2NjdXIgaW4gdGhlIFhZ WiBUcmFuc2FjdGlvbiBSZXF1ZXN0PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1y aWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei0wOCNzZWN0aW9uLTI+IGFuZCBUcmFuc2FjdGlvbiBS ZXNwb25zZTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLXRyYW5zYWN0 aW9uYWwtYXV0aHotMDgjc2VjdGlvbi04PiBzZWN0aW9ucy4NCg0KR2V0dGluZyB0aGlzIHJpZ2h0 IG1hdHRlcnMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwu Y29tPg0KU2VudDogVHVlc2RheSwgSnVuZSA5LCAyMDIwIDE6MTUgUE0NClRvOiBKdXN0aW4gUmlj aGVyIDxqcmljaGVyQG1pdC5lZHU+DQpDYzogdHhhdXRoQGlldGYub3JnOyBNaWtlIEpvbmVzIDxN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBSZTogW1R4YXV0aF0gYWRkaW5n IGlkZW50aXR5IGNsYWltIHNjaGVtYXMgKHdhczogWFlaLTA4IHZzIFhBdXRoLTA4KQ0KDQpGb3Jr aW5nIHRoaXMgdG9waWMgdG8gYSBuZXcgdGhyZWFkDQoNCitNaWtlIGFzIGhlIGhhcyBleHByZXNz ZWQgY29uY2VybiBhYm91dCBjcmVhdGluZyBuZXcgaWRlbnRpdHkgY2xhaW1zDQoNCk9uIFR1ZSwg SnVuIDksIDIwMjAgYXQgOToxMCBBTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFp bHRvOmpyaWNoZXJAbWl0LmVkdT4+IHdyb3RlOg0KDQoNCg0KT24gSnVuIDgsIDIwMjAsIGF0IDU6 MzMgUE0sIERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29tPG1haWx0bzpkaWNrLmhhcmR0 QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCg0KT24gTW9uLCBKdW4gOCwgMjAyMCBhdCAxOjAyIFBN IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4g d3JvdGU6DQoNCjxzbmlwPg0KSSBkb24ndCBmb2xsb3cgaG93IHRoaXMgd291bGQgd29yay4gUGVy aGFwcyB5b3UgY291bGQgcHJvdmlkZSBhbiBleGFtcGxlIGluIEpTT04/DQoNCk9uZSBtZXRob2Qg aXMgZGVmaW5pbmcgYSBuZXcgdmFsdWUgaW5zaWRlIHRoZSBYWVog4oCcY2xhaW1z4oCdIHJlcXVl c3Qgb2JqZWN0IHRoYXQgbWFwcyB0byBhIHNwZWNpZmljIHN1Yi1zY2hlbWE6DQoNCmNsYWltczog ew0KICAg4oCcc3ViamVjdOKAnTogdHJ1ZSwNCiAgIOKAnGVtYWls4oCdOiB0cnVlLA0KICAg4oCc b2lkY+KAnTogew0KICAgICAgICJ1c2VyaW5mbyI6DQogICAgICAgIHsNCiAgICAgICAgICJnaXZl bl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgICAgICJuaWNrbmFtZSI6IG51bGws DQogICAgICAgICAiZW1haWwiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0KICAgICAgICAgImVtYWls X3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgICAgICJwaWN0dXJlIjogbnVs bCwNCiAgICAgICAgICJodHRwOi8vZXhhbXBsZS5pbmZvL2NsYWltcy9ncm91cHMiOiBudWxsDQog ICAgICAgIH0sDQogICAgICAgImlkX3Rva2VuIjoNCiAgICAgICAgew0KICAgICAgICAgImF1dGhf dGltZSI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBb InVybjptYWNlOmluY29tbW9uOmlhcDpzaWx2ZXIiXSB9DQogICAgICAgIH0NCiAgICAgIH0NCn0N Cg0KVGhhdCBzaG91bGQgbG9vayBwcmV0dHkgZmFtaWxpYXIuIEFsdGVybmF0aXZlbHksIHRoaXMg Y291bGQgYmUgZG9uZSB3aXRoIGEgc2VwYXJhdGUgdG9wLWxldmVsIHJlcXVlc3Qgb2JqZWN0IGZp ZWxkOg0KDQoNCmNsYWltczogew0KICAg4oCcc3ViamVjdOKAnTogdHJ1ZSwNCiAgIOKAnGVtYWls 4oCdOiB0cnVlDQp9LA0K4oCcb2lkY19jbGFpbXNfcmVxdWVzdOKAnTogew0KICAgICAgICJ1c2Vy aW5mbyI6DQogICAgICAgIHsNCiAgICAgICAgICJnaXZlbl9uYW1lIjogeyJlc3NlbnRpYWwiOiB0 cnVlfSwNCiAgICAgICAgICJuaWNrbmFtZSI6IG51bGwsDQogICAgICAgICAiZW1haWwiOiB7ImVz c2VudGlhbCI6IHRydWV9LA0KICAgICAgICAgImVtYWlsX3ZlcmlmaWVkIjogeyJlc3NlbnRpYWwi OiB0cnVlfSwNCiAgICAgICAgICJwaWN0dXJlIjogbnVsbCwNCiAgICAgICAgICJodHRwOi8vZXhh bXBsZS5pbmZvL2NsYWltcy9ncm91cHMiOiBudWxsDQogICAgICAgIH0sDQogICAgICAgImlkX3Rv a2VuIjoNCiAgICAgICAgew0KICAgICAgICAgImF1dGhfdGltZSI6IHsiZXNzZW50aWFsIjogdHJ1 ZX0sDQogICAgICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOmluY29tbW9uOmlhcDpz aWx2ZXIiXSB9DQogICAgICAgIH0NCn0NCg0KSW4gYm90aCBjYXNlcyB0aGUgQVMgaXMgZ29pbmcg dG8gbmVlZCB0byBrbml0IHRoZW0gdG9nZXRoZXIgaW50byBhIHNlbnNpYmxlIHJlcXVlc3QgcG9s aWN5LCBlc3BlY2lhbGx5IHNpbmNlIHRoZSBPSURDIGNsYWltcyBxdWVyeSBsYW5ndWFnZSBoYXMg b3ZlcmxhcHBpbmcgaW1wbGljYXRpb25zIHRvIG9uZSBwYXJ0aWN1bGFyIHJlc291cmNlLCB0aGUg VXNlckluZm8gZW5kcG9pbnQuIE15IGNvbnRlbnRpb24gd2FzbuKAmXQgd2l0aCB5b3VyIHByb3Bv c2VkIHNvbHV0aW9uLCBteSBjb250ZW50aW9uIHdhcyB5b3UgY2xhaW1pbmcgdGhhdCBYWVogaGFz IGEgZml4ZWQgc2NoZW1hIGFuZCBpcyB0aGVyZWZvcmUgbGltaXRlZCBpbiBleHRlbnNpYmlsaXR5 Lg0KDQpPbmUgb2YgdGhlIG9iamVjdGl2ZXMgb2YgdGhpcyB3b3JrIGlzIHRvIGhhdmUgZXh0ZW5z aW9uIHBvaW50cy4gTXkgcG9pbnQgd2FzIHRoYXQgWEF1dGggaGFkIGEgY2xlYXIgZXh0ZW5zaW9u IHBvaW50IGZvciBhZGRpbmcgc2NoZW1hcy4gSG93IHRvIGV4dGVuZCBYWVogd2FzIG5vdCBjbGVh ciBpbiB5b3VyIHByb3Bvc2FsLg0KDQoNCkkgYW0gc29ycnkgdGhhdCB0aGUgZXh0ZW5zaWJpbGl0 eSBvZiB0aGUgcHJvdG9jb2wgd2FzIG5vdCBjbGVhci4gSXQgaXMgc3RhdGVkIGluIGVhY2ggc2Vj dGlvbiB0aGF0IGFkZGl0aW9uYWwgaXRlbXMgY2FuIGJlIGFkZGVkLCBhbmQgSSBoYXZlIHN0YXRl ZCByZXBlYXRlZGx5IHRoYXQgaXTigJlzIGV4dGVuc2libGUgYW5kIGRlbW9uc3RyYXRlZCBob3cs IGhlcmUgb24gdGhpcyBsaXN0Lg0KDQoNCkkgdGhpbmsgdGhlIFhBdXRoIHByb3Bvc2FsIGlzIGJl dHRlciB0aGFuIHRoZSB0d28gZXhhbXBsZXMgeW91IHByb3Bvc2VkLiBJbiB5b3VyIGZpcnN0IGV4 YW1wbGUsIHRoZSBzY2hlbWEgaXMgYSBzZWNvbmQgY2xhc3Mgc2NoZW1hLCBhbmQgaW4geW91ciBz ZWNvbmQgZXhhbXBsZSwgY2xhaW1zIGFyZSBzcHJlYWQgYWNyb3NzIHRvIHRvcCBsZXZlbCBvcHRp b25zLiBCb3RoIG9mIHRoZXNlIHBvbGx1dGUgb3RoZXIgc2NoZW1hcy4NCg0KDQpOb3Qgc3VycHJp c2luZ2x5LCBJIGRpc2FncmVlIGFib3V0IHRoZSBjbGVhbmxpbmVzcyBvZiBYQXV0aOKAmXMgcHJv cG9zZWQgYXBwcm9hY2guIFRoZSBwcm9wb3NhbCBoZXJlIGFkZHMgZXh0ZXJuYWwgc2NoZW1hcyBh cyBleHRlbnNpb25zIGluc3RlYWQgb2YgcmVseWluZyBvbiB0aGVtIGludGVybmFsbHkuDQoNCklm IGFueXRoaW5nLCBJIHRoaW5rIHRoYXQgdGhlIE9wZW5JRCBGb3VuZGF0aW9uIHdvdWxkIGJlIHRo ZSBvbmVzIHRvIGRlZmluZSBob3cgdG8gbWFrZSBhbiBPSURDIGNsYWltcyByZXF1ZXN0IHVzaW5n IHRoaXMgcHJvdG9jb2wsIG5vdCB1cywgc2luY2UgdGhleSBvd24gYW5kIGNvbnRyb2wgdGhhdCBx dWVyeSBzeW50YXggYW5kIGV2ZXJ5dGhpbmcgaXQgaW1wbGllcy4gV2UgY2FuIHByb3ZpZGUgYSBt ZWFucyBvZiBleHRlbnNpb24uDQoNCkkgYWxzbyB0aGluayB0aGVyZeKAmXMgdmFsdWUgaW4gZGVm aW5pbmcgYSBzZXQgb2YgY29yZSBpbnRlcm9wZXJhYmxlIGlkZW50aXR5IGZpZWxkcywgd2hpY2gg dGhlbXNlbHZlcyBjb3VsZCBhbHNvIGJlIGV4dGVuZGVkLg0KDQpBbGwgb2YgdGhlc2UgbWVjaGFu aXNtcyBzaG91bGQgYmUgY29udHJvbGxlZCBieSBzb21lIGNvbWJpbmF0aW9uIG9mIHJlZ2lzdHJp ZXMgYW5kIGNvbGxpc2lvbi1yZXNpc3RhbnQgbmFtZXNwYWNlcywgd2hpY2ggaXMgdGhlIGFwcHJv YWNoIEnigJl2ZSB0YWtlbiBmb3IgZXh0ZW5zaWJpbGl0eSB0aHJvdWdob3V0IFhZWi4NCg0KDQpK U09OIGJ5IGl0cyBuYXR1cmUgaXMgZXh0ZW5zaWJsZS4gQWRkaW5nIG5ldyBtZW1iZXJzIHRvIGFu IG9iamVjdCBpcyBzdHJhaWdodCBmb3J3YXJkLiBYWVogaXMgbm90IHVuaXF1ZSBoZXJlLiBJdCBz b3VuZHMgbGlrZSB5b3VyIGlkZWEgb2YgZXh0ZW5zaWJpbGl0eSBpcyB0ZWxsaW5nIHBlb3BsZSB0 aGF0IHRoZXkgY2FuIGFkZCBuZXcgbWVtYmVycyB0byBKU09OLiBPZiBjb3Vyc2UgdGhleSBjYW4u IFRoYXQgaXMgbGlrZSBzYXlpbmcgeW91IGNhbiBhZGQgbmV3IHF1ZXJ5IHBhcmFtZXRlcnMgdG8g YSBmcm9udCBjaGFubmVsIE9BdXRoIDIgcmVxdWVzdC4NCg0KTXkgY29uY2VybiB3YXMgdGhhdCBY WVogZG9lcyBub3QgaGF2ZSBhIGNsZWFyIHdheSB0byBhZGQgbmV3IGlkZW50aXR5IGNsYWltIHNj aGVtYXMuIFlvdSBoYXZlIHR3byBleGFtcGxlcywgYWRkIGEgc2NoZW1hIGFzIGEgbWVtYmVyIG9m IHRoZSBjbGFpbXMgb2JqZWN0LCB3aGljaCBpcyBtaXhpbmcgY2xhaW1zIHdpdGggc2NoZW1hIGV4 dGVuc2lvbnMsIG9yIGFkZGluZyBhIHJvb3QgbWVtYmVyLCB3aGljaCBpcyB0aGVuIHB1dHRpbmcg Y2xhaW1zIGludG8gbW9yZSB0aGFuIG9uZSBwbGFjZS4gSXQgaXMgbm90IGNsZWFyIHdoZXJlIHRv IGFkZCBhIG5ldyBzY2hlbWEsIHNvIHdlIGNvdWxkIGVhc2lseSBlbmQgdXAgd2l0aCBuZXcgc2No ZW1hcyBpbiBib3RoIHBsYWNlcy4gVGhhdCBzb3VuZHMgY29uZnVzaW5nLg0KDQpJbiBYQXV0aCwg dGhlIG1lbWJlcnMgb2YgdGhlIGNsYWltcyBvYmplY3QgYXJlIHRoZSBzY2hlbWEuIEFkZGluZyBh IG5ldyBzY2hlbWEgaXMgZG9uZSBvbmUsIGNvbnNpc3RlbnQgd2F5Lg0KDQp3cnQuICJkZWZpbmlu ZyBhIHNldCBvZiBjb3JlIGludGVyb3BlcmFibGUgaWRlbnRpdHkgZmllbGRzIiwgdGhlIGNoYXJ0 ZXIgc2F5cyB3ZSBzaG91bGQgYmUgTk9UIGRldmVsb3AgYSBuZXcgc2NoZW1hOg0KDQpUaGUgZ3Jv dXAgaXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgbWVjaGFuaXNtcyBmb3IgY29udmV5aW5nIGlkZW50 aXR5IGluZm9ybWF0aW9uIHdpdGhpbiB0aGUgcHJvdG9jb2wgaW5jbHVkaW5nIGlkZW50aWZpZXJz IChzdWNoIGFzIGVtYWlsIGFkZHJlc3NlcywgcGhvbmUgbnVtYmVycywgdXNlcm5hbWVzLCBhbmQg c3ViamVjdCBpZGVudGlmaWVycykgYW5kIGFzc2VydGlvbnMgKHN1Y2ggYXMgT3BlbklEIENvbm5l Y3QgSUQgVG9rZW5zLCBTQU1MIEFzc2VydGlvbnMsIGFuZCBWZXJpZmlhYmxlIENyZWRlbnRpYWxz KS4gVGhlIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQgdG8gZGV2ZWxvcCBuZXcgZm9ybWF0cyBmb3Ig aWRlbnRpZmllcnMgb3IgYXNzZXJ0aW9ucywgbm9yIGlzIHRoZSBncm91cCBjaGFydGVyZWQgdG8g ZGV2ZWxvcCBzY2hlbWFzIGZvciB1c2VyIGluZm9ybWF0aW9uLCBwcm9maWxlcywgb3Igb3RoZXIg aWRlbnRpdHkgYXR0cmlidXRlcywgdW5sZXNzIGEgdmlhYmxlIGV4aXN0aW5nIGZvcm1hdCBpcyBu b3QgYXZhaWxhYmxlLg0KDQp3cnQuIE9JREMgY2xhaW1zLCB0aGUgY2hhcnRlciBleHBsaWNpdGx5 IGNhbGxzIG91dCBkZXZlbG9waW5nIG1lY2hhbmlzbXMgZm9yIGNvbnZleWluZyAuLi4gT0lEQyBJ RCBUb2tlbnMuDQoNCuGQpw0K --_000_DM6PR00MB06846ED1BA34EBC8E3D31266F5820DM6PR00MB0684namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ SSBhZ3JlZSB0aGF0IGV4cGxpY2l0bHkgcmV1c2luZyBleGlzdGluZyBjbGFpbXMgc2NoZW1hcywg cmF0aGVyIHRoYW4gaW52ZW50aW5nIG5ldyBvbmVzLCBpcyBvbmUgb2YgdGhlIGNsZWFyIGFuZCBj b21wZWxsaW5nIGFkdmFudGFnZXMgb2YgWEF1dGggb3ZlciBYWVouJm5ic3A7IEnigJlkIHByZXZp b3VzbHkgc3VnZ2VzdGVkIHRoYXQgdGhlDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtcmljaGVyLXRyYW5zYWN0aW9uYWwtYXV0aHotMDgjc2VjdGlvbi0yLjciPg0K Q2xhaW1zIHNlY3Rpb24gb2YgWFlaPC9hPiBiZSByZXZpc2VkIHRvIG5vdCBkZWZpbmUgbmV3IOKA nGVtYWls4oCdIGFuZCDigJxzdWJqZWN04oCdIGNsYWltcyB3aXRoIGFuIHVua25vd24gc2NoZW1h IGJ1dCB0aGF0IGhhc27igJl0IGJlZW4gZG9uZS4mbmJzcDsgT3RoZXIgaW5zdGFuY2VzIG9mIHRo aXMgcHJvYmxlbSBvY2N1ciBpbiB0aGUgWFlaDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtcmljaGVyLXRyYW5zYWN0aW9uYWwtYXV0aHotMDgjc2VjdGlvbi0yIj4N ClRyYW5zYWN0aW9uIFJlcXVlc3Q8L2E+IGFuZCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtcmljaGVyLXRyYW5zYWN0aW9uYWwtYXV0aHotMDgjc2VjdGlvbi04Ij4N ClRyYW5zYWN0aW9uIFJlc3BvbnNlPC9hPiBzZWN0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDIwNjAiPkdldHRpbmcgdGhpcyByaWdodCBtYXR0ZXJzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwuY29tJmd0OyA8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgSnVuZSA5LCAyMDIwIDE6MTUgUE08YnI+DQo8Yj5Ubzo8L2I+IEp1 c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDs8YnI+DQo8Yj5DYzo8L2I+IHR4YXV0 aEBpZXRmLm9yZzsgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1R4YXV0aF0gYWRkaW5nIGlkZW50aXR5IGNsYWlt IHNjaGVtYXMgKHdhczogWFlaLTA4IHZzIFhBdXRoLTA4KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9ya2luZyB0aGlzIHRvcGljIHRvIGEgbmV3IHRocmVh ZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m IzQzO01pa2UgYXMgaGUgaGFzIGV4cHJlc3NlZCBjb25jZXJuIGFib3V0IGNyZWF0aW5nIG5ldyBp ZGVudGl0eSBjbGFpbXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVuIDksIDIwMjAgYXQgOToxMCBBTSBKdXN0aW4g UmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQuZWR1Ij5qcmljaGVyQG1pdC5l ZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEp1biA4LCAyMDIwLCBhdCA1OjMzIFBNLCBEaWNrIEhh cmR0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdW4gOCwgMjAyMCBhdCAx OjAyIFBNIEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUi IHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZsdDtzbmlwJmd0OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgZG9uJ3QgZm9sbG93IGhvdyB0aGlzIHdvdWxkIHdvcmsuIFBlcmhhcHMgeW91IGNvdWxkIHBy b3ZpZGUgYW4gZXhhbXBsZSBpbiBKU09OPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbmUgbWV0aG9kIGlzIGRlZmluaW5nIGEgbmV3IHZhbHVlIGluc2lkZSB0aGUgWFlaIOKA nGNsYWltc+KAnSByZXF1ZXN0IG9iamVjdCB0aGF0IG1hcHMgdG8gYSBzcGVjaWZpYyBzdWItc2No ZW1hOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Y2xhaW1zOiB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A74oCcc3Vi amVjdOKAnTogdHJ1ZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDvigJxlbWFpbOKAnTogdHJ1ZSw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDvigJxvaWRj4oCdOiB7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmcXVvdDt1c2VyaW5mbyZxdW90Ozo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7JnF1b3Q7Z2l2ZW5fbmFtZSZxdW90OzogeyZxdW90O2Vzc2VudGlhbCZxdW90Ozog dHJ1ZX0sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7 bmlja25hbWUmcXVvdDs6IG51bGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7JnF1b3Q7ZW1haWwmcXVvdDs6IHsmcXVvdDtlc3NlbnRpYWwmcXVvdDs6IHRydWV9 LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2VtYWls X3ZlcmlmaWVkJnF1b3Q7OiB7JnF1b3Q7ZXNzZW50aWFsJnF1b3Q7OiB0cnVlfSw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtwaWN0dXJlJnF1b3Q7OiBu dWxsLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90Ozxh IGhyZWY9Imh0dHA6Ly9leGFtcGxlLmluZm8vY2xhaW1zL2dyb3VwcyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHA6Ly9leGFtcGxlLmluZm8vY2xhaW1zL2dyb3VwczwvYT4mcXVvdDs6IG51bGw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7JnF1b3Q7aWRfdG9rZW4mcXVvdDs6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZxdW90O2F1dGhfdGltZSZxdW90OzogeyZxdW90O2Vzc2VudGlhbCZxdW90OzogdHJ1 ZX0sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7YWNy JnF1b3Q7OiB7JnF1b3Q7dmFsdWVzJnF1b3Q7OiBbJnF1b3Q7dXJuOm1hY2U6aW5jb21tb246aWFw OnNpbHZlciZxdW90O10gfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH08 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPn08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhdCBzaG91bGQgbG9vayBwcmV0dHkgZmFtaWxpYXIuIEFsdGVybmF0 aXZlbHksIHRoaXMgY291bGQgYmUgZG9uZSB3aXRoIGEgc2VwYXJhdGUgdG9wLWxldmVsIHJlcXVl c3Qgb2JqZWN0IGZpZWxkOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNsYWltczogezxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwO+KAnHN1YmplY3TigJ06IHRydWUsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A74oCcZW1h aWzigJ06IHRydWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPn0sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxvaWRjX2NsYWltc19yZXF1ZXN04oCdOiB7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O3VzZXJpbmZvJnF1b3Q7OjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtnaXZlbl9uYW1l JnF1b3Q7OiB7JnF1b3Q7ZXNzZW50aWFsJnF1b3Q7OiB0cnVlfSw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmcXVvdDtuaWNrbmFtZSZxdW90OzogbnVsbCw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmcXVvdDtlbWFpbCZxdW90OzogeyZxdW90O2Vzc2VudGlhbCZxdW90OzogdHJ1 ZX0sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7ZW1haWxfdmVyaWZpZWQmcXVv dDs6IHsmcXVvdDtlc3NlbnRpYWwmcXVvdDs6IHRydWV9LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZxdW90O3BpY3R1cmUmcXVvdDs6IG51bGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuaW5mby9jbGFpbXMvZ3JvdXBzIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL2V4YW1wbGUuaW5mby9jbGFpbXMvZ3JvdXBzPC9hPiZxdW90 OzogbnVsbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH0sPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm cXVvdDtpZF90b2tlbiZxdW90Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7YXV0aF90aW1lJnF1b3Q7OiB7JnF1b3Q7ZXNzZW50aWFs JnF1b3Q7OiB0cnVlfSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDthY3ImcXVv dDs6IHsmcXVvdDt2YWx1ZXMmcXVvdDs6IFsmcXVvdDt1cm46bWFjZTppbmNvbW1vbjppYXA6c2ls dmVyJnF1b3Q7XSB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu IGJvdGggY2FzZXMgdGhlIEFTIGlzIGdvaW5nIHRvIG5lZWQgdG8ga25pdCB0aGVtIHRvZ2V0aGVy IGludG8gYSBzZW5zaWJsZSByZXF1ZXN0IHBvbGljeSwgZXNwZWNpYWxseSBzaW5jZSB0aGUgT0lE QyBjbGFpbXMgcXVlcnkgbGFuZ3VhZ2UgaGFzIG92ZXJsYXBwaW5nIGltcGxpY2F0aW9ucyB0byBv bmUgcGFydGljdWxhciByZXNvdXJjZSwgdGhlIFVzZXJJbmZvIGVuZHBvaW50LiBNeSBjb250ZW50 aW9uIHdhc27igJl0DQogd2l0aCB5b3VyIHByb3Bvc2VkIHNvbHV0aW9uLCBteSBjb250ZW50aW9u IHdhcyB5b3UgY2xhaW1pbmcgdGhhdCBYWVogaGFzIGEgZml4ZWQgc2NoZW1hIGFuZCBpcyB0aGVy ZWZvcmUgbGltaXRlZCBpbiBleHRlbnNpYmlsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T25lIG9mIHRoZSBvYmplY3RpdmVzIG9mIHRoaXMgd29yayBpcyB0byBoYXZlIGV4dGVuc2lv biBwb2ludHMuIE15IHBvaW50IHdhcyB0aGF0IFhBdXRoIGhhZCBhIGNsZWFyIGV4dGVuc2lvbiBw b2ludCBmb3IgYWRkaW5nIHNjaGVtYXMuIEhvdyB0byBleHRlbmQgWFlaIHdhcyBub3QgY2xlYXIg aW4mbmJzcDt5b3VyIHByb3Bvc2FsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgYW0gc29ycnkgdGhhdCB0aGUgZXh0ZW5zaWJpbGl0eSBvZiB0aGUgcHJvdG9jb2wgd2Fz IG5vdCBjbGVhci4gSXQgaXMgc3RhdGVkIGluIGVhY2ggc2VjdGlvbiB0aGF0IGFkZGl0aW9uYWwg aXRlbXMgY2FuIGJlIGFkZGVkLCBhbmQgSSBoYXZlIHN0YXRlZCByZXBlYXRlZGx5IHRoYXQgaXTi gJlzIGV4dGVuc2libGUgYW5kIGRlbW9uc3RyYXRlZCBob3csIGhlcmUgb24gdGhpcyBsaXN0LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIFhBdXRoIHByb3Bvc2FsIGlzIGJldHRlciB0aGFu IHRoZSB0d28gZXhhbXBsZXMgeW91IHByb3Bvc2VkLiBJbiB5b3VyIGZpcnN0IGV4YW1wbGUsIHRo ZSBzY2hlbWEgaXMgYSBzZWNvbmQgY2xhc3Mgc2NoZW1hLCBhbmQgaW4geW91ciBzZWNvbmQgZXhh bXBsZSwgY2xhaW1zIGFyZSBzcHJlYWQgYWNyb3NzIHRvIHRvcCBsZXZlbCBvcHRpb25zLiBCb3Ro IG9mIHRoZXNlIHBvbGx1dGUgb3RoZXINCiBzY2hlbWFzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk5vdCBzdXJwcmlzaW5nbHksIEkgZGlzYWdyZWUgYWJvdXQgdGhlIGNs ZWFubGluZXNzIG9mIFhBdXRo4oCZcyBwcm9wb3NlZCBhcHByb2FjaC4gVGhlIHByb3Bvc2FsIGhl cmUgYWRkcyBleHRlcm5hbCBzY2hlbWFzIGFzIGV4dGVuc2lvbnMgaW5zdGVhZCBvZiByZWx5aW5n IG9uIHRoZW0gaW50ZXJuYWxseS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgYW55dGhpbmcsIEkgdGhpbmsgdGhhdCB0aGUgT3Bl bklEIEZvdW5kYXRpb24gd291bGQgYmUgdGhlIG9uZXMgdG8gZGVmaW5lIGhvdyB0byBtYWtlIGFu IE9JREMgY2xhaW1zIHJlcXVlc3QgdXNpbmcgdGhpcyBwcm90b2NvbCwgbm90IHVzLCBzaW5jZSB0 aGV5IG93biBhbmQgY29udHJvbCB0aGF0IHF1ZXJ5IHN5bnRheCBhbmQgZXZlcnl0aGluZyBpdCBp bXBsaWVzLiBXZSBjYW4gcHJvdmlkZSBhIG1lYW5zIG9mDQogZXh0ZW5zaW9uLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFsc28gdGhpbmsg dGhlcmXigJlzIHZhbHVlIGluIGRlZmluaW5nIGEgc2V0IG9mIGNvcmUgaW50ZXJvcGVyYWJsZSBp ZGVudGl0eSBmaWVsZHMsIHdoaWNoIHRoZW1zZWx2ZXMgY291bGQgYWxzbyBiZSBleHRlbmRlZC4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QWxsIG9mIHRoZXNlIG1lY2hhbmlzbXMgc2hvdWxkIGJlIGNvbnRyb2xsZWQgYnkgc29tZSBj b21iaW5hdGlvbiBvZiByZWdpc3RyaWVzIGFuZCBjb2xsaXNpb24tcmVzaXN0YW50IG5hbWVzcGFj ZXMsIHdoaWNoIGlzIHRoZSBhcHByb2FjaCBJ4oCZdmUgdGFrZW4gZm9yIGV4dGVuc2liaWxpdHkg dGhyb3VnaG91dCBYWVouPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpTT04gYnkgaXRz IG5hdHVyZSBpcyBleHRlbnNpYmxlLiBBZGRpbmcgbmV3IG1lbWJlcnMgdG8gYW4gb2JqZWN0IGlz IHN0cmFpZ2h0IGZvcndhcmQuIFhZWiBpcyBub3QgdW5pcXVlIGhlcmUuIEl0IHNvdW5kcyBsaWtl IHlvdXIgaWRlYSBvZiBleHRlbnNpYmlsaXR5Jm5ic3A7aXMgdGVsbGluZyBwZW9wbGUgdGhhdCB0 aGV5IGNhbiBhZGQgbmV3IG1lbWJlcnMgdG8gSlNPTi4gT2YgY291cnNlIHRoZXkgY2FuLiBUaGF0 IGlzDQogbGlrZSBzYXlpbmcgeW91IGNhbiBhZGQgbmV3IHF1ZXJ5IHBhcmFtZXRlcnMgdG8gYSBm cm9udCBjaGFubmVsIE9BdXRoIDIgcmVxdWVzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgY29uY2VybiB3YXMgdGhhdCBYWVogZG9lcyBu b3QgaGF2ZSBhIGNsZWFyIHdheSB0byBhZGQgbmV3IGlkZW50aXR5IGNsYWltIHNjaGVtYXMuIFlv dSBoYXZlIHR3byBleGFtcGxlcywgYWRkIGEgc2NoZW1hIGFzIGEgbWVtYmVyIG9mIHRoZSBjbGFp bXMgb2JqZWN0LCB3aGljaCBpcyBtaXhpbmcgY2xhaW1zIHdpdGggc2NoZW1hIGV4dGVuc2lvbnMs IG9yIGFkZGluZyBhIHJvb3QgbWVtYmVyLCB3aGljaCBpcw0KIHRoZW4gcHV0dGluZyBjbGFpbXMg aW50byBtb3JlIHRoYW4gb25lIHBsYWNlLiBJdCBpcyBub3QgY2xlYXIgd2hlcmUgdG8gYWRkIGEg bmV3IHNjaGVtYSwgc28gd2UgY291bGQgZWFzaWx5IGVuZCB1cCB3aXRoIG5ldyBzY2hlbWFzIGlu IGJvdGggcGxhY2VzLiBUaGF0IHNvdW5kcyBjb25mdXNpbmcuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIFhBdXRoLCB0aGUgbWVtYmVycyBv ZiB0aGUgY2xhaW1zIG9iamVjdCBhcmUgdGhlIHNjaGVtYS4gQWRkaW5nIGEgbmV3IHNjaGVtYSBp cyBkb25lIG9uZSwgY29uc2lzdGVudCB3YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndydC4gJnF1b3Q7ZGVmaW5pbmcgYSBzZXQgb2YgY29y ZSBpbnRlcm9wZXJhYmxlIGlkZW50aXR5IGZpZWxkcyZxdW90OywgdGhlIGNoYXJ0ZXIgc2F5cyB3 ZSBzaG91bGQgYmUNCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOnllbGxvdyI+ Tk9UIGRldmVsb3AgYSBuZXcgc2NoZW1hPC9zcGFuPjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOmxpbWUiPlRoZSBncm91cCBpcyBjaGFydGVyZWQgdG8g ZGV2ZWxvcCBtZWNoYW5pc21zIGZvciBjb252ZXlpbmcgaWRlbnRpdHkgaW5mb3JtYXRpb24gd2l0 aGluIHRoZSBwcm90b2NvbA0KPC9zcGFuPmluY2x1ZGluZyBpZGVudGlmaWVycyAoc3VjaCBhcyBl bWFpbCBhZGRyZXNzZXMsIHBob25lIG51bWJlcnMsIHVzZXJuYW1lcywgYW5kIHN1YmplY3QgaWRl bnRpZmllcnMpIGFuZCBhc3NlcnRpb25zICg8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7YmFja2dy b3VuZDpsaW1lIj5zdWNoIGFzIE9wZW5JRCBDb25uZWN0IElEIFRva2Vuczwvc3Bhbj4sIFNBTUwg QXNzZXJ0aW9ucywgYW5kIFZlcmlmaWFibGUgQ3JlZGVudGlhbHMpLg0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrO2JhY2tncm91bmQ6eWVsbG93Ij5UaGUgZ3JvdXAgaXMgbm90IGNoYXJ0ZXJlZCB0 byBkZXZlbG9wIG5ldyBmb3JtYXRzIGZvciBpZGVudGlmaWVycyBvciBhc3NlcnRpb25zLCBub3Ig aXMgdGhlIGdyb3VwIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIHNjaGVtYXMgZm9yIHVzZXIgaW5mb3Jt YXRpb24sIHByb2ZpbGVzLCBvciBvdGhlciBpZGVudGl0eSBhdHRyaWJ1dGVzLCB1bmxlc3MgYSB2 aWFibGUgZXhpc3RpbmcNCiBmb3JtYXQgaXMgbm90IGF2YWlsYWJsZS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPndydC4gT0lEQyBjbGFpbXMsIHRoZSBjaGFydGVyIGV4cGxpY2l0 bHkgY2FsbHMgb3V0IDxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNrZ3JvdW5kOmxpbWUiPg0K ZGV2ZWxvcGluZyBtZWNoYW5pc21zIGZvciBjb252ZXlpbmcgLi4uIE9JREMgSUQgVG9rZW5zPC9z cGFuPi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMSIgaGVpZ2h0PSIxIiBz dHlsZT0id2lkdGg6LjAxMDRpbjtoZWlnaHQ6LjAxMDRpbiIgaWQ9Il94MDAwMF9pMTAyNSIgc3Jj PSJodHRwczovL21haWxmb29nYWUuYXBwc3BvdC5jb20vdD9zZW5kZXI9YVpHbGpheTVvWVhKa2RF Qm5iV0ZwYkM1amIyMCUzRCZhbXA7dHlwZT16ZXJvY29udGVudCZhbXA7Z3VpZD02MGI4MDMyZC1l MDYxLTQ2NGUtYWZiYi0xYTgyYWJkMDJmMjEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2hpdGUiPuGQ pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_DM6PR00MB06846ED1BA34EBC8E3D31266F5820DM6PR00MB0684namp_-- From nobody Wed Jun 10 01:56:38 2020 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 966593A079B for ; Wed, 10 Jun 2020 01:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 XGneWDMs9cDz for ; Wed, 10 Jun 2020 01:56:34 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 D31413A079A for ; Wed, 10 Jun 2020 01:56:34 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id d5so1270546ios.9 for ; Wed, 10 Jun 2020 01:56:34 -0700 (PDT) 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=mba7QCyX59+ut/1FUirZTR6UoFkPE8SFETti4PqXkQw=; b=L0/29utZanT0fULKFq5HY7vxAZWBfZs5VclvDtPUWnzk/NtoS0WKhfYHQCI9ZqccnI QAVc93qx8b62J4uNppTJlfzHbFRVsB+/0cNuZtgJPLApCmXGZGW7XSIQNh/Z4PyKrg/b iCk7LlCCfAejSnefo2/XVgaZ9iykbHQQHlwD9UvU67X2Cj/hWy7N4HmK5deV1SFKVA3y 9W2ymIEYwQmLfCRhliEWKmW6AKiQERMVZ3stMDrKwdWQstpc0cbCGvbRSdjXiquSuFXD ObNyHDbA6noPagYp8r3H3PHzUJjTxz+7a691Gs9XIBZEIuJ1dawhdVxrOYEFC9WLPkoZ GYTQ== 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=mba7QCyX59+ut/1FUirZTR6UoFkPE8SFETti4PqXkQw=; b=lxIhwmZVzXKk3tfcHEcMqmayxGFPCzLBKPQuPHSXU3IdiMbFiFu8Eb2toQIA2OXHV5 VoVtAVwWXJQRVxm8DIAVjBcgj9dV0f+yGUbd6wuKmkjpi9Q8UOe1a0CJRy3gjW/OkcZ5 JzpJLC6KTCd1AEzzeKWoYA7cULfUwNnOB+S0mCpGzzRkORE5F6FTxl8uZlnhvPvU0W/E TPfQqLw7fsxAklMKlxQ91wL+SV1nzsxy4sted59eXQ0NI2aGKYIbG+A03/m7eD3L7Ygq YoEvtQT/qewnukCfj4s/PK3aSM2p+y1rh+YWm7oVWPCAG2f2jxDoXTk9dShk34AK7NOH J+4g== X-Gm-Message-State: AOAM5314UwC+1JWtqQGO6aNqRrbarl5iTWBZ+VsEmyWF/LiSUerrJCpL NdQ4gBKJdW/S8gvBf3JBqgQkt2ZmqlLYy4zgmsANqZG+g6U= X-Google-Smtp-Source: ABdhPJx3zOm5/RkMJsS0xIn4FvCHDNMdSmPNlZzHKc//698W6LAD1SNbihh1B81/cZqYOU6WMuSlX0rgQ/dtNQnBuVQ= X-Received: by 2002:a6b:4413:: with SMTP id r19mr2230569ioa.162.1591779393217; Wed, 10 Jun 2020 01:56:33 -0700 (PDT) MIME-Version: 1.0 From: Fabien Imbault Date: Wed, 10 Jun 2020 10:56:20 +0200 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000004b298605a7b705cb" Archived-At: Subject: [Txauth] Additional implementation 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, 10 Jun 2020 08:56:37 -0000 --0000000000004b298605a7b705cb Content-Type: text/plain; charset="UTF-8" Hi, Just to let you know that we started our own implementation of XYZ / XAuth (and future GNAP). It's just a first attempt of getting the concepts put into use quickly. We wanted to have a clear separation between the client and the AS, and demonstrate the retrieval of a protected resource to make it simpler for people to understand (even if there's nothing new there). Here's a quick MVP of xyz. Currently it's just implementing a basic flow, redirect with callback interaction. https://github.com/acertio/mvp_xyz (also working on the same for XAuth, because I sometimes get a bit lost in discussions between Justin and Dick, really need to get down to the drafts and write concrete examples to get a sense of what it means). This is very basic/naive but really gave us some better ideas on what to test/implement next, and contribute to the discussion. Note also that our target implementation will be in rust, and we are currently testing the approach on how to best implement it using a system oriented language (the fact that nodejs is very web oriented is abstracting some important aspects in our view). Our work is available under an MPLv2 licence, and we'll be happy to keep working on a separate and open reference implementation. As a last comment, I'd like to say that both XYZ and XAuth are great work, but it seems we're having 2 competing views, difficult to reconcile. I believe we can do better. Following our experiments, I would say: a) XYZ really makes a new experience possible, and the flow really fixes common issues in OAuth2. I believe this design idea is of great value, but the downside is that the written spec doesn't explicitly cover every aspect yet, so sometimes you have to guess or dig into Justin's implementation. But making sure we clarify that is also what the working group is there for, isn't it? Justin has even put his money where his mouth is by providing implementations and integrating with legacy software (an old implementation by mitre), so it's a very good sign that we won't end up with unnecessary breaking changes. b) XAuth's spec is written in a more consistent way, which reflects the fact that is closer to the previous art. There is no reference implementation (as far as I'm aware) and it comes with the potential downside of having a more opinionated/prescriptive stance and being much closer to legacy (for good or worse). However, I don't think the game of spotting the differences is that meaningful, and the charter should provide sufficient common ground to proceed forward despite or thanks to those differences. Otherwise we'll end up in surprisingly narrow considerations, such as I prefer X because it's reusing existing schemas. This is something we need to handle when time comes, but that's really an implementation detail and obviously nobody thinks we shouldn't reuse things that do work. A better way would be XYZ concepts challenged by XAuth's rigour (surely Dick and others would make sure of that) and several iterative implementations to make sure it does work as intended, as we propose to do. Fabien --0000000000004b298605a7b705cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Just to let you know tha= t we started our own implementation of XYZ / XAuth (and future GNAP).
=
It's just a first attempt of getting the concepts put into use qui= ckly. We wanted to have a clear separation between the client and the AS, a= nd demonstrate the retrieval of a protected resource to make it simpler for= people to understand (even if there's nothing new there).=C2=A0
<= div>
Here's a quick MVP of xyz.=20 Currently it's just implementing a basic flow, redirect with callback i= nteraction.
(also working on= the same for XAuth, because I sometimes get a bit lost in discussions betw= een Justin and Dick, really need to get down to the drafts and write concre= te examples to=C2=A0get a sense of what it=C2=A0means).=C2=A0
Thi= s is very=C2=A0basic/naive but really gave us some better ideas on what to = test/implement next,=C2=A0and contribute to the discussion.=C2=A0
=C2=A0
Note also that our target implementation will be in rust,= and we are currently testing the approach on how to best implement it usin= g a system oriented language (the fact that nodejs is very web oriented is = abstracting some important aspects in our view).
Our work is available under an MPLv2 licence, and we'll be happy to kee= p working on=C2=A0a separate and open reference implementation.=C2=A0 =C2= =A0

As a last comment, I'd like to say that bo= th XYZ and XAuth are great work, but it seems we're having 2 competing = views,=C2=A0difficult=C2=A0to reconcile. I believe we can do better.
<= div>
Following our experiments, I would say:=C2=A0
= a) XYZ really makes a new experience possible, and the flow really fixes co= mmon issues in OAuth2. I believe this design idea is of great value, but th= e downside is that the written spec doesn't explicitly cover=C2=A0every= aspect yet,=C2=A0so sometimes you have to guess or dig into Justin's i= mplementation. But making sure we clarify that is also what the working gro= up is there for, isn't it?=C2=A0
Justin has even put his mone= y where his mouth is by providing implementations and integrating with lega= cy software (an old implementation by mitre), so it's a very good sign = that we won't end up with unnecessary breaking changes.=C2=A0
=C2=A0 =C2=A0=C2=A0
b) XAuth's spec is written in a more con= sistent way, which=C2=A0reflects the fact that is closer to the previous ar= t. There is no reference implementation (as far as I'm aware) and it co= mes with the potential downside of having a more opinionated/prescriptive s= tance and being much closer to legacy (for good or worse).=C2=A0
=
However, I don't think the game of spotting the differen= ces is that meaningful, and the charter should provide sufficient common gr= ound to proceed forward despite or thanks to those differences. Otherwise w= e'll end up in surprisingly narrow considerations, such as I prefer X b= ecause it's reusing existing schemas. This is something we need to hand= le when time comes, but that's really an implementation detail and obvi= ously nobody thinks we shouldn't reuse things that do work.=C2=A0
=

A better way would be XYZ concepts challenged by XAuth&= #39;s rigour (surely Dick and others would make sure of that) and several i= terative implementations to make sure it=C2=A0does work as intended,=C2=A0a= s we propose to do.=C2=A0
=C2=A0 =C2=A0
Fabien
--0000000000004b298605a7b705cb-- From nobody Wed Jun 10 07:54:35 2020 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 1C5133A00D3 for ; Wed, 10 Jun 2020 07:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 lHYJ0abMU9s2 for ; Wed, 10 Jun 2020 07:54:29 -0700 (PDT) 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 373493A00B2 for ; Wed, 10 Jun 2020 07:54:28 -0700 (PDT) Received: from [192.168.1.14] (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 05AEsPF8013500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Jun 2020 10:54:25 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3A1E12FB-67E6-4372-91D4-507BBD232FF2" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 10 Jun 2020 10:54:25 -0400 In-Reply-To: Cc: txauth@ietf.org To: Dick Hardt References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 10 Jun 2020 14:54:34 -0000 --Apple-Mail=_3A1E12FB-67E6-4372-91D4-507BBD232FF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 9, 2020, at 4:11 PM, Dick Hardt wrote: >=20 > Comments inline >=20 > Last item will be broken out to new thread. >=20 > On Tue, Jun 9, 2020 at 9:10 AM Justin Richer > wrote: >=20 >=20 >> On Jun 8, 2020, at 5:33 PM, Dick Hardt > wrote: >>=20 >>=20 >>=20 >> On Mon, Jun 8, 2020 at 1:02 PM Justin Richer > wrote: >>=20 >> >>> A GS implementation can decide to only return an authorization from = doing a GET on the AZ URL. Returning only an AZ URL is an option in = XAuth. Similarly, we could do the same for a Grant URI.=20 >>=20 >> And that=E2=80=99s a lot of complex code paths for both the GS and = client to deal with. With more ways that it might happen, the client has = to be prepared for any of them =E2=80=94 and get them all right.=20 >>=20 >> I don't see it being complex. The data either moves by reference or = by value. Both parties will have to enable support by reference. Passing = by value is an optimization so that the client does not have to make an = additional call. >=20 > =E2=80=9CBoth parties will have to enable=E2=80=9D is where the = complexity comes into play. It=E2=80=99s putting a requirement on the = client to anticipate several different ways to get the same information. >=20 > As I understand it, XYZ works the same way. The client may get a = handle to the transaction in an Interaction Response or a Wait Response, = or the client receives a transaction response. >=20 > There could be only one way in XAuth (pass by reference), but I expect = that people will prefer an optimization of pass by value when it can be = done and deal with the complexity that they may get the data in two = different ways, just as in XYZ. It=E2=80=99s not the same. What you=E2=80=99re missing, I believe, is = that this is one of the benefits of having a single endpoint, as XYZ is = defined today. The =E2=80=9Cgrant response=E2=80=9D comes from exactly = one place regardless of where in the transaction it happens. This is why = I think this is something the working group as a whole needs to weigh in = on, to figure out the pros and cons of different designs. I personally = don=E2=80=99t like the complexity, and a definitely don=E2=80=99t like = the restrictions imposed by XAuth today, but there are benefits that = might outweigh and justify that move.=20 > =20 >=20 >>=20 >> >>=20 >>> =20 >>>=20 >>> Using a different URI, optionally, isn=E2=80=99t the problem, and = that could easily be added to the. Removal of the separate handle is the = problem I have with the XAuth approach. >>>=20 >>> In XAuth, the Grant URI is the GS URI + TBD + handle >>>=20 >>> Given we have asymmetric crypto as a requirement, it is unclear what = having two pieces of random signal provide. >>=20 >> Asymmetric crypto is an implementation requirement in both the input = drafts but it isn=E2=80=99t a requirement in the charter, and there are = likely symmetric use cases and key proofing mechanisms that are going to = be desirable for a lot of people. >>=20 >>> =20 >>>=20 >>>> =20 >>>>=20 >>>> Additionally, I find XAuth=E2=80=99s restrictions on the structure = of the Grant URI potentially problematic, namely that it has to start = with the server=E2=80=99s URL. This will lead to deployments needing to = bend their setups with proxies or redirectors to make things fit, which = you yourself have said is going to be an issue for things like = supporting a short redirect URL vs. a long redirect URL. Your complaint = there was one of latency and complexity, why does that not apply here? = But most fundamentally, I do not see what value this restriction brings = to the system. If the value is coming back from the GS endpoint, and the = client is getting all of its pointers from there, what=E2=80=99s the = point of dictating how that has to look? >>>>=20 >>>> Requiring the Grant URI to start with the GS URI is open to = discussion. It is not clear to me why a deployment would need to have a = redirector. Large scale deployments I have worked on have a router / = proxy that routes requests to internal services. Having all the URIs = start with the GS URI enables all GNAP operations to be routed in the = same place. >>>=20 >>> You still haven=E2=80=99t addressed why you think that this is a = reasonable requirement or assumption here but not when dealing with = long/short URLs for QR codes. What is the difference? >>>=20 >>> Short URLs generally use a short host name as well as a short path.=20= >>>=20 >>> Most REST interfaces have the pattern I am proposing. A mental model = many developers are familiar with.=20 >>=20 >> This is assuming a lot on the part of the GS implementation, still, = and all of my arguments stand.=20 >>=20 >>=20 >> That is not entirely correct. A pre-registered client can still pass = its key by value, and a dynamic client can still use a = (dynamically-acquired) handle. In all cases, the client is identifying = itself by its key. The difference is how the server looks up that key = =E2=80=94 it=E2=80=99s either from the handle, or it=E2=80=99s from the = key value itself.=20 >>=20 >> I don't understand this.=20 >>=20 >> How is the Client authenticating that it is a specific pre-registered = client? >=20 > The client is identified by its key. >=20 > And you think that will be an easy concept for developers to migrate = to from the mental model they have now? And what is the value? I believe = your proposal for other pre-registered clients to migrate was to use the = Client ID as the Key Handle. So the Key Handle may represent any of the = pre-registered clients, but represents each instance of a dynamic = client. Does not seem like it is any different than how a Client ID is = used today. >=20 > Tom has started a new thread on other aspects of this section. Not only do I think OAuth developers can migrate, I think it=E2=80=99s = essential that we do in order to make this useful to non-OAuth = developers. Vast swaths of the internet are already building out = key-based systems, not using OAuth. In my own experience, I can say for = a fact that the awkwardness of needing a client identifier ahead of time = is one of the problems. The fact that there=E2=80=99s a place to use a = legacy client ID within the protocol is a bonus feature, and important = for migration. But it=E2=80=99s even more important that it=E2=80=99s = not=20 And we should look at history before we declare something impossible. We = managed to get web developers away from thinking about accessing an API = with a username and password and toward thinking in terms of accessing = it with a token. This is a shift of the same kind, and an important one = at that. To me, this is one of the important fundamental shifts of this work away = from the limits of OAuth=E2=80=99s models and assumptions, and one of = the ones that will make this work applicable far outside of the space = that OAuth 2 has already carved. I don=E2=80=99t see a compelling reason = to limit ourselves. If your primary goal is to keep OAuth 2 developers safe and happy, then = in all honesty, just keep using OAuth 2. Why wouldn=E2=80=99t you? Use = PAR and RAR and DPoP for advanced functionality. It=E2=80=99s a = combination that, if a bit patched-together, does work. Move to a new = protocol when it does something you can=E2=80=99t do, or it=E2=80=99s = otherwise a better fit for what you=E2=80=99re trying to solve. And when = you=E2=80=99re in a position to move, there=E2=80=99s a migration path. = That doesn=E2=80=99t mean it=E2=80=99s a direct re-use, it means you can = migrate =E2=80=94 move, change =E2=80=94 without tearing absolutely = everything out. But you still need to move, and that=E2=80=99s expected.=20= In all honesty, I think the gap between OAuth 2 and XYZ is less than the = gap between OAuth 1 and OAuth 2, especially if you=E2=80=99re looking at = using OAuth 2 with PAR, RAR, etc. I don=E2=80=99t see a compelling = reason to artificially limit the new protocol with the constraints of = the old, particularly when there=E2=80=99s a migration path between = them. XYZ can make use of some of the familiar pieces of OAuth 2 without = causing all clients to depend on them. That=E2=80=99s the difference = between migration and straight re-use. > >> In XAuth, if the server wants to protect itself from a session = fixation attack in a given request, and it wants to support both = "redirect" and "user_code" modes,=20 >> the server will return only those two modes and not "indirect". The=20= >>=20 >> In XAuth, if the server wants to protect itself from a session = fixation attack in a given request, and it wants to support both = "redirect" and "user_code" modes,=20 >> the server MUST return callback, redirect, and user_code. The client = does not know that the "indirect" mode is not supported, and may try = that. >>=20 >=20 > In XYZ, if the server wants to protect against a session fixation = attack, it will reject a request that doesn=E2=80=99t have a = =E2=80=9Ccallback=E2=80=9D field in it. The AS always gets to choose = which things it supports for any given request. If the client wants to = support both =E2=80=9Credirect=E2=80=9D and =E2=80=9Cuser_code=E2=80=99 = modes AND has the ability to handle session fixation issues, it sends = the =E2=80=9Credirect=E2=80=9D, =E2=80=9Cuser_code=E2=80=99, and = =E2=80=9Ccallback=E2=80=9D fields in its interaction request.=20 >=20 > If the client chooses to present the interaction_url as a scannable = barcode, which is an option if it receives one, it will then get an = error when it tries to do a transaction continue request as the AS = protects itself. Unfortunately the user has scanned the barcode and is = now at the AS. I don't see how the client learns it is not able to do = what I call an "indirect" mode interaction. Would you explain how this = situation is prevented in XYZ? If the client has made a request with =E2=80=9Credirect=E2=80=9D and = =E2=80=9Ccallback=E2=80=9D in its request, and then decides to display = the interaction URL as a scannable code, then the AS will just redirect = to the client=E2=80=99s callback URL when it=E2=80=99s done, whatever = that URL was. If the client sends a =E2=80=9Ccallback=E2=80=9D URL that = it can=E2=80=99t get information from, then that=E2=80=99s a = poorly-written client, isn=E2=80=99t it? If the client can=E2=80=99t get to the information in the callback URL = unless it=E2=80=99s on the same device, then the client isn=E2=80=99t = going to show the user a scannable code to be read by a secondary = device. Why would it? >=20 > >> =20 >>=20 >>>=20 >>> For example:=20 >>>=20 >>> How is a transaction updated?=20 >>> How are separate access tokens refreshed?=20 >>> Refreshing an access token in XYZ returns a full transaction = response per Section 9.3 which refers to Section 8. >=20 > Would you address these questions? Transactions are updated by sending the transaction handle back with = additional information. This is no different from the request made after = a front channel callback, or what would be made in a challenge-response = format. I haven=E2=80=99t written up a way to create a new transaction = building on an old one (which I think is an important advanced use = case), but it would amount to having a separate field in the initial = transaction request to have the transaction handle of the old = transaction in it.=20 Multiple access tokens cannot be refreshed separately in the current = implementation of XYZ. This is a noted gap in the spec, and I=E2=80=99m = open to ideas on how it would be handled. > =20 >>>=20 >>>=20 >>> By using URIs and methods, XAuth has an easy to understand API for = CRUD operations on Grants and Authorizations. >>>=20 >>> = +--------------+-----------+--------+-----------------------------+ >>> | request | http verb | uri | response = | >>> = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>> | Create Grant | POST | GS URI | interaction, wait, or = grant | >>> = +--------------+-----------+--------+-----------------------------+ >>> | List Grants | GET | GS URI | grant list = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Verify Grant | PATCH | Grant | grant = | >>> | | | URI | = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Read Grant | GET | Grant | wait, or grant = | >>> | | | URI | = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Update Grant | PUT | Grant | interaction, wait, or = grant | >>> | | | URI | = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Delete Grant | DELETE | Grant | success = | >>> | | | URI | = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Read AuthZ | GET | AZ URI | authorization = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Update AuthZ | PUT | AZ URI | authorization = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Delete AuthZ | DELETE | AZ URI | success = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | GS Options | OPTIONS | GS URI | metadata = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | Grant | OPTIONS | Grant | metadata = | >>> | Options | | URI | = | >>> = +--------------+-----------+--------+-----------------------------+ >>> | AuthZ | OPTIONS | AZ URI | metadata = | >>> | Options | | | = | >>> = +--------------+-----------+--------+-----------------------------+ >>> =20 >>=20 >> While this looks good on paper, there are very pragmatic reasons that = many APIs have moved away from purely RESTful patterns over the last = decade, including limitations on what can be sent with GET and DELETE = requests, for example. I don=E2=80=99t think it=E2=80=99s as clean a win = as you=E2=80=99re presenting it, but I think it=E2=80=99s worth checking = out. >>=20 >> Agreed that RESTful does not work for everything. It does look like = it maps well here. >=20 > I disagree that it maps well. I think this is an over-application of a = design pattern and the details will be problematic in implementation. >=20 > What aspect does not map well? >=20 > What do you think will be problematic? >=20 > It seems much simpler to route a request based on URI and verb(XAuth), = then parse and inspect a JSON payload (XYZ) See above. > =20 >=20 >> =20 >>=20 >>>=20 >>>> =20 >>>>=20 >>>> The modes in XAuth are much more limiting, as the mixing of = different interaction methods is already something that we need to start = figuring out. Let=E2=80=99s say, for example, a client can do a = redirect, accept a CIBA-style ping, or do a direct app2app = communication. There=E2=80=99s a natural preference the client will have = here: if it can talk to another app directly, it=E2=80=99ll try that = first. If that doesn=E2=80=99t work, it can get a push notification = sent, and if all that fails, it can pop open a browser. If I have to = pick just one of those modes when I make the request, then the client = needs to make three different requests to the AS before I get anything = that works.=20 >>>>=20 >>>> Have you read the revised draft? As I noted above, I have added = negotiation. The Client can state all the modes it wants, the GS can = respond with the modes it will support, and the Client can offer the = User any modes returned from the GS. >>>=20 >>> Yes, did you read what I wrote? I think we=E2=80=99re talking past = each other. >>>=20 >>> This is not how XAuth is written currently. The Client can list all = of the modes it wants to use. The Server will return all the modes that = fit in its policy for the Grant Request. Why would the Client need to = make different requests? >>>=20 >>> per >>>=20 >>> = https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.2 = = =20 >>>=20 >>> The interaction object contains one or more interaction mode objects = per Section 5 >>>=20 >>> Three modes are defined here: >>>=20 >>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-5 = >>>=20 >>> More modes may defined in extensions, or in this document. >>=20 >> Yes, this is an improvement, and I=E2=80=99m glad you=E2=80=99re = moving your thinking in this direction. However, it=E2=80=99s still not = as clear how things combine to solve different use cases, and it = conflates the means of getting the user TO the interaction page with the = way of getting them BACK from it. It=E2=80=99s these flexible = combinations that I think are important, and I don=E2=80=99t think XAuth = gets this quite right yet.=20 >>=20 >> I think how the user gets to and from the server is CRITICAL to the = server if it wants to protect itself from a session fixation attack. >> See above where the client does not know what it can actually do that = the server will allow. >=20 > It is critical that the server knows how to protect itself, yes. = It=E2=80=99s not critical that the way there and the way back are = tightly bound to each other in this way. I think that model is limiting. >=20 > What other way back are you envisioning there could be besides a URI = redirect? >=20 > Rolling between mobile apps is a URI redirect. What else could happen? >=20 > I expect there will be new ways of transferring control to a GS, or = that the GS will reach out to the user directly. >=20 Push notifications on a mobile platform, COAP-style subscriptions at the = HTTP layer, messages coming in over a blockchain fabric through a = separate entity=E2=80=A6 I think your view of what a client is and how it could communicate and = interact is limited, and that=E2=80=99s informing XAuth=E2=80=99s = design. > =20 >=20 >> =20 >> >>>=20 >>> It is an OR in that if the client is using the type "oauth_scope", = they cannot have an "authorization_details" attribute, they can only = have "scope" >>>=20 >>> If the client is using the type "oauth_rich", the client MUST = include "authorization_details", and MAY include "scope" >>> =20 >>> I have updated the the doc to better capture that: >>>=20 >>> = https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.4 = >>>=20 >>> and example 2 now is of type "oauth_rich" >>>=20 >>> = https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.2 = >>>=20 >>=20 >> It was not clear to me that both could be sent with that mode, so = thank you for updating that. But the client still has to choose one or = the other up front. Why not have a mechanism that it can send both at = all times? Why have a =E2=80=9Cmode=E2=80=9D type switch at all? XYZ = allows clients to make these combined requests with a single consistent = syntax. >>=20 >> And by completely externalizing this to OAuth 2, I would argue that = we lose an opportunity to more clearly define how resources are = described and used, and we inherit the same combination issues that are = facing RAR today. We can do better because we get to define the context. >>=20 >> This group can define a new syntax if it wants, and it will be = unencumbered by the OAuth 2 and RAR legacy if deployments that want to = use the OAuth 2 and RAR syntax can use them directly. Ie, there can be a = type "gnap" or some such. >=20 >=20 > You did not respond to this response.=20 >=20 What I=E2=80=99m proposing in XYZ is exactly the new syntax that = incorporates both RAR and scope natively by using handles and = polymorphic JSON. Other resource request syntaxes could also be defined = and added. > The next section I have put into a separate email. >=20 > /Dick >=20 > =E1=90=A7 --Apple-Mail=_3A1E12FB-67E6-4372-91D4-507BBD232FF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Jun 9, 2020, at 4:11 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Comments inline

Last item will be broken out to new thread.

On Tue, Jun 9, 2020 at 9:10 AM Justin Richer <jricher@mit.edu> = wrote:


On Jun 8, 2020, at 5:33 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:



On Mon, Jun 8, 2020 at 1:02 PM Justin = Richer <jricher@mit.edu> wrote:

<snip>
A GS implementation can decide to = only return an authorization from doing a GET on the AZ URL. Returning = only an AZ URL is an option in XAuth. Similarly, we could do the same = for a Grant URI. 

And that=E2=80=99s a lot = of complex code paths for both the GS and client to deal with. With more = ways that it might happen, the client has to be prepared for any of them = =E2=80=94 and get them all = right. 

I don't see it being complex. The data = either moves by reference or by value. Both parties will have to enable = support by reference. Passing by value is an optimization so that the = client does not have to make an additional = call.

=E2=80=9CBoth parties will have to = enable=E2=80=9D is where the complexity comes into play. It=E2=80=99s = putting a requirement on the client to anticipate several different ways = to get the same information.

As I understand it, = XYZ works the same way. The client may get a handle to the transaction = in an Interaction Response or a Wait Response, or the client receives a = transaction response.

There could be only one way in XAuth (pass by reference), but = I expect that people will prefer an optimization of pass by value when = it can be done and deal with the complexity that they may get the data = in two different ways, just as in = XYZ.

It=E2=80=99s not the same. What you=E2=80=99re = missing, I believe, is that this is one of the benefits of having a = single endpoint, as XYZ is defined today. The =E2=80=9Cgrant response=E2=80= =9D comes from exactly one place regardless of where in the transaction = it happens. This is why I think this is something the working group as a = whole needs to weigh in on, to figure out the pros and cons of different = designs. I personally don=E2=80=99t like the complexity, and a = definitely don=E2=80=99t like the restrictions imposed by XAuth today, = but there are benefits that might outweigh and justify that = move. 

 


 <snip>

 

Using a different URI, optionally, = isn=E2=80=99t the problem, and that could easily be added to the. = Removal of the separate handle is the problem I have with the XAuth = approach.

In XAuth, the Grant URI is the GS = URI + TBD + handle

Given we have asymmetric crypto as = a requirement, it is unclear what having two pieces of random = signal provide.

Asymmetric crypto is an = implementation requirement in both the input drafts but it isn=E2=80=99t = a requirement in the charter, and there are likely symmetric use cases = and key proofing mechanisms that are going to be desirable for a lot of = people.

 

 

Additionally, I find XAuth=E2=80=99s restrictions on the = structure of the Grant URI potentially problematic, namely that it has = to start with the server=E2=80=99s URL. This will lead to deployments = needing to bend their setups with proxies or redirectors to make things = fit, which you yourself have said is going to be an issue for things = like supporting a short redirect URL vs. a long redirect URL. Your = complaint there was one of latency and complexity, why does that not = apply here? But most fundamentally, I do not see what value this = restriction brings to the system. If the value is coming back from the = GS endpoint, and the client is getting all of its pointers from there, = what=E2=80=99s the point of dictating how that has to = look?

Requiring the Grant URI to start with = the GS URI is open to discussion. It is not clear to me why a deployment = would need to have a redirector. Large scale deployments I have worked = on have a router / proxy that routes requests to internal services. = Having all the URIs start with the GS URI enables all GNAP operations to = be routed in the same place.

You still haven=E2=80=99t = addressed why you think that this is a reasonable requirement or = assumption here but not when dealing with long/short URLs for QR codes. = What is the difference?

Short URLs generally use a short host = name as well as a short path. 

Most REST interfaces have the pattern I = am proposing. A mental model many developers are familiar = with. 

This is assuming a lot on the part of = the GS implementation, still, and all of my arguments = stand. 


That = is not entirely correct. A = pre-registered client can still pass its key by value, and a = dynamic client can still use a (dynamically-acquired) handle. In all = cases, the client is identifying itself by its key. The difference is = how the server looks up that key =E2=80=94 it=E2=80=99s either from the = handle, or it=E2=80=99s from the key value = itself. 

I don't understand this. 

How is the Client authenticating that = it is a specific pre-registered = client?

The client is identified = by its key.

And you think that will be an easy = concept for developers to migrate to from the mental model they have = now? And what is the value? I believe your proposal for other = pre-registered clients to migrate was to use the Client ID as the Key = Handle. So the Key Handle may represent any of the pre-registered = clients, but represents each instance of a dynamic client. Does not seem = like it is any different than how a Client ID is used today.

Tom has started a new = thread on other aspects of this = section.

Not only do I think OAuth developers can migrate, = I think it=E2=80=99s essential that we do in order to = make this useful to non-OAuth developers. Vast swaths of the internet = are already building out key-based systems, not using OAuth. In my own = experience, I can say for a fact that the awkwardness of needing a = client identifier ahead of time is one of the problems. The fact that = there=E2=80=99s a place to use a legacy client ID within the protocol is = a bonus feature, and important for migration. But it=E2=80=99s even more = important that it=E2=80=99s not 

And we should look at history before we declare = something impossible. We managed to get web developers away from = thinking about accessing an API with a username and password and toward = thinking in terms of accessing it with a token. This is a shift of the = same kind, and an important one at that.

To me, this is one of the important fundamental = shifts of this work away from the limits of OAuth=E2=80=99s models and = assumptions, and one of the ones that will make this work applicable far = outside of the space that OAuth 2 has already carved. I don=E2=80=99t = see a compelling reason to limit ourselves.

If your primary goal is to keep OAuth 2 developers = safe and happy, then in all honesty, just keep using OAuth 2. Why = wouldn=E2=80=99t you? Use PAR and RAR and DPoP for advanced = functionality. It=E2=80=99s a combination that, if a bit = patched-together, does work. Move to a new protocol when it does = something you can=E2=80=99t do, or it=E2=80=99s otherwise a better fit = for what you=E2=80=99re trying to solve. And when you=E2=80=99re in a = position to move, there=E2=80=99s a migration path. That doesn=E2=80=99t = mean it=E2=80=99s a direct re-use, it means you can migrate =E2=80=94 = move, change =E2=80=94 without tearing absolutely everything out. But = you still need to move, and that=E2=80=99s expected. 

In all honesty, I think the gap between OAuth 2 = and XYZ is less than the gap between OAuth 1 and OAuth 2, especially if = you=E2=80=99re looking at using OAuth 2 with PAR, RAR, etc. I don=E2=80=99= t see a compelling reason to artificially limit the new protocol with = the constraints of the old, particularly when there=E2=80=99s a = migration path between them. XYZ can make use of some of the familiar = pieces of OAuth 2 without causing all clients to depend on them. = That=E2=80=99s the difference between migration and straight = re-use.

 <snip>
In XAuth, if the server wants to protect itself from a = session fixation attack in a given request, and it wants to support both = "redirect" and "user_code" modes, 
the server = will return only those two modes and not "indirect". The 

In = XAuth, if the server wants to protect itself from a session fixation = attack in a given request, and it wants to support both "redirect" and = "user_code" modes, 
the server MUST return callback, redirect, and = user_code. The client does not know that the "indirect" mode is not = supported, and may try that.


In XYZ, if the server wants to protect = against a session fixation attack, it will reject a request that = doesn=E2=80=99t have a =E2=80=9Ccallback=E2=80=9D field in it. The AS = always gets to choose which things it supports for any given request. If = the client wants to support both =E2=80=9Credirect=E2=80=9D and = =E2=80=9Cuser_code=E2=80=99 modes AND has the ability to handle session = fixation issues, it sends the =E2=80=9Credirect=E2=80=9D, = =E2=80=9Cuser_code=E2=80=99, and =E2=80=9Ccallback=E2=80=9D fields in = its interaction request. 

If the client chooses to = present the interaction_url as a scannable barcode, which is an option = if it receives one, it will then get an error when it tries to do a = transaction continue request as the AS protects itself. Unfortunately = the user has scanned the barcode and is now at the AS. I don't see how = the client learns it is not able to do what I call an "indirect" mode = interaction. Would you explain how this situation is prevented in = XYZ?

If= the client has made a request with =E2=80=9Credirect=E2=80=9D and = =E2=80=9Ccallback=E2=80=9D in its request, and then decides to display = the interaction URL as a scannable code, then the AS will just redirect = to the client=E2=80=99s callback URL when it=E2=80=99s done, whatever = that URL was. If the client sends a =E2=80=9Ccallback=E2=80=9D URL that = it can=E2=80=99t get information from, then that=E2=80=99s a = poorly-written client, isn=E2=80=99t it?

If the client can=E2=80=99t get to the information = in the callback URL unless it=E2=80=99s on the same device, then the = client isn=E2=80=99t going to show the user a scannable code to be read = by a secondary device. Why would it?


<snip>
 


For example: 

How is a transaction = updated? 
How are separate access tokens = refreshed? 
Refreshing an access token in XYZ = returns a full transaction response per Section 9.3 which refers to = Section 8.
<= /div>
Would you address = these questions?

Transactions are updated by sending the = transaction handle back with additional information. This is no = different from the request made after a front channel callback, or what = would be made in a challenge-response format. I haven=E2=80=99t written = up a way to create a new transaction building on an old one (which I = think is an important advanced use case), but it would amount to having = a separate field in the initial transaction request to have the = transaction handle of the old transaction in it. 

Multiple access tokens cannot be refreshed = separately in the current implementation of XYZ. This is a noted gap in = the spec, and I=E2=80=99m open to ideas on how it would be = handled.

 


By using = URIs and methods, XAuth has an easy to understand API for CRUD = operations on Grants and Authorizations.

    =
+--------------+-----------+--------+-----------------------------+
    | request      | http verb | uri    | response                    |
    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
    | Create Grant | POST      | GS URI | interaction, wait, or grant |
    +--------------+-----------+--------+-----------------------------+
    | List Grants  | GET       | GS URI | grant list                  |
    +--------------+-----------+--------+-----------------------------+
    | Verify Grant | PATCH     | Grant  | grant                       |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read Grant   | GET       | Grant  | wait, or grant              |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Update Grant | PUT       | Grant  | interaction, wait, or grant |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Delete Grant | DELETE    | Grant  | success                     |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read AuthZ   | GET       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Update AuthZ | PUT       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Delete AuthZ | DELETE    | AZ URI | success                     |
    +--------------+-----------+--------+-----------------------------+
    | GS Options   | OPTIONS   | GS URI | metadata                    |
    +--------------+-----------+--------+-----------------------------+
    | Grant        | OPTIONS   | Grant  | metadata                    |
    | Options      |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | AuthZ        | OPTIONS   | AZ URI | metadata                    |
    | Options      |           |        |                             |
    =
+--------------+-----------+--------+-----------------------------+
<= /div>
 

While this looks good on = paper, there are very pragmatic reasons that many APIs have moved away = from purely RESTful patterns over the last decade, including limitations = on what can be sent with GET and DELETE requests, for example. I don=E2=80= =99t think it=E2=80=99s as clean a win as you=E2=80=99re presenting it, = but I think it=E2=80=99s worth checking = out.

Agreed that RESTful does not work for everything. It does = look like it maps well here.

I disagree that it maps = well. I think this is an over-application of a design pattern and the = details will be problematic in = implementation.

What aspect does not map = well?

What do = you think will be problematic?

It seems much simpler to route a = request based on URI and verb(XAuth), then parse and inspect a JSON = payload (XYZ)

See above.

 

 


 

The = modes in XAuth are much more limiting, as the mixing of different = interaction methods is already something that we need to start figuring = out. Let=E2=80=99s say, for example, a client can do a redirect, accept = a CIBA-style ping, or do a direct app2app communication. There=E2=80=99s = a natural preference the client will have here: if it can talk to = another app directly, it=E2=80=99ll try that first. If that doesn=E2=80=99= t work, it can get a push notification sent, and if all that fails, it = can pop open a browser. If I have to = pick just one of those modes when I make the request, then the client = needs to make three different requests to the AS before I get anything = that works. 
Have you read the revised draft? As I = noted above, I have added negotiation. The Client can state all the = modes it wants, the GS can respond with the modes it will support, and = the Client can offer the User any modes returned from the = GS.

Yes, did you read what I wrote? I think = we=E2=80=99re talking past each = other.

This is not how XAuth is written = currently. The Client can list all of the modes it wants to use. The = Server will return all the modes that fit in its policy for the Grant = Request. Why would the Client need to make different requests?

per

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-3.4.2  

The interaction object contains one or more interaction mode = objects per Section 5

Three modes are defined here:

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-5

More modes may defined in extensions, or in this = document.

Yes, this is an improvement, and I=E2=80=99= m glad you=E2=80=99re moving your thinking in this direction. However, = it=E2=80=99s still not as clear how things combine to solve different = use cases, and it conflates the means of getting the user TO the = interaction page with the way of getting them BACK from it. It=E2=80=99s = these flexible combinations that I think are important, and I don=E2=80=99= t think XAuth gets this quite right = yet. 

I think how the user gets to and from = the server is CRITICAL to the server if it wants to protect itself from = a session fixation attack.
See above where the = client does not know what it can actually do that the server will = allow.

It is critical that the server knows = how to protect itself, yes. It=E2=80=99s not critical that the way there = and the way back are tightly bound to each other in this way. I think = that model is limiting.

What other way back are you envisioning = there could be besides a URI redirect?

Rolling between mobile apps is a URI = redirect. What else could happen?

I expect there will be new ways of = transferring control to a GS, or that the GS will reach out to the user = directly.


Push notifications on a mobile platform, = COAP-style subscriptions at the HTTP layer, messages coming in over a = blockchain fabric through a separate entity=E2=80=A6

I think your view of what a client is and how it = could communicate and interact is limited, and that=E2=80=99s informing = XAuth=E2=80=99s design.

 

 
<snip>

It is an OR in that if the client is = using the type "oauth_scope", they cannot have an = "authorization_details" attribute, they can only have "scope"

If the client is using = the type "oauth_rich", the client MUST = include "authorization_details", and MAY include "scope"
 
I have updated the the doc to = better capture that:

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-3.4.4

and example 2 now is of type "oauth_rich"

https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#secti= on-3.2


It was not clear to me that both could = be sent with that mode, so thank you for updating that. But the client = still has to choose one or the other up front. Why not have a mechanism = that it can send both at all times? Why have a =E2=80=9Cmode=E2=80=9D = type switch at all? XYZ allows clients to make these combined requests = with a single consistent syntax.

And by completely externalizing this to = OAuth 2, I would argue that we lose an opportunity to more clearly = define how resources are described and used, and we inherit the same = combination issues that are facing RAR today. We can do better because = we get to define the context.

This group can define a = new syntax if it wants, and it will be unencumbered by the OAuth 2 and = RAR legacy if deployments that want to use the OAuth 2 and RAR syntax = can use them directly. Ie, there can be a type "gnap" or some = such.

You did not respond to = this response. 


What I=E2=80=99m proposing in XYZ is exactly the = new syntax that incorporates both RAR and scope natively by using = handles and polymorphic JSON. Other resource request syntaxes could also = be defined and added.

The next section I have put into a separate email.

/Dick

3D""=E1=90=A7

= --Apple-Mail=_3A1E12FB-67E6-4372-91D4-507BBD232FF2-- From nobody Wed Jun 10 08:07:09 2020 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 0FA5B3A03FF for ; Wed, 10 Jun 2020 08:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 PD2WgLei4Jm5 for ; Wed, 10 Jun 2020 08:07:05 -0700 (PDT) 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 E188A3A0598 for ; Wed, 10 Jun 2020 08:07:04 -0700 (PDT) Received: from [192.168.1.14] (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 05AF71Jg017668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 10 Jun 2020 11:07:01 -0400 From: Justin Richer Message-Id: <083D078A-10B2-4764-BEC9-AD9A783512CD@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_B53884DF-EFA0-4227-955E-B2B29C365873" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 10 Jun 2020 11:07:00 -0400 In-Reply-To: Cc: txauth@ietf.org, Mike Jones To: Dick Hardt References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs XAuth-08) 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, 10 Jun 2020 15:07:08 -0000 --Apple-Mail=_B53884DF-EFA0-4227-955E-B2B29C365873 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 9, 2020, at 4:14 PM, Dick Hardt wrote: >=20 > Forking this topic to a new thread >=20 > +Mike as he has expressed concern about creating new identity claims >=20 > On Tue, Jun 9, 2020 at 9:10 AM Justin Richer > wrote: >=20 >=20 >> On Jun 8, 2020, at 5:33 PM, Dick Hardt > wrote: >>=20 >>=20 >>=20 >> On Mon, Jun 8, 2020 at 1:02 PM Justin Richer > wrote: >>=20 >=20 > =20 >>> I don't follow how this would work. Perhaps you could provide an = example in JSON? >>=20 >> One method is defining a new value inside the XYZ =E2=80=9Cclaims=E2=80= =9D request object that maps to a specific sub-schema: >>=20 >> claims: { >> =E2=80=9Csubject=E2=80=9D: true, >> =E2=80=9Cemail=E2=80=9D: true, >> =E2=80=9Coidc=E2=80=9D: { >> "userinfo": >> { >> "given_name": {"essential": true}, >> "nickname": null, >> "email": {"essential": true}, >> "email_verified": {"essential": true}, >> "picture": null, >> "http://example.info/claims/groups = ": null >> }, >> "id_token": >> { >> "auth_time": {"essential": true}, >> "acr": {"values": ["urn:mace:incommon:iap:silver"] } >> } >> } >> } >>=20 >> That should look pretty familiar. Alternatively, this could be done = with a separate top-level request object field: >>=20 >>=20 >> claims: { >> =E2=80=9Csubject=E2=80=9D: true, >> =E2=80=9Cemail=E2=80=9D: true >> }, >> =E2=80=9Coidc_claims_request=E2=80=9D: { >> "userinfo": >> { >> "given_name": {"essential": true}, >> "nickname": null, >> "email": {"essential": true}, >> "email_verified": {"essential": true}, >> "picture": null, >> "http://example.info/claims/groups = ": null >> }, >> "id_token": >> { >> "auth_time": {"essential": true}, >> "acr": {"values": ["urn:mace:incommon:iap:silver"] } >> } >> } >>=20 >> In both cases the AS is going to need to knit them together into a = sensible request policy, especially since the OIDC claims query language = has overlapping implications to one particular resource, the UserInfo = endpoint. My contention wasn=E2=80=99t with your proposed solution, my = contention was you claiming that XYZ has a fixed schema and is therefore = limited in extensibility. >>=20 >> One of the objectives of this work is to have extension points. My = point was that XAuth had a clear extension point for adding schemas. How = to extend XYZ was not clear in your proposal. >>=20 >=20 > I am sorry that the extensibility of the protocol was not clear. It is = stated in each section that additional items can be added, and I have = stated repeatedly that it=E2=80=99s extensible and demonstrated how, = here on this list.=20 >=20 >> I think the XAuth proposal is better than the two examples you = proposed. In your first example, the schema is a second class schema, = and in your second example, claims are spread across to top level = options. Both of these pollute other schemas. >>=20 >=20 > Not surprisingly, I disagree about the cleanliness of XAuth=E2=80=99s = proposed approach. The proposal here adds external schemas as extensions = instead of relying on them internally.=20 >=20 > If anything, I think that the OpenID Foundation would be the ones to = define how to make an OIDC claims request using this protocol, not us, = since they own and control that query syntax and everything it implies. = We can provide a means of extension. >=20 > I also think there=E2=80=99s value in defining a set of core = interoperable identity fields, which themselves could also be extended.=20= >=20 > All of these mechanisms should be controlled by some combination of = registries and collision-resistant namespaces, which is the approach = I=E2=80=99ve taken for extensibility throughout XYZ. >=20 >=20 > JSON by its nature is extensible. Adding new members to an object is = straight forward. XYZ is not unique here. It sounds like your idea of = extensibility is telling people that they can add new members to JSON. = Of course they can. That is like saying you can add new query parameters = to a front channel OAuth 2 request. >=20 Yes, exactly. And that=E2=80=99s exactly how OAuth 2 has been extended. = I=E2=80=99m glad you see that now. > My concern was that XYZ does not have a clear way to add new identity = claim schemas. You have two examples, add a schema as a member of the = claims object, which is mixing claims with schema extensions, or adding = a root member, which is then putting claims into more than one place. It = is not clear where to add a new schema, so we could easily end up with = new schemas in both places. That sounds confusing. >=20 > In XAuth, the members of the claims object are the schema. Adding a = new schema is done one, consistent way. I provided a couple examples off the cuff of possible ways to extend = something, as your base claim was that XYZ could not be extended with = new or external query schemas. Of the two, I think that it makes more = sense for it to be a separate top-level object. Why? Because the OIDC = =E2=80=9Cclaims=E2=80=9D request syntax not only dictates claims within = the OIDC schema, it also specifies how the information comes back. The = XYZ claims request talks about information that comes back in the XYZ = claims section of the response. Since the OIDC request allows for = targeting specifically to the ID token and UserInfo Endpoint, I think it = is much cleaner to be at the top level as its own thing.=20 >=20 > wrt. "defining a set of core interoperable identity fields", the = charter says we should be NOT develop a new schema: >=20 > The group is chartered to develop mechanisms for conveying identity = information within the protocol including identifiers (such as email = addresses, phone numbers, usernames, and subject identifiers) and = assertions (such as OpenID Connect ID Tokens, SAML Assertions, and = Verifiable Credentials). The group is not chartered to develop new = formats for identifiers or assertions, nor is the group chartered to = develop schemas for user information, profiles, or other identity = attributes, unless a viable existing format is not available. >=20 > wrt. OIDC claims, the charter explicitly calls out developing = mechanisms for conveying ... OIDC ID Tokens. >=20 > =E1=90=A7 Precisely: the charter says we will have a way to convey identifiers and = assertions. The XYZ =E2=80=9Cclaims=E2=80=9D section lists identifiers = that can come back, in plain text, and assertions, that can also come = back along side them. It=E2=80=99s not a full query language and isn=E2=80= =99t intended to be, and I think that it would actually be dangerous for = this to be a full identity schema, but it is itself extensible = internally if someone wants to do that. Claiming that a list of = identifiers is =E2=80=9Cdeveloping a new schema=E2=80=9D is an argument = several bridges too far from reality. I picked a couple examples out of = thin air, with the idea that we=E2=80=99d bikeshed them eventually and = tie them to a registry. We might want to re-use a set of identifiers = here, and for that I actually like Annabelle Backman=E2=80=99s proposal = to the SECEVENT group better than most that I=E2=80=99ve seen in the = space: https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers = As many of you know, I kept all identity stuff out of XYZ initially, but = there was enough interest within the group here for me to give it a shot = to see what it would look like. In designing the =E2=80=9Cclaims=E2=80=9D = capability of XYZ, I took several pages from Aaron Parecki=E2=80=99s = blog post on the topic from last year, which I still think is a valuable = read if you haven=E2=80=99t yet: https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz = =E2=80=94 Justin= --Apple-Mail=_B53884DF-EFA0-4227-955E-B2B29C365873 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun 9, 2020, at 4:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Forking= this topic to a new thread

+Mike as he has = expressed concern about creating new identity claims

On Tue, Jun = 9, 2020 at 9:10 AM Justin Richer <jricher@mit.edu> wrote:


On Jun = 8, 2020, at 5:33 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Mon, Jun 8, 2020 at 1:02 PM Justin = Richer <jricher@mit.edu> wrote:

<= div class=3D""><snip> 
I = don't follow how this would work. Perhaps you could provide an example = in JSON?

One method is defining a new value = inside the XYZ =E2=80=9Cclaims=E2=80=9D request object that maps to a = specific sub-schema:

claims: {
  =  =E2=80=9Csubject=E2=80=9D: true,
   =E2=80=9Cemail=E2=80=9D: true,
   =E2=80=9Coidc=E2=80=9D: = {
      =  "userinfo":
  =       {
  =        "given_name": {"essential": = true},
      =    "nickname": null,
         "email": {"essential": = true},
      =    "email_verified": {"essential": true},
         "picture": = null,
      =    "http://example.info/claims/groups": = null
      =   },
    =    "id_token":
 =       {
  =        "auth_time": {"essential": = true},
      =    "acr": {"values": ["urn:mace:incommon:iap:silver"] = }
        = }
      = }
}

That should look pretty familiar. = Alternatively, this could be done with a separate top-level request = object field:


claims: {
   =E2=80=9Csubject=E2=80=9D: true,
   =E2=80=9Cemail=E2=80=9D: = true
},
=E2=80=9Coidc_claims_request=E2=80=9D: {
       "userinfo":
        {
  =        "given_name": {"essential": true},
         "nickname": null,
         "email": {"essential": = true},
        =  "email_verified": {"essential": true},
  =        "picture": null,
  =        "http://example.info/claims/groups": = null
        },
       "id_token":
        {
  =        "auth_time": {"essential": true},
         "acr": {"values": = ["urn:mace:incommon:iap:silver"] }
    =     }
}

In both cases the AS is going to need to knit them together = into a sensible request policy, especially since the OIDC claims query = language has overlapping implications to one particular resource, the = UserInfo endpoint. My contention wasn=E2=80=99t with your proposed = solution, my contention was you claiming that XYZ has a fixed schema and = is therefore limited in = extensibility.

One of the objectives of this work is = to have extension points. My point was that XAuth had a clear extension = point for adding schemas. How to extend XYZ was not clear in your = proposal.


I am sorry that the extensibility of = the protocol was not clear. It is stated in each section that additional = items can be added, and I have stated repeatedly that it=E2=80=99s = extensible and demonstrated how, here on this list. 

I = think the XAuth proposal is better than the two examples you proposed. = In your first example, the schema is a second class schema, and in your = second example, claims are spread across to top level options. Both of = these pollute other schemas.


Not surprisingly, I disagree about the = cleanliness of XAuth=E2=80=99s proposed approach. The proposal here adds = external schemas as extensions instead of relying on them = internally. 

If anything, I think that the OpenID Foundation would be the = ones to define how to make an OIDC claims request using this protocol, = not us, since they own and control that query syntax and everything it = implies. We can provide a means of extension.

I also think there=E2=80=99s value in = defining a set of core interoperable identity fields, which themselves = could also be extended. 

All of these mechanisms should be = controlled by some combination of registries and collision-resistant = namespaces, which is the approach I=E2=80=99ve taken for extensibility = throughout XYZ.


JSON= by its nature is extensible. Adding new members to an object is = straight forward. XYZ is not unique here. It sounds like your idea of = extensibility is telling people that they can add new members to = JSON. Of course they can. That is like saying you can add new query = parameters to a front channel OAuth 2 request.


Yes, exactly. And that=E2=80=99s exactly how OAuth = 2 has been extended. I=E2=80=99m glad you see that now.

My = concern was that XYZ does not have a clear way to add new identity claim = schemas. You have two examples, add a schema as a member of the claims = object, which is mixing claims with schema extensions, or adding a root = member, which is then putting claims into more than one place. It is not = clear where to add a new schema, so we could easily end up with new = schemas in both places. That sounds confusing.

In XAuth, the members of the claims = object are the schema. Adding a new schema is done one, consistent = way.

I = provided a couple examples off the cuff of possible ways to extend = something, as your base claim was that XYZ could not be extended with = new or external query schemas. Of the two, I think that it makes more = sense for it to be a separate top-level object. Why? Because the OIDC = =E2=80=9Cclaims=E2=80=9D request syntax not only dictates claims within = the OIDC schema, it also specifies how the information comes back. The = XYZ claims request talks about information that comes back in the XYZ = claims section of the response. Since the OIDC request allows for = targeting specifically to the ID token and UserInfo Endpoint, I think it = is much cleaner to be at the top level as its own thing. 


wrt. "defining a set of core = interoperable identity fields", the charter says we should be NOT develop a new = schema:

The group is = chartered to develop mechanisms for conveying identity information = within the protocol including identifiers (such as email = addresses, phone numbers, usernames, and subject identifiers) and = assertions (such = as OpenID Connect ID Tokens, SAML Assertions, and Verifiable = Credentials). The group is not chartered to develop new formats for = identifiers or assertions, nor is the group chartered to develop schemas = for user information, profiles, or other identity attributes, unless a = viable existing format is not = available.

wrt. OIDC claims, the = charter explicitly calls out developing mechanisms for conveying ... OIDC ID = Tokens.

3D""=E1=90=A7

Precisely: the = charter says we will have a way to convey identifiers and assertions. = The XYZ =E2=80=9Cclaims=E2=80=9D section lists identifiers that can come = back, in plain text, and assertions, that can also come back along side = them. It=E2=80=99s not a full query language and isn=E2=80=99t intended = to be, and I think that it would actually be dangerous for this to be a = full identity schema, but it is itself extensible internally if someone = wants to do that. Claiming that a list of identifiers is =E2=80=9Cdevelopi= ng a new schema=E2=80=9D is an argument several bridges too far from = reality. I picked a couple examples out of thin air, with the idea that = we=E2=80=99d bikeshed them eventually and tie them to a registry. We = might want to re-use a set of identifiers here, and for that I actually = like Annabelle Backman=E2=80=99s proposal to the SECEVENT group better = than most that I=E2=80=99ve seen in the space:

https://tools.ietf.org/html/draft-ietf-secevent-subject-identif= iers

As = many of you know, I kept all identity stuff out of XYZ initially, but = there was enough interest within the group here for me to give it a shot = to see what it would look like. In designing the =E2=80=9Cclaims=E2=80=9D = capability of XYZ, I took several pages from Aaron Parecki=E2=80=99s = blog post on the topic from last year, which I still think is a valuable = read if you haven=E2=80=99t yet:

https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz

 =E2=80=94= Justin
= --Apple-Mail=_B53884DF-EFA0-4227-955E-B2B29C365873-- From nobody Wed Jun 10 19:22:16 2020 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 419873A0D7A for ; Wed, 10 Jun 2020 19:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=adorsys.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GJqfXpagiJa for ; Wed, 10 Jun 2020 19:22:12 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 965233A157D for ; Wed, 10 Jun 2020 19:22:12 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id l10so4438358wrr.10 for ; Wed, 10 Jun 2020 19:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:from:date:message-id:subject:to; bh=1jYGqzGg48LEUaC9uNWjsUgwArGihx37MJPwD+0MOOA=; b=gcR8MsygT4QYMYWL+1X9UfrN2ZUSWxiwV/i+oxzD0HKjs6BkS4W56BJlHaMQmkwSxR BNjvZzInL7Zjyw2RgjT4RfxDAHkXpaD8PYFxjF2jlueiii9zcpxrN0ugGMVRGKDAOZMY EWZHoBJjuykgcSy7+UQgxNOxYQIYje0mUBDsM= 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=1jYGqzGg48LEUaC9uNWjsUgwArGihx37MJPwD+0MOOA=; b=CxgXjJWBcxCF8YgirMz+w3r5PLH4pW/BZyJ1hdykkGsz9ZQOxazJfSLccK6ApVYJpd Oi64TrxGPh2f5l2ge03yV8wUVdxe9EACCWOs6Qu+W+5aEBJayoYwV9wsGaHx6DqXHcjA eYMtSXM7L4E3sgb1NlGIO/VB2dy/WtXDcOgPPvRdlbUDUCF/fKHI5L7l0Z6eKGpDB3K7 xAX5xztO0ywYE7q+vDozCn+O5WyP32PeMtp04NpmKQjpwoq/bCJBw5VFyA7F4A3q9pKl D1jnXG+ASApAyUcA88szExM8mjAqvq8DKl3QQX8AfNYcKZCNQX8A7dZhXJVWI3rhwz0I hbYA== X-Gm-Message-State: AOAM533Ig0bT3g9cpYFtKyqrpbjyFTG+qQVNfvV0mPdl1sDcVIMoBHC0 1UORQhOkZn0m92Bj3ZXMgIJXO8Y6O3jgKNLG18RYvKzd X-Google-Smtp-Source: ABdhPJyPmKqX3ENnq4DhWcG3f5fN02smjXaE6zVGrHSK8qRTaUDuYF6shLLhkSi8MMomI1Zv55/OThpmf16A+T80ORE= X-Received: by 2002:a5d:4bc5:: with SMTP id l5mr7008090wrt.104.1591842130788; Wed, 10 Jun 2020 19:22:10 -0700 (PDT) MIME-Version: 1.0 From: Francis Pouatcha Date: Wed, 10 Jun 2020 22:21:59 -0400 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000be98b405a7c5a0c0" Archived-At: Subject: [Txauth] Use of word transaction request vs. transaction authorization request 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, 11 Jun 2020 02:22:14 -0000 --000000000000be98b405a7c5a0c0 Content-Type: text/plain; charset="UTF-8" I just read through the last version of txauth. There is a need to associate clear definition to following keyword to prevent confusion in productive systems: - <>: this shall be used to describe the call sent by the RC to the RS. The response of this call shall be the <>. - <>: this shall be used to describe the call sent by the RC to the AS. The response of the call shall also be the <>. The word transaction is currently used to designate this last call. -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ --000000000000be98b405a7c5a0c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000be98b405a7c5a0c0-- From nobody Wed Jun 10 19:30:07 2020 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 BBD763A1645 for ; Wed, 10 Jun 2020 19:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=adorsys.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etlxxOUOagQ8 for ; Wed, 10 Jun 2020 19:30:04 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 38F6D3A1643 for ; Wed, 10 Jun 2020 19:30:04 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id u26so5902797wmn.1 for ; Wed, 10 Jun 2020 19:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:from:date:message-id:subject:to; bh=wPPJO7PCkRxoE79M75akBqN3IdhfJXNEP2M2wW1EM8k=; b=XPvG+pvR8K7kqoGh/QWEtovnimWbl0AU3/7ejboDxgFMO110x96gKEGtsEib31g0Ax aX18LhxsKcxY4BvvFYsS3NlJIT7xYKMV0yW+y3JEf3EOW7AazHpG2z4wbOvSahlMsqFo LIC0i5nTnaPqFF/0D+iA0TM2sU+7O1WGuthis= 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=wPPJO7PCkRxoE79M75akBqN3IdhfJXNEP2M2wW1EM8k=; b=oQHpCUxql8HeNIgchkI/gq4ySQgDavTcP2lIphxiWBYxKksDwqZq48fos4gvFRAxOK rEIlvVVyy0U9V3r2NGQU+Bb9gp37CRVSHdUgzG/GJvxHiHRviXgJQdGiBcETlexgvmHT zCAAArfZEJCbh7/dMOO2X5BOaWrfoPP/6jgPDIjYndOc+uwDOAoOwzj8OpLjxePlozQl 9uBYc7lCdP3pGJlq/0vJ4nCLqO+tas3HpBNjq+8uf8MI2wY0J+XoH6QkN4YIjtlIGJj4 AY8g1byCb8diu1cXooMt3t5oT6aUuXtrHcIbZMJHKqIEQRM1K3W2Nq5g1sTO6ZR1FW3Q 1NDw== X-Gm-Message-State: AOAM531CyDSSYv7ChvvuhU1010Y0pYju8m3FLfIzeBpHZepqhvewIptd x5sMlrwJ624/S/Xth7zBAqALgSdDiNUjl5YEHqec8lOIKxc= X-Google-Smtp-Source: ABdhPJywAs2A8ADVXF3V8PiB8ZtRz2sH0aM6Fr8q7WG7FqqemqpCe9lh+H/nd+KCCnKw0vf6pGQr0S9AyfNLwQeS8jY= X-Received: by 2002:a1c:9802:: with SMTP id a2mr5545905wme.64.1591842602331; Wed, 10 Jun 2020 19:30:02 -0700 (PDT) MIME-Version: 1.0 From: Francis Pouatcha Date: Wed, 10 Jun 2020 22:29:51 -0400 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000d9c7f205a7c5bcf1" Archived-At: Subject: [Txauth] Transactional Authorization vs Transaction Authorization 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, 11 Jun 2020 02:30:06 -0000 --000000000000d9c7f205a7c5bcf1 Content-Type: text/plain; charset="UTF-8" Reading through <>, I really do enjoy the simplicity of the authorization flow defined. I have the feeling the title of the rfp shall be shifted to reflect the content of the document. I would prefer calling it "Transaction Authorization" and not "Transactional Authorization". I could not find the transactional character authorization flow described here, but what is clearly emphasized through the specification is the use of the described flow to authorize transactions. -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ --000000000000d9c7f205a7c5bcf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reading through <<draft-richer-transactional-authz-0= 8>>, I really do enjoy the simplicity of the authorization flow defin= ed. I have the feeling the title of the rfp shall be shifted to reflect the= content of the document.

I would prefer calling it &quo= t;Transaction Authorization" and not "Transactional Authorization= ". I could not find the transactional character authorization flow des= cribed here, but what is clearly emphasized through the specification is th= e use of the described flow to authorize transactions.
--000000000000d9c7f205a7c5bcf1-- From nobody Wed Jun 10 20:12:40 2020 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 E73FA3A1658 for ; Wed, 10 Jun 2020 20:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=adorsys.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMm-84vfS5zW for ; Wed, 10 Jun 2020 20:12:37 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 CFCF73A1627 for ; Wed, 10 Jun 2020 20:12:36 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id x13so4537972wrv.4 for ; Wed, 10 Jun 2020 20:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adorsys.de; s=google; h=mime-version:from:date:message-id:subject:to; bh=k9hX7UXYlGsi0l8m73y2L3W501YpPskGPuNrnnPpA/U=; b=dFKM7y4yNdcTbRqwdGaTNBzp4QCRZ64dKH4yrCILk+96kOLeZZiQtWfAMeq4rps5+E B2Wd8pUoshxK2iLZvYwCn66A5DkEGikcNKbqmTeKkEjNELEe43/RPBSHmUckPfeGCNUq YORrun3Uxmh4jASDCnUvEbzMtcLaygPXbCL2M= 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=k9hX7UXYlGsi0l8m73y2L3W501YpPskGPuNrnnPpA/U=; b=R+ciyx0AIAebsbDFP0o+fkh3P9J92fExI9VPkzcox/bdVVnxlmIMoUrjAx3i0oKDhM kPmXJjfdbVdGf9fKn4PHpLGEMgQruJR8NB9P9l+n4XQV1YcrhjNe0noGx46PQFTEZ2x5 5ML7AsvYPmAuLCf/a2ETsAUJcB2bSTr7jl0RRPlBG33ouMc/f2ZzIdqtfYhuc3K8yIrN p6CErtgNDzd06N9zZfjhVhGGzkZHu2CViKQI+QvE1ausNpLcZVC3weHNzEXsy51tZtSA DPgKD4IUHy90jqTzATsBb/IlN0x0V8OKxsyj+YXlyrme49nKIPsploKLOU/fmO8zEnMN I7Qw== X-Gm-Message-State: AOAM530cCG2bnn5HJ1uNdqVL/NyikqwaXuWVgVtoOJlGgptLgpoqIK7W GeP8oa9hmr8JFWKgQgy93pnw6/+Z7+QLkkteN3/zz8FQ X-Google-Smtp-Source: ABdhPJzPbdWXo8PGv5nluFzLmyOj6+pTWcbZO89efNrxE11VMUtFHVOm8pYFMXABrLiQDUoX18SJhdPT0LIy2yzz7Kk= X-Received: by 2002:adf:e545:: with SMTP id z5mr6773636wrm.89.1591845154820; Wed, 10 Jun 2020 20:12:34 -0700 (PDT) MIME-Version: 1.0 From: Francis Pouatcha Date: Wed, 10 Jun 2020 23:12:23 -0400 Message-ID: To: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000fda97d05a7c65431" Archived-At: Subject: [Txauth] Interact Section 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, 11 Jun 2020 03:12:39 -0000 --000000000000fda97d05a7c65431 Content-Type: text/plain; charset="UTF-8" The interact section of the <> sort of defines the choreographie of the authorization process (flow). I am missing something like: - A redirect flow here the AS instructs the RC to redirect to RO to the given interaction URL. Upon completing the RO interaction, the RO will be redirected back to the callback.uri specified by the RC. SO there is no callback here. - A decoupled flow is actually not visible. This is, I assume upon receiving the <>, the AS initiated an interaction with the RO (-device). Upon completion of the interaction with the RO, the AS invokes the provided callback.uri to deliver the token (authorization) used by the RC to proceed with the transaction request>>. - An embedded flow seems hidden behind the didcom section. With the evolding number smart devices, the embedded flow shall open room for different types of synchronous transaction authorization requests in which the RO gives a verifiable assertion (proof of possession) to the RC for use at the <> in exchange for the seeked access token. This assertion can range from a simple password to a cryptographically signed claim. "interact": { "embedded":[{ "mode":"encrypted password" }, { "mode":"didcom" }], "redirect":[{ "callback": { "uri": "https://example.com/rc-front-channel/123456", "nonce": "VJLO6A4CAYLBXHTR0KRO" } }], "decoupled": [{ "callback": { "uri": "https://example.com/rc-back-channel/123456", "nonce": "VJLO6A4CAYLBXHTR0KRO" } }] } Still no idea on how to express the RC flow preferences to the AS. Maybe the order of entries in the interact sesion -- Francis Pouatcha Co-Founder and Technical Lead at adorys https://adorsys-platform.de/solutions/ --000000000000fda97d05a7c65431 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The interact section of the <<draft-richer-transacti= onal-authz-08>> sort of defines the choreographie of the authorizatio= n process (flow). I am missing something like:

- A redir= ect flow=C2=A0
here the AS instructs the RC to redirect to RO to = the given=C2=A0interac= tion URL.=C2=A0 Upon completing the RO interaction, the RO will be redirect= ed back to the=C2=A0callback.uri=C2=A0specified by the RC. SO there is no callback here.

- A decoupled flow=C2=A0
is actually not visible.= This is, I assume upon receiving=C2=A0the=C2=A0 <<transaction author= ization request>>, the AS initiated=C2=A0an interaction with the RO (= -device). Upon completion of the interaction with the RO, the AS invokes th= e provided callback.uri to deliver the token (authorization) used by the RC= to proceed=C2=A0with=C2=A0 the transaction request>>.

=
- An embedded flow
seems hidden behind the didcom sect= ion. With the evolding number smart devices, the embedded flow shall open r= oom for different types of synchronous transaction authorization requests i= n which the RO gives a verifiable assertion (proof of possession) to the RC= for use at the <<transaction authorization endpoint>> in excha= nge for the seeked access token. This assertion can range from a simple pas= sword to a cryptographically signed claim.

=
"interact": {
=C2=A0 "embedded":[{
=C2=A0 = =C2=A0 =C2=A0 "mode":"encrypted password"
=C2= =A0 =C2=A0 },
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "mod= e":"didcom"
=C2=A0 =C2=A0 }],
=C2=A0 =C2=A0"= redirect":[{
=C2=A0 =C2=A0 =C2=A0 "callback": {
=C2=A0= =C2=A0 =C2=A0 =C2=A0 "uri": "https://example.com/rc-front-ch= annel/123456",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "nonce": &= quot;VJLO6A4CAYLBXHTR0KRO"
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 = }],
=C2=A0 =C2=A0 "decoupled": [{
=C2=A0 =C2=A0 =C2=A0 &quo= t;callback": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "uri": "<= a href=3D"https://example.com/rc-back-channel/123456" target=3D"_blank">htt= ps://example.com/rc-back-channel/123456",
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 "nonce": "VJLO6A4CAYLBXHTR0KRO"
=C2=A0 =C2=A0= =C2=A0 }
=C2=A0 =C2=A0 }]
}

Still no id= ea on how to express the RC flow preferences to the AS. Maybe the order of = entries in the interact sesion
--
Francis Pouatcha
Co-Foun= der and Technical Lead at adorys
--000000000000fda97d05a7c65431-- From nobody Thu Jun 11 02:14:07 2020 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 903CF3A177D; Thu, 11 Jun 2020 02:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 jXtAVvq5O3ku; Thu, 11 Jun 2020 02:14:03 -0700 (PDT) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 5C17D3A177B; Thu, 11 Jun 2020 02:14:02 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id cv17so2315216qvb.13; Thu, 11 Jun 2020 02:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=//WjQ3jyDzuDJVrCFy9y4rxRbkcizEn5zn3c6upA7gk=; b=ZFQaKKDLhLYDNLvnj7KkvVMOtqqY+RVCmOsohvpqsBGswLZA5i15BVEwIJkAWHQ/Ku LyKZVgig5OwN2EgbUmhln3Cmxhy17S+d7RMDM/lZapUrhjmIHhor2jqUrbASiI82i08V +k+LKVwP/zpHqFqlraiqZmnTsd4zRW9w+O82mdyAUxLnUpPN/RfVt10VUDK1p4Mw9BqR V/GaGZVoEYe80mFiETEjmnPBRMnE/ZeI8M5nFLtAUtorZpGrMkranYm8oV99ERGpjHvq Q1rl/sDPaBAbMXjSFp2Kbz9zz35KimoKykh7hDhFQvVcLstL4B23mF1FalWREgiM5Kn2 eyVw== 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:message-id :thread-topic:references:in-reply-to:mime-version; bh=//WjQ3jyDzuDJVrCFy9y4rxRbkcizEn5zn3c6upA7gk=; b=aJBAyTACJYw6A481k7bnaOXDmh7lSawvVtp3Jj805+M5R/OOWdpYaaEmJYvJYGSN// XJuKox7QSe9ooIaeor2nNoajS+aiH8JKzQr1YP6UtCthCGvpwdE2Po2ISNZxzFQzZEPc D4tXO66x0E84LEdm0ZfNt4lkqgn97AfXj/je7WxF7ljuJ192HtounAycAJSKv2BpCAWB 7X09X9hmVRlBotXhL5WJ7h5lGmVwZz+AFqo7yWSQpVqDd7SUU/svL9YlKGvMnLRKJNy3 Gli+5sCYfMP4wJbM9AzJibOCNTF7WnxnSEN1npJGiN6tmckmvDGnHn7Hn7Vjhq437D65 VtgA== X-Gm-Message-State: AOAM533AZGE56QkKg9kPF5W8xumetJOreRWyYojp1zek4+yL807CzsRk fji0EPxI75lNeF6psyyo6dv//Ipb X-Google-Smtp-Source: ABdhPJz5itnO6zeZlZwUKN0yftgA3pF7aUZA5N3xQpaZlFIsLEqQCASF1GAS5SGTI5vCN9nGHPe3rw== X-Received: by 2002:a0c:c249:: with SMTP id w9mr6873020qvh.149.1591866841255; Thu, 11 Jun 2020 02:14:01 -0700 (PDT) Received: from [172.26.61.225] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id v3sm1612288qkh.130.2020.06.11.02.13.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2020 02:14:00 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.37.20051002 Date: Thu, 11 Jun 2020 12:13:31 +0300 From: Yaron Sheffer To: "txauth@ietf.org" , "id-event@ietf.org" Message-ID: <6E080E7D-6AAF-42A5-A14D-13E7D56F6CF2@gmail.com> Thread-Topic: Nomcom 2020-2021 Second Call For Volunteers References: <159181529656.16063.6964178024900109434@ietfa.amsl.com> <90F43A4B-9A1E-480A-B7BF-75A93842C261@att.com> In-Reply-To: <90F43A4B-9A1E-480A-B7BF-75A93842C261@att.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3674722440_2100256815" Archived-At: Subject: [Txauth] FW: Nomcom 2020-2021 Second Call For Volunteers 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, 11 Jun 2020 09:14:06 -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_3674722440_2100256815 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Folks, please consider volunteering for this round. Note that NomCom will b= e selecting a Security AD, among others. =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 Begin forwarded message: From: NomCom Chair 2020 Date: June 10, 2020 at 1:55:21 PM CDT To: IETF Announcement List Cc: "ietf@ietf.org" Subject: Nomcom 2020-2021 Second Call For Volunteers =EF=BB=BFThis is the second sending of the call for volunteers for the 2020-2021 = NomCom. I wanted to mention a few updates from the previous email (sent 2 weeks ago= ): - I've fixed the URL at the bottom of the email to point to https://urldefe= nse.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org_nomcom_2020_&d=3DDw= IDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DZsNIRqCxjDeOYYDNalO= SHcuwQG23wBJtxzmEnsbPBtI&s=3DNgIu-7Ij0nEdsFcbJOLcl2M56RxyREhLAtcaHLatD34&e=3D i= nstead of /2019/. This was a test to see if anyone was paying attention. App= arently, some people were. ;) - The IETF 108 registration form includes a checkbox that will let you volu= nteer. You can use this instead of emailing me, when you register for IETF 1= 08. - I currently have 39 volunteers. Last year had 149. I need more volunteers= ! ---------------------------------------------------------------------------= ------ The IETF NomCom appoints people to fill the open slots on the LLC, IETF Tru= st, the IAB, and the IESG. Ten voting members for the NomCom are selected in a verifiably random way f= rom a pool of volunteers. The more volunteers, the better chance we have of = choosing a random yet representative cross section of the IETF population. The details of the operation of the NomCom can be found in BCP 10 (RFC 8713= ). RFC 3797 details the selection algorithm. Special for this year (and only this year), we also have RFC 8788 (one-off = update to RFC 8713 / BCP 10) to tell us who is eligible to volunteer: Members of the IETF community must have attended at least three of the last five in-person IETF meetings in order to volunteer. The five meetings are the five most recent in-person meetings that ended prior to the date on which the solicitation for NomCom volunteers was submitted for distribution to the IETF community. Because no IETF 107 in-person meeting was held, for the 2020-2021 Nominating Committee those five meetings are IETFs 102 [Montreal, Canada; July 2018], 103 [Bangkok, Thailand; November 2018], 104 [Prague, Czech Republic; March 2019], 105 [Montreal, Canada; July 2019], and=20 106 [Singapore; November 2019]. Keep in mind that eligibility is based on in-person attendance at the five = listed meetings. You can check your eligibility at: https://urldefense.proof= point.com/v2/url?u=3Dhttps-3A__www.ietf.org_registration_nomcom.py&d=3DDwIDaQ&c=3D= LFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG= 23wBJtxzmEnsbPBtI&s=3D7_9x9PPoUIajJs2AnUFYg0KnEg8gkD3Jnwf1v079EQo&e=3D . If you qualify, please volunteer. Before you decide to volunteer, please re= member that anyone appointed to this NomCom will not be considered as a cand= idate for any of the positions that the 2020 - 2021 NomCom is responsible fo= r filling. People commonly volunteer by ticking the box on IETF registration forms. Th= e IETF 106 form did not ask whether people were willing to volunteer. IETF 1= 07 did ask, but all those registrations were canceled. I have asked the Secr= etariat if it is possible to get the list if volunteers from canceled IETF 1= 07 registrations. If that list is available, I will contact all who are veri= fied as eligible. But given the uncertainty of this process, I would encoura= ge people to volunteer directly (see the bottom of this email for instructio= ns). Thank you for volunteering! The list of people and posts whose terms end with the March 2021 IETF meeti= ng, and thus the positions for which this NomCom is responsible, are IETF Trust: Joel Halpern LLC: Maja Andjelkovic IAB: Jari Arkko Jeff Tantsura Mark Nottingham Stephen Farrell Wes Hardaker Zhenbin Li IESG: Alissa Cooper, IETF Chair/GEN AD Alvaro Retana, RTG AD Barry Leiba, ART AD Deborah Brungard, RTG AD =C3=89ric Vyncke, INT AD Magnus Westerlund, TSV AD Roman Danyliw, SEC AD Warren Kumari, OPS AD All appointments are for 2 years. The Routing area has 3 ADs and the Genera= l area has 1; all other areas have 2 ADs. Thus, all areas (that have more th= an one AD) have at least one continuing AD. The primary activity for this NomCom will begin in July 2020 and should be = completed in January 2021. The NomCom will have regularly scheduled confere= nce calls to ensure progress. There will be activities to collect requiremen= ts from the community, review candidate questionnaires, review feedback from= community members about candidates, and talk to candidates. While being a NomCom member does require some time commitment it is also a = very rewarding experience. As a member of the NomCom it is very important that you be willing and able= to attend either videoconference or in-person meetings (which may not happe= n) during 14-20 November (IETF 109 - Bangkok) to conduct interviews. Videoco= nference attendance will be supported whether or not there are in-person mee= tings. Orientation and setting of the NomCom schedule will be done by videoc= onference during the week 20-24 July (exact time and date to be determined a= fter NomCom membership is finalized on July 12), the week prior to IETF 108.= Being at IETF 110 (Prague) is not essential. Please volunteer by sending me an email before 23:59 UTC June 24, 2020, as = follows: To: nomcom-chair-2020@ietf.org Subject: NomCom 2020-21 Volunteer Please include the following information in the email body: Your Full Name:=20 // as you write it on the IETF registration form Current Primary Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails:=20 // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone:=20 // For confirmation if selected You should expect an email response from me within 5 business days stating = whether or not you are qualified. If you don't receive this response, pleas= e re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider tha= t NomCom members play a very important role in shaping the leadership of the= IETF. Questions by email or voice are welcome. Volunteering for the NomCom= is a great way to contribute to the IETF! You can find a detailed timeline on the NomCom web site at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_nomcom_2020_&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3D= ZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=3DNgIu-7Ij0nEdsFcbJOLcl2M56RxyRE= hLAtcaHLatD34&e=3D=20 I will be publishing a more detailed target timetable, as well as details o= f the randomness seeds to be used for the RFC 3797 selection process, within= the next few weeks. Thank you! Barbara Stark bs7652 at att dot com nomcom-chair-2020 at ietf dot org --B_3674722440_2100256815 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Folks, please consider volunteering for th= is round. Note that NomCom will be selecting a Security AD, among others.

 

Thank= s,

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



Begi= n forwarded message:

<= b>From: NomCom Chair 2020 <nomcom-chair-2020@ietf.org>
Date:= June 10, 2020 at 1:55:21 PM CDT
To: IETF Announcement List &l= t;ietf-announce@ietf.org>
Cc: "ietf@ietf.org" <iet= f@ietf.org>
Subject: Nomcom 2020-2021 Second Call For Volunt= eers

= =EF=BB=BFThis is the second sending of the call for volunteers for the 2020-2021 N= omCom.

I wanted to mention a few updates from the previous email (sen= t 2 weeks ago):
- I've fixed the URL at the bottom of the email to point = to https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _nomcom_2020_&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8= Tq4vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=3DNgIu-7Ij0nE= dsFcbJOLcl2M56RxyREhLAtcaHLatD34&e=3D  instead of /2019/. This was a = test to see if anyone was paying attention. Apparently, some people were. ;)=
- The IETF 108 registration form includes a checkbox that will let you v= olunteer. You can use this instead of emailing me, when you register for IET= F 108.
- I currently have 39 volunteers. Last year had 149. I need more v= olunteers!
--------------------------------------------------------------= -------------------
The IETF NomCom appoints people to fill the open slot= s on the LLC, IETF Trust, the IAB, and the IESG.

Ten voting members f= or the NomCom are selected in a verifiably random way from a pool of volunte= ers. The more volunteers, the better chance we have of choosing a random yet= representative cross section of the IETF population.

The details of = the operation of the NomCom can be found in BCP 10 (RFC 8713). RFC 3797 deta= ils the selection algorithm.

Special for this year (and only this yea= r), we also have RFC 8788 (one-off update to RFC 8713 / BCP 10) to tell us w= ho is eligible to volunteer:

     Members of= the IETF community must have attended at least three of
  &nbs= p;  the last five in-person IETF meetings in order to volunteer.
     The five meetings are the five most rece= nt in-person meetings that
     ended prior to t= he date on which the solicitation for NomCom
    &nbs= p;volunteers was submitted for distribution to the IETF community.
 =     Because no IETF 107 in-person meeting was held, for = the 2020-2021
     Nominating Committee those fi= ve meetings are IETFs
       102 [Mont= real, Canada; July 2018],
       103 [= Bangkok, Thailand; November 2018],
      &n= bsp;104 [Prague, Czech Republic; March 2019],
    &nb= sp;  105 [Montreal, Canada; July 2019], and
   =     106 [Singapore; November 2019].

Keep in mind = that eligibility is based on in-person attendance at the five listed meeting= s. You can check your eligibility at: https://urldefense.proofpoint.com/v2/u= rl?u=3Dhttps-3A__www.ietf.org_registration_nomcom.py&d=3DDwIDaQ&c=3DLFYZ-o= 9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8SY8Tq4vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuw= QG23wBJtxzmEnsbPBtI&s=3D7_9x9PPoUIajJs2AnUFYg0KnEg8gkD3Jnwf1v079EQo&e=3D= .

If you qualify, please volunteer. Before you decide to volunteer, = please remember that anyone appointed to this NomCom will not be considered = as a candidate for any of the positions that the 2020 - 2021 NomCom is respo= nsible for filling.

People commonly volunteer by ticking the box on I= ETF registration forms. The IETF 106 form did not ask whether people were wi= lling to volunteer. IETF 107 did ask, but all those registrations were cance= led. I have asked the Secretariat if it is possible to get the list if volun= teers from canceled IETF 107 registrations. If that list is available, I wil= l contact all who are verified as eligible. But given the uncertainty of thi= s process, I would encourage people to volunteer directly (see the bottom of= this email for instructions). Thank you for volunteering!

The list o= f people and posts whose terms end with the March 2021 IETF meeting, and thu= s the positions for which this NomCom is responsible, are

IETF Trust:=
   Joel Halpern

LLC:
   Maja And= jelkovic

IAB:
   Jari Arkko
   Je= ff Tantsura
   Mark Nottingham
   Stephe= n Farrell
   Wes Hardaker
   Zhenbin Li<= br>
IESG:
   Alissa Cooper, IETF Chair/GEN AD
 =   Alvaro Retana, RTG AD
   Barry Leiba, ART AD   Deborah Brungard, RTG AD
   =C3=89ric Vync= ke, INT AD
   Magnus Westerlund, TSV AD
  &nb= sp;Roman Danyliw, SEC AD
   Warren Kumari, OPS AD

A= ll appointments are for 2 years. The Routing area has 3 ADs and the General = area has 1; all other areas have 2 ADs. Thus, all areas (that have more than= one AD) have at least one continuing AD.

The primary activity for th= is NomCom will begin in July 2020 and should be completed in January 2021. &= nbsp;The NomCom will have regularly scheduled conference calls to ensure pro= gress. There will be activities to collect requirements from the community, = review candidate questionnaires, review feedback from community members abou= t candidates, and talk to candidates.

While being a NomCom member doe= s require some time commitment it is also a very rewarding experience.
As a member of the NomCom it is very important that you be willing and abl= e to attend either videoconference or in-person meetings (which may not happ= en) during 14-20 November (IETF 109 - Bangkok) to conduct interviews. Videoc= onference attendance will be supported whether or not there are in-person me= etings. Orientation and setting of the NomCom schedule will be done by video= conference during the week 20-24 July (exact time and date to be determined = after NomCom membership is finalized on July 12), the week prior to IETF 108= .  Being at IETF 110 (Prague) is not essential.

Please volunteer= by sending me an email before 23:59 UTC June 24, 2020, as follows:

T= o: nomcom-chair-2020@ietf.org
Subject: NomCom 2020-21 Volunteer

Pl= ease include the following information in the email body:

Your Full N= ame:
   // as you write it on the IETF registration form<= br>
Current Primary Affiliation:
   // Typically what g= oes in the Company field
   // in the IETF Registration Fo= rm

Emails:
  // All email addresses used to register fo= r the past 5 IETF meetings
  // Preferred email address first
Telephone:
   // For confirmation if selected
You should expect an email response from me within 5 business days stating= whether or not you are qualified.  If you don't receive this response,= please re-send your email with the tag "RESEND"" added to th= e subject line.

If you are not yet sure if you would like to voluntee= r, please consider that NomCom members play a very important role in shaping= the leadership of the IETF.  Questions by email or voice are welcome. = Volunteering for the NomCom is a great way to contribute to the IETF!
You can find a detailed timeline on the NomCom web site at:
  =  https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.= org_nomcom_2020_&d=3DDwIDaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DLoGzhC-8sc8= SY8Tq4vrfog&m=3DZsNIRqCxjDeOYYDNalOSHcuwQG23wBJtxzmEnsbPBtI&s=3DNgIu-7Ij= 0nEdsFcbJOLcl2M56RxyREhLAtcaHLatD34&e=3D

I will be publishing a mo= re detailed target timetable, as well as details of the randomness seeds to = be used for the RFC 3797 selection process, within the next few weeks.
Thank you!

Barbara Stark
bs7652 at att dot com
nomcom-chair-2= 020 at ietf dot org

--B_3674722440_2100256815-- From nobody Thu Jun 11 08:01:40 2020 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 EF9213A08F0; Thu, 11 Jun 2020 08:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 JrOkjVm8A7GD; Thu, 11 Jun 2020 08:01:36 -0700 (PDT) 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 2AB2A3A08DB; Thu, 11 Jun 2020 08:01:35 -0700 (PDT) Received: from [192.168.1.14] (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 05BF1XMf025497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jun 2020 11:01:34 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5AA39BB4-1362-4D89-B449-C006DB8E8E01" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 11 Jun 2020 11:01:33 -0400 In-Reply-To: Cc: txauth@ietf.org To: Francis Pouatcha References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Interact Section 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, 11 Jun 2020 15:01:39 -0000 --Apple-Mail=_5AA39BB4-1362-4D89-B449-C006DB8E8E01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 XYZ doesn=E2=80=99t look at interaction in terms of =E2=80=9Cflows=E2=80=9D= but instead in terms of discrete capabilities, and this is a deliberate = move beyond what OAuth 2 allows for. Each member of the interaction = request represents one piece of the whole set of capabilities the client = is able to do. For what=E2=80=99s in there right now: redirect: this tells the AS that the client can get the user to an = arbitrary URL, determined at runtime by the AS. This URL is taken as a = whole without the client doing anything to it. The client can do = whatever makes the most sense for the client in order to get that user = to the URL. It could redirect them, it could open up a browser, it could = display a scannable code, it could email them a link to click on, etc. = Importantly, this says nothing about how the user gets back =E2=80=94 = more on that in a minute. This could be renamed = =E2=80=9Carbitarily_long_url=E2=80=9D or something more general. user_code: this tells the AS that the client can tell the user about a = short user-typable code and direct them to a static URL that the client = should be able to know outside of the protocol. It doesn=E2=80=99t say = anything about how the client gets the user there, and it doesn=E2=80=99t = say anything about how the user gets back.=20 callback: this tells the AS that the client can receive a response on = the given URL when the client is done interacting with the AS. It says = nothing about how the user got there =E2=80=94 they could have gone to = an arbitrary URL via redirect, they could have gone to a static URL and = entered a code, they could have gotten a push notification to a = different application they have installed. What=E2=80=99s important here = is that this allows the client and AS to prevent certain kinds of = attacks, including session fixation, by coupling a front-channel = response with a back-channel response.=20 didcomm/didcomm_query: these tell the AS that the client could speak the = DIDCOMM protocol to pass messages around to an agent via some kind of = DID-enhanced communication fabric. The XYZ spec is light on details here = because, to me, these are largely examples of what else could be done = outside of HTTP. If we brought these into the eventual GNAP = specification I would expect them to be in their own DIDCOMM-focused = interaction extension. I really wasn=E2=80=99t trying to hide the = extensibility within the DIDCOMM specs; I would much rather we be clear = about how things work together in our own spec than to punt all = extensibility to external groups and claim success. But now that you have the parts, in order to make the =E2=80=98flows=E2=80= =9D you have below, you combine these capabilities and probably invent a = few other interaction methods to add to them. That=E2=80=99s where the = extensibility of this model really comes into play: you don=E2=80=99t = define a comprehensive =E2=80=9Cflow=E2=80=9D with all of the = interaction parts, you define what new parts you need and use them in = combination to solve your use case. This allows you to re-use = well-defined behaviors, and for all behaviors to have pretty narrow = scopes and expectations of use. There are a few potential future interaction options that I think = deserve some thought at some point within the group: webauthn: basically a way for the client to propose a webauthn = challenge/response to the AS. The AS would respond to the initial = request with a challenge to be signed, and the client would sign it and = return it directly after having interacted with the user to unlock their = key store. So really I mean any number of FIDO-style key stores and = devices here. password: as much as I hate this, someone=E2=80=99s going to want to = have the client prompt for credentials directly with the user in an = interaction mechanism, equivalent to the resource owner password grant = in OAuth 2. I do not think this should be in the core, if we tackle it = at all in this group, but we should at least discuss it because I = guarantee people will ask for it. callback_push: this would give the AS a URL that it could call directly = to push a response to, instead of having the client poll for it. There = are some interesting implications with HTTP2 and HTTP3 that we could = make use of here, and if this all ever is translated on top of COAP then = there are even more ways to push data. I think this fits with part of = your =E2=80=9Cdecoupled=E2=80=9D flow below. callback_ping: this would be a callback URL that didn=E2=80=99t do the = cryptographic protection, because it would be something the client could = detect was hit but couldn=E2=80=99t get data from it beyond that ping. = We could accomplish this today by making the client nonce optional in = XYZ and defining how it works with and without that, but I=E2=80=99m not = sure I like that amount of subtlety, and the fact that it would fail to = a more insecure method.=20 app2app: this would tell the AS that the client wants to open another = application, and not a webpage. The funny thing is that today on a = mobile platform that=E2=80=99s usually done through an HTTPS URL = that=E2=80=99s captured by the app. There=E2=80=99s a lot of thinking = that needs to happen here, but it=E2=80=99s an area of active interest = outside of this group, and I=E2=80=99ve personally got meetings with = several clients this week alone to discuss this use case and need. There are other protocols and communication methods here that are = possible, especially, as you say, when we start thinking about the = capabilities of smart devices. I think there=E2=80=99s even a way to = bootstrap a self-issued-OP style flow but I haven=E2=80=99t chased down = the details on that enough to be comfortable trying to plot it out, yet. =E2=80=94 Justin > On Jun 10, 2020, at 11:12 PM, Francis Pouatcha = wrote: >=20 > The interact section of the <> = sort of defines the choreographie of the authorization process (flow). I = am missing something like: >=20 > - A redirect flow=20 > here the AS instructs the RC to redirect to RO to the given = interaction URL. Upon completing the RO interaction, the RO will be = redirected back to the callback.uri specified by the RC. SO there is no = callback here. >=20 > - A decoupled flow=20 > is actually not visible. This is, I assume upon receiving the = <>, the AS initiated an interaction = with the RO (-device). Upon completion of the interaction with the RO, = the AS invokes the provided callback.uri to deliver the token = (authorization) used by the RC to proceed with the transaction = request>>. >=20 > - An embedded flow > seems hidden behind the didcom section. With the evolding number smart = devices, the embedded flow shall open room for different types of = synchronous transaction authorization requests in which the RO gives a = verifiable assertion (proof of possession) to the RC for use at the = <> in exchange for the seeked access = token. This assertion can range from a simple password to a = cryptographically signed claim. >=20 > "interact": { > "embedded":[{ > "mode":"encrypted password" > }, > { > "mode":"didcom" > }], > "redirect":[{ > "callback": { > "uri": "https://example.com/rc-front-channel/123456 = ", > "nonce": "VJLO6A4CAYLBXHTR0KRO" > } > }], > "decoupled": [{ > "callback": { > "uri": "https://example.com/rc-back-channel/123456 = ", > "nonce": "VJLO6A4CAYLBXHTR0KRO" > } > }] > } >=20 > Still no idea on how to express the RC flow preferences to the AS. = Maybe the order of entries in the interact sesion > --=20 > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/ = --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_5AA39BB4-1362-4D89-B449-C006DB8E8E01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 XYZ = doesn=E2=80=99t look at interaction in terms of =E2=80=9Cflows=E2=80=9D = but instead in terms of discrete capabilities, and this is a deliberate = move beyond what OAuth 2 allows for. Each member of the interaction = request represents one piece of the whole set of capabilities the client = is able to do. For what=E2=80=99s in there right now:


redirect: this tells the AS that the client can get the = user to an arbitrary URL, determined at runtime by the AS. This URL is = taken as a whole without the client doing anything to it. The client can = do whatever makes the most sense for the client in order to get that = user to the URL. It could redirect them, it could open up a browser, it = could display a scannable code, it could email them a link to click on, = etc. Importantly, this says nothing about how the user = gets back =E2=80=94 more on that in a minute. This could be renamed = =E2=80=9Carbitarily_long_url=E2=80=9D or something more = general.

user_code: this tells the AS that the client can tell the = user about a short user-typable code and direct them to a static URL = that the client should be able to know outside of the protocol. It = doesn=E2=80=99t say anything about how the client gets the user there, = and it doesn=E2=80=99t say anything about how the user gets = back. 

callback: this tells the AS that the client can receive a = response on the given URL when the client is done interacting with the = AS. It says nothing about how the user got there =E2=80=94 they could = have gone to an arbitrary URL via redirect, they could have gone to a = static URL and entered a code, they could have gotten a push = notification to a different application they have installed. What=E2=80=99= s important here is that this allows the client and AS to prevent = certain kinds of attacks, including session fixation, by coupling a = front-channel response with a back-channel response. 

didcomm/didcomm_query: these tell the AS that the client = could speak the DIDCOMM protocol to pass messages around to an agent via = some kind of DID-enhanced communication fabric. The XYZ spec is light on = details here because, to me, these are largely examples of what else = could be done outside of HTTP. If we brought these into the eventual = GNAP specification I would expect them to be in their own = DIDCOMM-focused interaction extension. I really wasn=E2=80=99t trying to = hide the extensibility within the DIDCOMM specs; I would much rather we = be clear about how things work together in our own spec than to punt all = extensibility to external groups and claim success.

But now that you have = the parts, in order to make the =E2=80=98flows=E2=80=9D you have below, = you combine these capabilities and probably invent a few other = interaction methods to add to them. That=E2=80=99s where the = extensibility of this model really comes into play: you don=E2=80=99t = define a comprehensive =E2=80=9Cflow=E2=80=9D with all of the = interaction parts, you define what new parts you need and use them in = combination to solve your use case. This allows you to re-use = well-defined behaviors, and for all behaviors to have pretty narrow = scopes and expectations of use.

There are a few potential future = interaction options that I think deserve some thought at some point = within the group:

webauthn: basically a way for the client to = propose a webauthn challenge/response to the AS. The AS would respond to = the initial request with a challenge to be signed, and the client would = sign it and return it directly after having interacted with the user to = unlock their key store. So really I mean any number of FIDO-style key = stores and devices here.

password: as much as I hate this, = someone=E2=80=99s going to want to have the client prompt for = credentials directly with the user in an interaction mechanism, = equivalent to the resource owner password grant in OAuth 2. I do not = think this should be in the core, if we tackle it at all in this group, = but we should at least discuss it because I guarantee people will ask = for it.

callback_push: this would give the AS a URL that it could = call directly to push a response to, instead of having the client poll = for it. There are some interesting implications with HTTP2 and HTTP3 = that we could make use of here, and if this all ever is translated on = top of COAP then there are even more ways to push data. I think this = fits with part of your =E2=80=9Cdecoupled=E2=80=9D flow below.

callback_ping: this would be a callback URL that didn=E2=80= =99t do the cryptographic protection, because it would be something the = client could detect was hit but couldn=E2=80=99t get data from it beyond = that ping. We could accomplish this today by making the client nonce = optional in XYZ and defining how it works with and without that, but = I=E2=80=99m not sure I like that amount of subtlety, and the fact that = it would fail to a more insecure method. 

app2app: this would = tell the AS that the client wants to open another application, and not a = webpage. The funny thing is that today on a mobile platform that=E2=80=99s= usually done through an HTTPS URL that=E2=80=99s captured by the app. = There=E2=80=99s a lot of thinking that needs to happen here, but it=E2=80=99= s an area of active interest outside of this group, and I=E2=80=99ve = personally got meetings with several clients this week alone to discuss = this use case and need.


There are other = protocols and communication methods here that are possible, especially, = as you say, when we start thinking about the capabilities of smart = devices. I think there=E2=80=99s even a way to bootstrap a = self-issued-OP style flow but I haven=E2=80=99t chased down the details = on that enough to be comfortable trying to plot it out, yet.

 =E2=80=94 = Justin


On Jun = 10, 2020, at 11:12 PM, Francis Pouatcha <fpo=3D40adorsys.de@dmarc.ietf.org> wrote:

The interact section of the = <<draft-richer-transactional-authz-08>> sort of defines the = choreographie of the authorization process (flow). I am missing = something like:

- A = redirect flow 
here the AS instructs the RC to = redirect to RO to the given interaction URL.  Upon completing the RO interaction, = the RO will be redirected back to the callback.uri specified by the RC. SO = there is no callback here.

- A decoupled flow 
is actually not visible. This is, I assume upon = receiving the  <<transaction authorization = request>>, the AS initiated an interaction with the RO = (-device). Upon completion of the interaction with the RO, the AS = invokes the provided callback.uri to deliver the token (authorization) = used by the RC to proceed with  the transaction = request>>.

- An embedded flow
seems hidden behind = the didcom section. With the evolding number smart devices, the embedded = flow shall open room for different types of synchronous transaction = authorization requests in which the RO gives a verifiable assertion = (proof of possession) to the RC for use at the <<transaction = authorization endpoint>> in exchange for the seeked access token. = This assertion can range from a simple password to a cryptographically = signed claim.

"interact": {
  = "embedded":[{
      "mode":"encrypted password"
    },
  =   {
      "mode":"didcom"
  =   }],
   "redirect":[{
      "callback": {
  =       "uri": "https://example.com/rc-front-channel/123456",
        "nonce": = "VJLO6A4CAYLBXHTR0KRO"
      }
    }],
    "decoupled": = [{
      "callback": {
  =       "uri": "https://example.com/rc-back-channel/123456",
        "nonce": = "VJLO6A4CAYLBXHTR0KRO"
      }
    }]
}

Still no idea on how to = express the RC flow preferences to the AS. Maybe the order of entries in = the interact sesion
--
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_5AA39BB4-1362-4D89-B449-C006DB8E8E01-- From nobody Thu Jun 11 12:09:08 2020 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 6C27F3A0061 for ; Thu, 11 Jun 2020 12:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4kmQ1HItnBs for ; Thu, 11 Jun 2020 12:09:04 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D743A005B for ; Thu, 11 Jun 2020 12:09:04 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05BJ92Mj015795; Thu, 11 Jun 2020 15:09:03 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 05BJ92Mj015795 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1591902543; bh=NZz3/GWMuFBvrLH8BoMYZpypRmhtcbNCuvr/qbd2YoY=; h=From:To:Subject:Date:References:In-Reply-To:From; b=ruRutzXc//jb0DhvYGWccMcqfA5bOY3JLXsdH4l951pIYaHvWLh6PWHqXs9EgNC28 IKZgVYBbTHgqxwXvV+eFA7cFulFNcPzsEMXYHvJqNjYFaM6hvTrSbPQ5d0jDzfB8uH r247YCxGIPhGEK1EpngTP7NsgcuqDaLnsWQpENDI= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05BJ8uwb031101; Thu, 11 Jun 2020 15:08:56 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 11 Jun 2020 15:08:55 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 11 Jun 2020 15:08:55 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Thu, 11 Jun 2020 15:08:55 -0400 From: Roman Danyliw To: Yaron Sheffer , "txauth@ietf.org" Thread-Topic: Working group name Thread-Index: AQHWO3jYGwZa6zSxWkuwBFmNTQg2H6jTzofA Date: Thu, 11 Jun 2020 19:08:55 +0000 Message-ID: <780885d9f0304fe3adbe7bd0460e624f@cert.org> References: <2626827D-194C-4BA7-A62C-22387942B571@gmail.com> In-Reply-To: <2626827D-194C-4BA7-A62C-22387942B571@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.211] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Working group name 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, 11 Jun 2020 19:09:06 -0000 SGVsbG8hDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVHhhdXRoIDx0 eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFlhcm9uIFNoZWZmZXINCj4gU2Vu dDogRnJpZGF5LCBKdW5lIDUsIDIwMjAgNDozNSBQTQ0KPiBUbzogdHhhdXRoQGlldGYub3JnDQo+ IFN1YmplY3Q6IFtUeGF1dGhdIFdvcmtpbmcgZ3JvdXAgbmFtZQ0KPiANCj4gVGhhbmsgeW91IHRv IGFsbCB3aG8gcGFydGljaXBhdGVkIGluIHRoZSB0d28gcm91bmRzIG9mIG5hbWUgc2VsZWN0aW9u LiBUaGlzDQo+IHByb2Nlc3MgaGFzIGJlZW4gbG9uZ2VyIHRoYW4gd2UgZXZlciBleHBlY3RlZCwg YW5kIEnigJltIGdsYWQgd2UgY2FuIGRlY2xhcmUNCj4gY29uc2Vuc3VzIG5vdyBhbmQgbW92ZSBm b3J3YXJkLg0KPiANCj4gQmFzZWQgb24gdGhlIGxhc3QgdHdvIHdlZWtz4oCZIHdvcnRoIG9mIGRp c2N1c3Npb24sIHdlIGhhdmUgcm91Z2ggY29uc2Vuc3VzIG9uDQo+IGEgbmFtZSBmb3IgdGhlIHBy b3Bvc2VkIHdvcmtpbmcgZ3JvdXA6DQo+IA0KPiAJR05BUDogR3JhbnQgTmVnb3RpYXRpb24gYW5k IEF1dGhvcml6YXRpb24gUHJvdG9jb2wNCg0KSSdtIHRocmlsbGVkIHdlJ3ZlIGNvbWUgdG8gY29u Y2x1c2lvbiBoZXJlLiAgVGhhbmtzIHRvIGFsbCBpbiB0aGUgY29tbXVuaXR5IHdobyByZXNwb25k ZWQgYW5kIHlvdXIgb3ZlcmFsbCBmbGV4aWJpbGl0eSBpbiBnZXR0aW5nIHRvIGNsb3N1cmUgb24g dGhlIGlzc3VlLg0KDQpJJ3ZlIGNyZWF0ZWQgYSBwbGFjZWhvbGRlciBpbiB0aGUgZGF0YXRyYWNr ZXIgZm9yIGl0IC0tIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvZ25hcC9hYm91dC8u ICBXaGlsZSB0aGUgbmFtZSBvZiB0aGUgcHJvcG9zZWQgV0cgaGFzIGNoYW5nZWQgZnJvbSB0aGUg Qm9GLCB0aGUgbWFpbGluZyBsaXN0IG5hbWUgd2lsbCBzdGF5IHRoZSBzYW1lLCB0eGF1dGhAaWV0 Zi4gIFNob3J0bHksIHRoZXJlIHNob3VsZCBhbHNvIGJlIHBvaW50ZXIgaW4gdGhlIGRhdGF0cmFj a2VyIGZyb20gdGhlIHR4YXV0aCBib2YgdG8gZ25hcCBhcyB3ZWxsLg0KDQo+IFRoaXMgZGVjaXNp b24gd2lsbCBub3cgZW5hYmxlIG91ciBBRCB0byBwdXQgb3VyIGNoYXJ0ZXIgWzFdIG9uIHRoZSBJ RVNHJ3MgdGFibGUsDQo+IHdoZXJlIEkgaG9wZSB3ZSB3aWxsIGJlIGFwcHJvdmVkIGFzIGEgd29y a2luZyBncm91cC4NCg0KSSd2ZSBwdXQgdGhlIGNoYXJ0ZXIgb24gdGhlIG5leHQgSUVTRyB0ZWxl Y2hhdCwgSnVuZSAyNXRoIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2llc2cvYWdlbmRh L2RvY3VtZW50cy8pLg0KDQpBcyBhIHByb2Nlc3MgcmVtaW5kZXIsIGFmdGVyIHRoZSBJRVNHIHBl cmZvcm1zIGFuIGludGVybmFsIHJldmlldyBvZiB0aGlzIGNoYXJ0ZXIsIGl0IHdpbGwgb3V0IGZv ciByZXZpZXcgYnkgdGhlIGNvbW11bml0eSwgYW5kIHRoZW4gYmFjayB0byB0aGUgSUVTRyBmb3Ig ZmluYWwgcmV2aWV3Lg0KDQpSZWdhcmRzLA0KUm9tYW4NCg0KPiBIZWFkcyB1cDogd2UgaW50ZW5k IHRvIG1lZXQgaW4gdGhlIHVwY29taW5nIGFsbC12aXJ0dWFsIElFVEYgMTA4IGluIGxhdGUgSnVs eSwNCj4gZWl0aGVyIGFzIGEgQm9GIG9yIGFzIGEgbmV3bHkgY2hhcnRlcmVkIFdHLg0KPiANCj4g VGhhbmtzLA0KPiAJWWFyb24NCj4gDQo+IA0KPiBbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvY2hhcnRlci1pZXRmLXR4YXV0aC8NCj4gDQo+IA0KPiAtLQ0KPiBUeGF1dGggbWFp bGluZyBsaXN0DQo+IFR4YXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3R4YXV0aA0K From nobody Thu Jun 11 12:44:35 2020 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 83DE03A0859 for ; Thu, 11 Jun 2020 12:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 huiXgiXQho37 for ; Thu, 11 Jun 2020 12:44:32 -0700 (PDT) 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 DF4303A0853 for ; Thu, 11 Jun 2020 12:44:31 -0700 (PDT) Received: from [192.168.1.14] (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 05BJhqbi011612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jun 2020 15:44:27 -0400 From: Justin Richer Message-Id: <498884EB-C4BA-4AE2-B1C0-265FD93A877C@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_44CB65C4-3844-4463-A4D0-582164C41481" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 11 Jun 2020 15:44:27 -0400 In-Reply-To: <780885d9f0304fe3adbe7bd0460e624f@cert.org> Cc: Yaron Sheffer , "txauth@ietf.org" To: "rdd@cert.org" References: <2626827D-194C-4BA7-A62C-22387942B571@gmail.com> <780885d9f0304fe3adbe7bd0460e624f@cert.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Working group name 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, 11 Jun 2020 19:44:35 -0000 --Apple-Mail=_44CB65C4-3844-4463-A4D0-582164C41481 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you very much, Roman! =E2=80=94 Justin > On Jun 11, 2020, at 3:08 PM, Roman Danyliw wrote: >=20 > Hello! >=20 >> -----Original Message----- >> From: Txauth On Behalf Of Yaron Sheffer >> Sent: Friday, June 5, 2020 4:35 PM >> To: txauth@ietf.org >> Subject: [Txauth] Working group name >>=20 >> Thank you to all who participated in the two rounds of name = selection. This >> process has been longer than we ever expected, and I=E2=80=99m glad = we can declare >> consensus now and move forward. >>=20 >> Based on the last two weeks=E2=80=99 worth of discussion, we have = rough consensus on >> a name for the proposed working group: >>=20 >> GNAP: Grant Negotiation and Authorization Protocol >=20 > I'm thrilled we've come to conclusion here. Thanks to all in the = community who responded and your overall flexibility in getting to = closure on the issue. >=20 > I've created a placeholder in the datatracker for it -- = https://datatracker.ietf.org/wg/gnap/about/ = . While the name of the = proposed WG has changed from the BoF, the mailing list name will stay = the same, txauth@ietf. Shortly, there should also be pointer in the = datatracker from the txauth bof to gnap as well. >=20 >> This decision will now enable our AD to put our charter [1] on the = IESG's table, >> where I hope we will be approved as a working group. >=20 > I've put the charter on the next IESG telechat, June 25th = (https://datatracker.ietf.org/iesg/agenda/documents/ = ). >=20 > As a process reminder, after the IESG performs an internal review of = this charter, it will out for review by the community, and then back to = the IESG for final review. >=20 > Regards, > Roman >=20 >> Heads up: we intend to meet in the upcoming all-virtual IETF 108 in = late July, >> either as a BoF or as a newly chartered WG. >>=20 >> Thanks, >> Yaron >>=20 >>=20 >> [1] https://datatracker.ietf.org/doc/charter-ietf-txauth/ >>=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=_44CB65C4-3844-4463-A4D0-582164C41481 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank= you very much, Roman!

 =E2=80=94 Justin

On Jun = 11, 2020, at 3:08 PM, Roman Danyliw <rdd@cert.org> wrote:

Hello!

-----Original Message-----
From: Txauth <txauth-bounces@ietf.org> On Behalf Of Yaron Sheffer
Sent: Friday, June 5, 2020 4:35 PM
To: txauth@ietf.org
Subject: [Txauth] Working group name

Thank you to all who participated in the two rounds of name = selection. This
process has been longer than we ever = expected, and I=E2=80=99m glad we can declare
consensus = now and move forward.

Based on the last two = weeks=E2=80=99 worth of discussion, we have rough consensus on
a name for the proposed working group:

= GNAP: Grant Negotiation and Authorization Protocol

I'm thrilled we've come to conclusion here.  Thanks to = all in the community who responded and your overall flexibility in = getting to closure on the issue.

I've created a placeholder in the datatracker for it -- https://datatracker.ietf.org/wg/gnap/about/.  While the name of the = proposed WG has changed from the BoF, the mailing list name will stay = the same, txauth@ietf.  Shortly, there should also be pointer in = the datatracker from the txauth bof to gnap as well.

This = decision will now enable our AD to put our charter [1] on the IESG's = table,
where I hope we will be approved as a working = group.

I've put the charter on the next IESG telechat, June 25th = (https://datatracker.ietf.org/iesg/agenda/documents/).

As a process reminder, after the IESG performs an internal = review of this charter, it will out for review by the community, and = then back to the IESG for final review.

Regards,
Roman

Heads up: we intend to meet in the = upcoming all-virtual IETF 108 in late July,
either as a = BoF or as a newly chartered WG.

Thanks,
= Yaron


[1] https://datatracker.ietf.org/doc/charter-ietf-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

= --Apple-Mail=_44CB65C4-3844-4463-A4D0-582164C41481-- From nobody Sat Jun 13 21:43:22 2020 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 653C03A0A3D for ; Sat, 13 Jun 2020 21:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 om_wngs56vSR for ; Sat, 13 Jun 2020 21:43:20 -0700 (PDT) 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 59E2D3A0A3C for ; Sat, 13 Jun 2020 21:43:20 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05E4hFsC021088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 14 Jun 2020 00:43:18 -0400 Date: Sat, 13 Jun 2020 21:43:15 -0700 From: Benjamin Kaduk To: txauth@ietf.org Message-ID: <20200614044315.GD11992@kduck.mit.edu> References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 14 Jun 2020 04:43:21 -0000 Hi all, Sorry for jumping in so late (and with so little to say). But, On Mon, Jun 08, 2020 at 11:58:03AM -0700, Dick Hardt wrote: > On Mon, Jun 8, 2020 at 5:29 AM Justin Richer wrote: > > > > > > These are input proposals, everything is up for debate. That’s why we’re > > debating. > > > > Yes, we are debating the pros and cons of each proposal. maybe it's just me, but the phrasing of "debating the pros and cons of each proposal" makes it sound like a fixed evaluation, where we have two inputs, tally the plusses and minuses in each's column, and at the end decide what is "better". I'd much rather describe what we're doing now as exploring what properties we could have in GNAP and considering which of those properties we believe will make for a successful protocol. Hopefully everyone is already doing this, and I will happily apologize for wasting your time to read this message. But I do want to avoid this as a question of "is X or Z a better protocol?", and ensure that we feel that we have the freedom to do the right thing. Thanks, Ben From nobody Sat Jun 13 21:49:49 2020 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 004DF3A0A47 for ; Sat, 13 Jun 2020 21:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 OjsAE80tUSo2 for ; Sat, 13 Jun 2020 21:49:46 -0700 (PDT) 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 77B3C3A0544 for ; Sat, 13 Jun 2020 21:49:46 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05E4nfGU022491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 14 Jun 2020 00:49:43 -0400 Date: Sat, 13 Jun 2020 21:49:40 -0700 From: Benjamin Kaduk To: Justin Richer Cc: Dick Hardt , txauth@ietf.org Message-ID: <20200614044940.GE11992@kduck.mit.edu> References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 14 Jun 2020 04:49:48 -0000 One more point, while I'm catching up on the thread... On Tue, Jun 09, 2020 at 12:10:40PM -0400, Justin Richer wrote: >=20 >=20 > > On Jun 8, 2020, at 5:33 PM, Dick Hardt wrote: > >=20 > > That is not entirely correct. A pre-registered client can still pass it= s key by value, and a dynamic client can still use a (dynamically-acquired)= handle. In all cases, the client is identifying itself by its key. The dif= ference is how the server looks up that key =E2=80=94 it=E2=80=99s either f= rom the handle, or it=E2=80=99s from the key value itself.=20 > >=20 > > I don't understand this.=20 > >=20 > > How is the Client authenticating that it is a specific pre-registered c= lient? >=20 > The client is identified by its key. There is no external client identifi= er. I think you=E2=80=99re confused because you=E2=80=99re still thinking i= n terms of OAuth 2=E2=80=99s client ID based model and I am trying to move = us past that. It took me time to realize that we really can let it go, so h= opefully this is helpful in explaining why. >=20 > When a credential is cryptographically random enough to be unique, it can= be used as its own identifier, particularly when you don=E2=80=99t need to= identify the entity outside of the context that it can present and prove i= ts credential. To stretch a metaphor, passwords don=E2=80=99t always need u= sernames. This is, after all, the driving design pattern behind OAuth acces= s tokens. An access token doesn=E2=80=99t have a =E2=80=9Cusername=E2=80=9D= portion to it, even though it would have been trivial to require the clien= t to send its client ID alongside the access token. Why does that work? Bec= ause our model of what the RS does with the access token is built around it= answering the questions: is this token valid and does it allow what=E2=80= =99s being requested? If the RS needs to know which client was issued the t= oken, it can discover that information without being told separately from t= he token -- perhaps it=E2=80=99s in the token itself or it=E2=80=99s in an = introspection response. And in a lot of cases, the RS doesn=E2=80=99t care = about the client software, it just wants to know if the token=E2=80=99s any= good. Even in constrained tokens such as MTLS, PoP, and DPoP, we aren=E2= =80=99t really authenticating the client at the RS so much as making sure t= he right key is presented alongside the right token.=20 >=20 > XYZ takes that same approach with the client talking to the AS and uses t= he credential (key) to identify the client as well as authenticate and prot= ect the request. We can=E2=80=99t just say =E2=80=9COAuth 2 had client IDs = and people are used to it so it must be good and we have to keep using it= =E2=80=9D. We need to ask WHY OAuth 2 needs client IDs and if that still ma= kes sense. I argue that it doesn=E2=80=99t make sense anymore and we need t= o step back and look at a better model. OAuth 2 needs a client ID because i= t gets passed in the front channel and the client=E2=80=99s credentials can= =E2=80=99t be used there. The access token doesn=E2=80=99t need an equivale= nt because it=E2=80=99s passed in the back channel and can be used directly= =2E Now that the client no longer needs to be identified, but not authentic= ated, through untrusted third parties (such as the browser), we don=E2=80= =99t need to have a separate identifier as part of the protocol. With an in= tent-based protocol, that starts in the back channel, you don=E2=80=99t nee= d a client identifier anymore. Once the AS finds that key, the AS can then = figure out what policies, rights, and restrictions are attached to that key= =2E In many implementations, there=E2=80=99s going to be some kind of =E2= =80=9Cregistered client=E2=80=9D object in a database somewhere that drives= those policies. That=E2=80=99s the classical OAuth model, and it works in = many cases. But in other cases, the key is going to just be a value used to= protect the request chain (and possibly the token itself), and the policy = is going to be built up by other things like a device posture or signature = on the calling software or verified user information. It=E2=80=99s not just= about client authentication, even though it can be used for it. DPoP, PKCE= , and DynReg have shown us the value in dynamic systems, in different ways.= =20 >=20 > On top of that, PAR is showing us that a lot of the constraints that we h= ave in OAuth 2 don=E2=80=99t really apply anymore. For instance, Redirect U= RI restrictions can be relaxed because now you CAN identify and authenticat= e the software sending it, which isn=E2=80=99t true with a front-channel-fi= rst approach. All of the things that are required in OAuth 2 start to becom= e redundant, and it leads to things like requiring that =E2=80=9Cclient_id= =E2=80=9D still always be passed in the front channel even though the infor= mation could be looked up from an internal request_uri reference using PAR = and JAR together. >=20 > That=E2=80=99s why a key handle isn=E2=80=99t exactly the same as a clien= t ID and I did not call it a client ID in the XYZ protocol. It=E2=80=99s a = shortcut to refer to the key material for certain optimized cases, but ulti= mately it=E2=80=99s pointing to a key. This has an interesting and benefici= al side effect =E2=80=94 if you HAVE a client ID as part of your internal d= ata model, it can FUNCTION as a key handle because it=E2=80=99s a unique va= lue the AS can use to look up key information. It=E2=80=99s not =E2=80=9Cau= thenticating the client=E2=80=9D, it=E2=80=99s pointing to a key which in t= urn identifies and authenticates the software making the call. The fact tha= t it=E2=80=99s a =E2=80=9Cclient ID=E2=80=9D is an artifact of the implemen= tation, which in this case has an OAuth 2 legacy to work with.=20 >=20 > If we=E2=80=99re going to move past the constraints of OAuth 2 we need to= stop thinking so strictly in its terms and models. There are better ways t= o approach this now and client IDs are not required by this protocol model. The idea of a client (or other entity) being identified precisely by its public key is very reminiscent of HIP (RFC 7401, 7402) that has a similar stance. (There, it's billed as a security feature, since you are literally guaranteed by the protocol to be talking to the entity you think you are.) One of the difficulties with using HIP, though, is that just the pubkey is not always a terribly useful identifier, and we tend to want to tie into other naming systems (e.g., the DNS in the case of HIP) so that we know that the party we're talking to at the HIP layer is also the person/organization we want to be talking to. In the case of HIP, the need to bind a different type of name to the public key brings back a lot of the issues that using the key as the identifier was supposed to solve (and in my opinion is part of why HIP is not more broadly deployed). I don't see this need for a binding of external name/identity to an XYZ public key as a fatal flaw, though -- the way in which introduction are done combined with the AS's database seems to allow things to work reasonably. I just want to make sure that we're thinking about how the public key will be bound to external identities, and make sure that our story for doing so is sound. Thanks, Ben From nobody Sun Jun 14 10:21:25 2020 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 EA4393A0817 for ; Sun, 14 Jun 2020 10:21:23 -0700 (PDT) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 R_ELkRIUqVmV for ; Sun, 14 Jun 2020 10:21:22 -0700 (PDT) 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 EC7083A07DA for ; Sun, 14 Jun 2020 10:21:21 -0700 (PDT) Received: from [192.168.1.14] (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 05EHLIhP016851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 14 Jun 2020 13:21:19 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Justin Richer In-Reply-To: <20200614044940.GE11992@kduck.mit.edu> Date: Sun, 14 Jun 2020 13:21:18 -0400 Cc: Dick Hardt , txauth@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> <20200614044940.GE11992@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 14 Jun 2020 17:21:24 -0000 Hi, Ben -- > On Jun 14, 2020, at 12:49 AM, Benjamin Kaduk wrote: >=20 > One more point, while I'm catching up on the thread... >=20 > On Tue, Jun 09, 2020 at 12:10:40PM -0400, Justin Richer wrote: >>=20 >>=20 >>> On Jun 8, 2020, at 5:33 PM, Dick Hardt wrote: >>>=20 >>> That is not entirely correct. A pre-registered client can still pass = its key by value, and a dynamic client can still use a = (dynamically-acquired) handle. In all cases, the client is identifying = itself by its key. The difference is how the server looks up that key = =E2=80=94 it=E2=80=99s either from the handle, or it=E2=80=99s from the = key value itself.=20 >>>=20 >>> I don't understand this.=20 >>>=20 >>> How is the Client authenticating that it is a specific = pre-registered client? >>=20 >> The client is identified by its key. There is no external client = identifier. I think you=E2=80=99re confused because you=E2=80=99re still = thinking in terms of OAuth 2=E2=80=99s client ID based model and I am = trying to move us past that. It took me time to realize that we really = can let it go, so hopefully this is helpful in explaining why. >>=20 >> When a credential is cryptographically random enough to be unique, it = can be used as its own identifier, particularly when you don=E2=80=99t = need to identify the entity outside of the context that it can present = and prove its credential. To stretch a metaphor, passwords don=E2=80=99t = always need usernames. This is, after all, the driving design pattern = behind OAuth access tokens. An access token doesn=E2=80=99t have a = =E2=80=9Cusername=E2=80=9D portion to it, even though it would have been = trivial to require the client to send its client ID alongside the access = token. Why does that work? Because our model of what the RS does with = the access token is built around it answering the questions: is this = token valid and does it allow what=E2=80=99s being requested? If the RS = needs to know which client was issued the token, it can discover that = information without being told separately from the token -- perhaps = it=E2=80=99s in the token itself or it=E2=80=99s in an introspection = response. And in a lot of cases, the RS doesn=E2=80=99t care about the = client software, it just wants to know if the token=E2=80=99s any good. = Even in constrained tokens such as MTLS, PoP, and DPoP, we aren=E2=80=99t = really authenticating the client at the RS so much as making sure the = right key is presented alongside the right token.=20 >>=20 >> XYZ takes that same approach with the client talking to the AS and = uses the credential (key) to identify the client as well as authenticate = and protect the request. We can=E2=80=99t just say =E2=80=9COAuth 2 had = client IDs and people are used to it so it must be good and we have to = keep using it=E2=80=9D. We need to ask WHY OAuth 2 needs client IDs and = if that still makes sense. I argue that it doesn=E2=80=99t make sense = anymore and we need to step back and look at a better model. OAuth 2 = needs a client ID because it gets passed in the front channel and the = client=E2=80=99s credentials can=E2=80=99t be used there. The access = token doesn=E2=80=99t need an equivalent because it=E2=80=99s passed in = the back channel and can be used directly. Now that the client no longer = needs to be identified, but not authenticated, through untrusted third = parties (such as the browser), we don=E2=80=99t need to have a separate = identifier as part of the protocol. With an intent-based protocol, that = starts in the back channel, you don=E2=80=99t need a client identifier = anymore. Once the AS finds that key, the AS can then figure out what = policies, rights, and restrictions are attached to that key. In many = implementations, there=E2=80=99s going to be some kind of =E2=80=9Cregiste= red client=E2=80=9D object in a database somewhere that drives those = policies. That=E2=80=99s the classical OAuth model, and it works in many = cases. But in other cases, the key is going to just be a value used to = protect the request chain (and possibly the token itself), and the = policy is going to be built up by other things like a device posture or = signature on the calling software or verified user information. It=E2=80=99= s not just about client authentication, even though it can be used for = it. DPoP, PKCE, and DynReg have shown us the value in dynamic systems, = in different ways.=20 >>=20 >> On top of that, PAR is showing us that a lot of the constraints that = we have in OAuth 2 don=E2=80=99t really apply anymore. For instance, = Redirect URI restrictions can be relaxed because now you CAN identify = and authenticate the software sending it, which isn=E2=80=99t true with = a front-channel-first approach. All of the things that are required in = OAuth 2 start to become redundant, and it leads to things like requiring = that =E2=80=9Cclient_id=E2=80=9D still always be passed in the front = channel even though the information could be looked up from an internal = request_uri reference using PAR and JAR together. >>=20 >> That=E2=80=99s why a key handle isn=E2=80=99t exactly the same as a = client ID and I did not call it a client ID in the XYZ protocol. It=E2=80=99= s a shortcut to refer to the key material for certain optimized cases, = but ultimately it=E2=80=99s pointing to a key. This has an interesting = and beneficial side effect =E2=80=94 if you HAVE a client ID as part of = your internal data model, it can FUNCTION as a key handle because it=E2=80= =99s a unique value the AS can use to look up key information. It=E2=80=99= s not =E2=80=9Cauthenticating the client=E2=80=9D, it=E2=80=99s pointing = to a key which in turn identifies and authenticates the software making = the call. The fact that it=E2=80=99s a =E2=80=9Cclient ID=E2=80=9D is an = artifact of the implementation, which in this case has an OAuth 2 legacy = to work with.=20 >>=20 >> If we=E2=80=99re going to move past the constraints of OAuth 2 we = need to stop thinking so strictly in its terms and models. There are = better ways to approach this now and client IDs are not required by this = protocol model. >=20 > The idea of a client (or other entity) being identified precisely by = its > public key is very reminiscent of HIP (RFC 7401, 7402) that has a = similar > stance. (There, it's billed as a security feature, since you are = literally > guaranteed by the protocol to be talking to the entity you think you = are.) > One of the difficulties with using HIP, though, is that just the = pubkey is > not always a terribly useful identifier, and we tend to want to tie = into > other naming systems (e.g., the DNS in the case of HIP) so that we = know > that the party we're talking to at the HIP layer is also the > person/organization we want to be talking to. In the case of HIP, the = need > to bind a different type of name to the public key brings back a lot = of the > issues that using the key as the identifier was supposed to solve (and = in > my opinion is part of why HIP is not more broadly deployed). I don't = see > this need for a binding of external name/identity to an XYZ public key = as a > fatal flaw, though -- the way in which introduction are done combined = with > the AS's database seems to allow things to work reasonably. I just = want to > make sure that we're thinking about how the public key will be bound = to > external identities, and make sure that our story for doing so is = sound. >=20 Yes, I feel the same way. The idea behind XYZ=E2=80=99s ability to = introduce the key either by value leads to a model where the key is = always what points to the policy of what=E2=80=99s allowed, but the way = that the AS discovers which key it=E2=80=99s supposed to be proving = against is separate. So it goes handle -> key -> client. In OAuth 2, the = model is you identify the client and then figure out what key is = attached to that client. The relationship is inverted as handle -> = client -> key, and that=E2=80=99s where the problems start to come in = for other communities.=20 It=E2=80=99s really important for a lot of use cases that we let clients = have an identifier separate from the key value itself, which is why XYZ = doesn=E2=80=99t define the key handle as the fingerprint of the key, or = the key ID (which could be internal to the JWK), or anything else. All = it means is =E2=80=9Cwhen the AS sees this value, it knows what key or = keys it is referring to=E2=80=9D. And from there, the AS can figure out = the rest of its policy. As you say, this relationship can get set up = with an AS database, or the AS could know how to look up the key in a = DNS store or distributed ledger =E2=80=94 it doesn=E2=80=99t matter, as = long as the AS can find the key. This allows us to also have use cases = where we don=E2=80=99t have a separate identifier that the AS knows = about and we can just send the key as-is, like for ephemeral clients in = SPAs, or mobile applications that would need to be registered in OAuth 2 = in order to get a client ID. And you don=E2=80=99t even need to look = that far from OAuth to find use cases for key-based identity, as = that=E2=80=99s at the core of the self-issued OP functions in OIDC, = which is in the core spec. There, we have the spec saying to use the = redirect URI as the client ID =E2=80=94 even though the client already = is sending the Redirect URI, OAuth 2 (and the associated assumptions and = model of the protocol underneath) need this explicit client ID field for = all use cases.=20 Something that I think is interesting is that we have an opportunity to = potentially define ways to process these kinds of things cross domain, = much the way JWTs and introspection allow for cross-domain access tokens = to be processed. But I think there=E2=80=99s still a lot of discussion = and debate to figure out all the avenues that people care about here. = XYZ=E2=80=99s model is probably not exactly right for every case, but = I=E2=80=99ve already seen the ability to do key by value or by reference = be useful in a lot of places that OAuth 2 doesn=E2=80=99t really work = well. And that=E2=80=99s really where GNAP is going to shine =E2=80=94 in the = gaps that OAuth 2 has left. > Thanks, >=20 > Ben Thanks,=20 =E2=80=94 Justin= From nobody Mon Jun 15 10:22:17 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CC93A0484; Mon, 15 Jun 2020 10:22:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: txauth@ietf.org, rdd@cert.org, gnap-chairs@ietf.org, avezza@amsl.com X-Test-IDTracker: no X-IETF-IDTracker: 7.3.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159224173498.25464.13455604143361674297@ietfa.amsl.com> Date: Mon, 15 Jun 2020 10:22:15 -0700 Archived-At: Subject: [Txauth] gnap - New Meeting Session Request for IETF 108 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 17:22:15 -0000 A new meeting session request has just been submitted by Amy K. Vezza, on behalf of the gnap working group. --------------------------------------------------------- Working Group Name: Grant Negotiation and Authorization Protocol Area Name: Security Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: ace acme cose curdle dots emu i2nsf ipsecme kitten lake lamps mile mls oauth rats sacm secdispatch secevent suit teep tls tokbind trans httpbis quic saag People who must be present: Yaron Sheffer Roman Danyliw Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jun 15 12:18:51 2020 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 097D23A0CC8 for ; Mon, 15 Jun 2020 12:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 j1IsJsJlK-It for ; Mon, 15 Jun 2020 12:18:48 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8615B3A0CC7 for ; Mon, 15 Jun 2020 12:18:47 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id y11so20608546ljm.9 for ; Mon, 15 Jun 2020 12:18:47 -0700 (PDT) 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=m9DxVJIJx2H4KTvXRcFJpDcr4CDNCVzoQFKKOgw5XvQ=; b=rtWA0uFU/ontgapm5p1Dzt1CLHyuz60dHbhw6rQ0qDaHaqA1w2DKyDIy2zJ3vFeM48 6iqVcto3bmF0EHl1RxSaTs/X/M3MQZloqqLhTHx+qNFYWHJ+3Naa+wEvQudu0LPcmr69 YgGvXwa01bN0GOshgmXFvie4gGvN1wxRsALydYTqOmMPTXbfZJK8qjMVhJiBZMFpvvE+ /EjGFAJsrO6aHrlrfKBYhunp06CT/vnA0HyYwP0YKGYOL69C23+KXktI5OhSkXeZ+Z2f zcrMV8iRDrAtNyTxyl0PuJ1oxW5x9RMlf4Bo7t9NReNvkW23aXxiENqJpR1qqzycuFpq vpog== 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=m9DxVJIJx2H4KTvXRcFJpDcr4CDNCVzoQFKKOgw5XvQ=; b=aXetrokGwPKA/uonhkcDtTByBQVjftCZLLGPGzZZbzCG7GLr7K41U+ThUGzhFBLm65 KVI4giXo6gOzr0mo/F+anLLA0/jgb3/mmPZ8HOhv1qUziJMVBx4jfTX5cVo4jtTrCgBS EnsfNqRDYrxh4fgCSADZXrEh0Do440wr14wLPX1tzlYNZxbM1WPzGg87mG4JJPXw5ZYC 5X2eca5U/sEGYfNscUplBLThI3pw20Jwd2XDjlpg3eO+WcddKFto5sXC9G6Gmz3XQYgQ Fjb+Tf/JFFwGaoGJuwYim3xeTaWZ4V/tR4Suv2zC2+u+5bypxf08aq2xJg5JhQBOge6m URdg== X-Gm-Message-State: AOAM531W4huUv9Uut+SDzstaSYYHgleMn0FYshzFweACS0lTMf/pf40b kZ/Ytw2T/qdHGcpTIXiDgmrqH/q8G/qaH1VBjxM= X-Google-Smtp-Source: ABdhPJyiYjLxzVGSBFTtWjJbN9TzVTlyJTCPug1ATNqDAnkylIU/I98YEoBOsjP9HmjX0copkmdOtWbMA2Vi3SarK8M= X-Received: by 2002:a2e:9987:: with SMTP id w7mr12863630lji.215.1592248725565; Mon, 15 Jun 2020 12:18:45 -0700 (PDT) MIME-Version: 1.0 References: <8db677bd-d054-136f-fbad-cae55237f7a8@mozilla.com> In-Reply-To: <8db677bd-d054-136f-fbad-cae55237f7a8@mozilla.com> From: Dick Hardt Date: Mon, 15 Jun 2020 12:18:19 -0700 Message-ID: To: Peter Saint-Andre Cc: Mike Jones , Fabien Imbault , Jared Jennings , Amanjeev Sethi , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ae755e05a8244bd4" Archived-At: Subject: Re: [Txauth] GNAP it is 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, 15 Jun 2020 19:18:50 -0000 --000000000000ae755e05a8244bd4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Checking in again on pronunciation. Mike: do you still have concerns with a silent 'G'? Anyone else have concerns? I'd like to nip pronunciation confusion in the bud by having the recommended pronunciation in the charter. =E1=90=A7 On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre wrote: > Looks like we were caught gnapping. ;-) > > OK, that's the last of my snarky comments, let's get to work! > > Peter > > On 6/7/20 2:09 PM, Dick Hardt wrote: > > It is if you are familiar with any of the GNU projects. > > > > https://www.gnu.org/gnu/pronunciation.en.html > > > > A quick search on the internet has the "normal" pronunciation of "gnu" > > to have a silent 'g'. > > > > https://www.howtopronounce.com/gnu > > https://dictionary.cambridge.org/us/pronunciation/english/gnu > > > > > > =E1=90=A7 > > > > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones > > wrote: > > > > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of GN= U. I > > think that=E2=80=99s the most natural way to read it.____ > > > > __ __ > > > > -- Mike____ > > > > __ __ > > > > *From:* Txauth > > *On Behalf Of *Dick Hardt > > *Sent:* Sunday, June 7, 2020 12:45 PM > > *To:* Amanjeev Sethi > > > *Cc:* Fabien Imbault > >; Jared Jennings > > >; > > txauth@ietf.org > > *Subject:* Re: [Txauth] GNAP it is____ > > > > __ __ > > > > Anyone have objection to the recommended pronunciation being the > > English word "nap", as in "gnaw"?____ > > > > __ __ > > > > If not, then we could add a pronunciation recommendation to the > > Charter.____ > > > > __ __ > > > > =E1=90=A7____ > > > > __ __ > > > > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi > > wrote:____ > > > > Vote for 'G' silent, as in 'lagnappe' ;)____ > > > > __ __ > > > > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____ > > > > I vote for G silent. For the reason it's most common to > > pronounce, especially for those not familiar with open > > source usages.____ > > > > __ __ > > > > On Sat, Jun 6, 2020, 08:45 Dick Hardt > > wrote:____ > > > > The obvious pronunciation choices are:____ > > > > __ __ > > > > nap (silent g as in gnaw)____ > > > > __ __ > > > > guh-nap (as in the GNU OS > > - https://www.gnu.org/gnu/pronunciation.en..html > > )____ > > > > __ __ > > > > gee-nap (as in G-man - government man > > - https://en.wikipedia.org/wiki/G-man)____ > > > > __ __ > > > > __ __ > > > > __ __ > > > > =E1=90=A7____ > > > > __ __ > > > > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault > > > > wrote:____ > > > > So, let's adopt a GNAP! We can even come with a > > little mascot (a bit like go gopher) as imagined > > by http://elisegravel.com/blog/adopte-un-gnap/, > > loved by little Canadians :-) ____ > > > > __ __ > > > > Just to be sure, how do you recommand we pronounce > > it? ____ > > > > __ __ > > > > Looking forward to the next steps too.. ____ > > > > __ __ > > > > Thxs____ > > > > Fabien____ > > > > --____ > > > > 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____ > > > > __ __ > > > > __ __ > > > > > --000000000000ae755e05a8244bd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Checking in again on pronunciation.

Mik= e: do you still have concerns with a silent 'G'?

Anyone else have concerns?

I'd like to = nip pronunciation confusion in the bud by having the recommended pronunciat= ion=C2=A0in the charter.


3D""=E1=90=A7

On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre <stpeter@mozilla.com> wrote:
Looks like we were cau= ght gnapping. ;-)

OK, that's the last of my snarky comments, let's get to work!

Peter

On 6/7/20 2:09 PM, Dick Hardt wrote:
> It is if you are familiar with any of the GNU projects.
>
> https://www.gnu.org/gnu/pronunciation.en.html<= br> >
> A quick search on the internet has the "normal" pronunciatio= n of "gnu"
> to have a silent 'g'.
>
> https://www.howtopronounce.com/gnu
> https://dictionary.cambridge.org/u= s/pronunciation/english/gnu
>
>
> =E1=90=A7
>
> On Sun, Jun 7, 2020 at 12:51 PM Mike Jones <Michael.Jones@microsoft.com > <mailto:Michael.Jones@microsoft.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I had assumed Guh-Nap =E2=80=93 parallel to the pro= nunciation of GNU.=C2=A0 I
>=C2=A0 =C2=A0 =C2=A0think that=E2=80=99s the most natural way to read i= t.____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0*From:* Txauth <txauth-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:txauth-bounces@ietf.org>> *On Behalf Of *Dic= k Hardt
>=C2=A0 =C2=A0 =C2=A0*Sent:* Sunday, June 7, 2020 12:45 PM
>=C2=A0 =C2=A0 =C2=A0*To:* Amanjeev Sethi <aj@amanjeev.com <mailto:aj@amanjeev.com>>
>=C2=A0 =C2=A0 =C2=A0*Cc:* Fabien Imbault <fabien.imbault@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:fabien.imbault@gmail.com>>; Jared Jennings<= br> >=C2=A0 =C2=A0 =C2=A0<jaredljennings@gmail.com <mailto:jaredljennings@gmail.com>&= gt;;
>=C2=A0 =C2=A0 =C2=A0txauth@ietf.org <mailto:txauth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0*Subject:* Re: [Txauth] GNAP it is____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0Anyone have objection to the recommended pronunciat= ion=C2=A0being the
>=C2=A0 =C2=A0 =C2=A0English word "nap", as in "gnaw"= ;?____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0If not, then we could add a pronunciation=C2=A0reco= mmendation to the
>=C2=A0 =C2=A0 =C2=A0Charter.____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0=E1=90=A7____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi <<= a href=3D"mailto:aj@amanjeev.com" target=3D"_blank">aj@amanjeev.com
>=C2=A0 =C2=A0 =C2=A0<mailto:aj@amanjeev.com>> wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vote for 'G' silent, as in &#= 39;lagnappe' ;)____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020, at 10:52 AM, Jar= ed Jennings wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I vote for G silent. Fo= r the reason it's most common to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pronounce, especially f= or those not familiar with open
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0source usages.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020, 08= :45 Dick Hardt <dick.hardt@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dick.hardt@gmail.com>&= gt; wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The obvio= us pronunciation choices are:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nap (sile= nt g as in gnaw)____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0guh-nap (= as in the GNU OS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0https://www.gnu.org/gnu/pronunciation.en..html
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.gnu.org/gnu/pronunciation.en.html>)____ >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gee-nap (= as in G-man - government man
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0https://en.wikipedia.org/wiki/G-man)____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E1=90=A7= ____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, J= un 6, 2020 at 1:34 AM Fabien Imbault
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<fabien.imbault@gma= il.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailt= o:fabien.imba= ult@gmail.com>> wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0So, let's adopt a GNAP! We can even come with a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0little mascot (a bit like go gopher) as imagined
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0by=C2=A0http://elisegravel.com/blog/adopte-un-gna= p/,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0loved by little Canadians :-)=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Just to be sure, how do you recommand we pronounce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0it?=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Looking forward to the next steps too..=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Thxs____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Fabien____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0--____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Txauth mailing list____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Txauth@ietf.org<= /a> <mailto:Txauth@= ietf.org>____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0https://www.ietf.org/mailman/listinfo/txauth__= __
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--____ >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth ma= iling list____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth@ietf.org <mailt= o:Txauth@ietf.org&= gt;____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/txauth____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list____=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth@ietf.org <mailto:Txauth@ietf.org>____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= https://www.ietf.org/mailman/listinfo/txauth____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>
--000000000000ae755e05a8244bd4-- From nobody Mon Jun 15 12:21:47 2020 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 45F2E3A0CE4 for ; Mon, 15 Jun 2020 12:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5AqlhHiELUp for ; Mon, 15 Jun 2020 12:21:45 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0F23A0CE3 for ; Mon, 15 Jun 2020 12:21:45 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05FJLibT029805 for ; Mon, 15 Jun 2020 15:21:44 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 05FJLibT029805 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1592248904; bh=jir7MWCnv2Aq5vop/jsQLHTgWHkaxVMI34IARAGk8Pk=; h=From:To:Subject:Date:From; b=DZ89k/I5ivVIcM/pBMv8TiVg/Lz5M5IzeqqYpVPmf+Wi+0CErXd5/V5TX+95eovoG uja0TJP7yVuiRrkAutzvxta+3hLYpdz4f/yvpvl+FM2rvwJgqD+X/+mlWWx8DDgXeI FDHOJ2q7EAJQOsrXGRR2lvtP6efT9uDAVhe4RLDY= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05FJLdmp014493 for ; Mon, 15 Jun 2020 15:21:39 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 15 Jun 2020 15:21:39 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 15 Jun 2020 15:21:38 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Mon, 15 Jun 2020 15:21:38 -0400 From: Roman Danyliw To: "txauth@ietf.org" Thread-Topic: WG chair changes -- thank you Dick, welcome Leif Thread-Index: AdZDR4A9QISPCpdoTFefrzsgGZotSQ== Date: Mon, 15 Jun 2020 19:21:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Txauth] WG chair changes -- thank you Dick, welcome Leif 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, 15 Jun 2020 19:21:46 -0000 Hi! With the GNAP charter now in IESG review (scheduled for the June 25 telecha= t), we enter a difference phase of work. At this natural transition, the c= hairs of GNAP will also change. =20 Yaron has graciously agreed to continue on as co-chair. Thank you! Dick will step down to focus his attention on the GNAP specifications. (Wi= th Yaron), Dick led us through multiple BoFs, charter refinements and key s= coping activities that allowed us to get to this point -- from mailing list= to BoF to "almost a WG". Please join me in thanking Dick for his leadersh= ip. Luckily for all of us, despite this change, he will still be quite inv= olved in the work. =20 Finally, I am pleased to announce that Leif Johansson will be stepping in a= s the new co-chair. Leif brings both domain and prior WG leadership experi= ence. Please join me in welcoming Leif to this role. Regards, Roman From nobody Mon Jun 15 12:25:19 2020 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 EEA983A08FC for ; Mon, 15 Jun 2020 12:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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=auth0.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 nZapeLS9VhBv for ; Mon, 15 Jun 2020 12:25:11 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 1E0C63A08FE for ; Mon, 15 Jun 2020 12:25:11 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id k1so7098425pls.2 for ; Mon, 15 Jun 2020 12:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=pjST/JMWGIwyNQeNOe2DtXQo5ZTN40q0K7mlveF44hY=; b=WuKdhT+AGErumr6OtdncgW+emIaTuSKw6DX8zYIdrHMO2bqMyrHYBN94B2YpuOOxrT 38wQeQ9z/Gp9krexpz1k0k4ndM+pfF35QOE1X8X3Zd/9WFqHEkQ9XR+8fwfcX+BydQvI gRWBqRS+uIqj+VJu/omhnCpdsjZMKCYH2xFqTIfIwkiQd/ekIOEHZRdInYg3viDtWBtg z6YW+EfIZI2jXKLDvJDni2HJHMqTyRXt6p9NavcAHTwIl2cqgqloP40xrDNNnsMR9KTb C9e89meNRX5EB7EvrOe76YpoytI3Bjxpv8tTibDv3cbK+Vs1/JmlyYs89taJraGvI/kv 9yiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=pjST/JMWGIwyNQeNOe2DtXQo5ZTN40q0K7mlveF44hY=; b=oc7Vrgw+z2uQsIAO0mzP5Cjm6X1wvHRXwqFAGdJu/NWiKMgLsPJGXxj8lnBrQTjEWT zbH+b/LERz9juWPn0iaDHTgzRHNoYsNE3Ri2uCXz6F7g/KeueZzFUE3ePrh3PAFdEL8B wAaSjAjtqi/4TTOoo2syYwNpk6QD20TLi43pq9w6T9ddIBjUry5qu5N7iuTsN2qMqrIe eMvKJ41WF6md+PVV3Bnvg1PT0Kz1ILyk+F9ACDRLeIqbL7LP9R0Etp+MmHg1a2bv9UVU HrcvalbLnC4OcSri6KxeYd9e7jykk4sNyYhmKV7S6H0b6bmX8YN9CNMOX5MGVBz2D+4i DA5g== X-Gm-Message-State: AOAM532nuKXbLfu4CyzJ439WL0ouRMCS5ohS3Q/tJLhg/W1zPCH7d9yH qmkvKHVx4m3kM1gWLXHJhF16Aw== X-Google-Smtp-Source: ABdhPJy4Eo80F2uYiGodhRfLtt+pRkIGQkjPzZWHkXjwkiqiqePhVz061uXQPymDtVBJSVLRwkikLQ== X-Received: by 2002:a17:902:9b92:: with SMTP id y18mr22094976plp.228.1592249110283; Mon, 15 Jun 2020 12:25:10 -0700 (PDT) Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id 204sm7439680pfx.119.2020.06.15.12.25.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2020 12:25:09 -0700 (PDT) From: To: "'Dick Hardt'" , "'Peter Saint-Andre'" Cc: "'Mike Jones'" , "'Jared Jennings'" , "'Amanjeev Sethi'" , "'Fabien Imbault'" , References: <8db677bd-d054-136f-fbad-cae55237f7a8@mozilla.com> In-Reply-To: Date: Mon, 15 Jun 2020 12:25:09 -0700 Message-ID: <019d01d6434a$af721ae0$0e5650a0$@auth0.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_019E_01D64310.031824E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHRqLJh3SW9f2voLCs8znBjvrrmZAKH+EQqAghBX58CTmjNiqisTfpQ Content-Language: en-us Archived-At: Subject: Re: [Txauth] GNAP it is 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, 15 Jun 2020 19:25:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_019E_01D64310.031824E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Perhaps not to be taken too seriously, but here=E2=80=99s prior art on = GNAP pronunciation. As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the = Smurfs comic and was reprised in a cartoon episode as well.=20 You=E2=80=99ll find few examples around 3:30 https://www.youtube.com/watch?v=3DGEl8IBv98vg = = &feature=3Dyoutu.be&fbclid=3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqM= O8A_qzCS-WBJgPbpQ =20 From: Txauth On Behalf Of Dick Hardt Sent: Monday, June 15, 2020 12:18 PM To: Peter Saint-Andre Cc: Mike Jones ; Jared Jennings = ; Amanjeev Sethi ; Fabien = Imbault ; txauth@ietf.org Subject: Re: [Txauth] GNAP it is =20 Checking in again on pronunciation. =20 Mike: do you still have concerns with a silent 'G'? =20 Anyone else have concerns? =20 I'd like to nip pronunciation confusion in the bud by having the = recommended pronunciation in the charter. =20 =20 = = =E1=90=A7 =20 On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre > wrote: Looks like we were caught gnapping. ;-) OK, that's the last of my snarky comments, let's get to work! Peter On 6/7/20 2:09 PM, Dick Hardt wrote: > It is if you are familiar with any of the GNU projects. >=20 > https://www.gnu.org/gnu/pronunciation.en.html >=20 > A quick search on the internet has the "normal" pronunciation of "gnu" > to have a silent 'g'. >=20 > https://www.howtopronounce.com/gnu > https://dictionary.cambridge.org/us/pronunciation/english/gnu >=20 >=20 > =E1=90=A7 >=20 > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones = =20 > >> wrote: >=20 > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of = GNU. I > think that=E2=80=99s the most natural way to read it.____ >=20 > __ __ >=20 > -- Mike____ >=20 > __ __ >=20 > *From:* Txauth =20 > = >> *On Behalf Of *Dick Hardt > *Sent:* Sunday, June 7, 2020 12:45 PM > *To:* Amanjeev Sethi = >> > *Cc:* Fabien Imbault =20 > = >>; Jared Jennings > = >>; > txauth@ietf.org > > *Subject:* Re: [Txauth] GNAP it is____ >=20 > __ __ >=20 > Anyone have objection to the recommended pronunciation being the > English word "nap", as in "gnaw"?____ >=20 > __ __ >=20 > If not, then we could add a pronunciation recommendation to the > Charter.____ >=20 > __ __ >=20 > =E1=90=A7____ >=20 > __ __ >=20 > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi =20 > >> wrote:____ >=20 > Vote for 'G' silent, as in 'lagnappe' ;)____ >=20 > __ __ >=20 > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____ >=20 > I vote for G silent. For the reason it's most common to > pronounce, especially for those not familiar with open > source usages.____ >=20 > __ __ >=20 > On Sat, Jun 6, 2020, 08:45 Dick Hardt = =20 > = >> wrote:____ >=20 > The obvious pronunciation choices are:____ >=20 > __ __ >=20 > nap (silent g as in gnaw)____ >=20 > __ __ >=20 > guh-nap (as in the GNU OS > - https://www.gnu.org/gnu/pronunciation.en..html > )____ >=20 > __ __ >=20 > gee-nap (as in G-man - government man > - https://en.wikipedia.org/wiki/G-man)____ >=20 > __ __ >=20 > __ __ >=20 > __ __ >=20 > =E1=90=A7____ >=20 > __ __ >=20 > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault > =20 > >> wrote:____ >=20 > So, let's adopt a GNAP! We can even come with a > little mascot (a bit like go gopher) as imagined > by http://elisegravel.com/blog/adopte-un-gnap/, > loved by little Canadians :-) ____ >=20 > __ __ >=20 > Just to be sure, how do you recommand we pronounce > it? ____ >=20 > __ __ >=20 > Looking forward to the next steps too.. ____ >=20 > __ __ >=20 > Thxs____ >=20 > Fabien____ >=20 > --____ >=20 > Txauth mailing list____ >=20 > Txauth@ietf.org = >____ >=20 > https://www.ietf.org/mailman/listinfo/txauth____ >=20 > --____ >=20 > Txauth mailing list____ >=20 > Txauth@ietf.org = >____ >=20 > https://www.ietf.org/mailman/listinfo/txauth____ >=20 > -- ____ >=20 > Txauth mailing list____ >=20 > Txauth@ietf.org = >____ >=20 > https://www.ietf.org/mailman/listinfo/txauth____ >=20 > __ __ >=20 > __ __ >=20 >=20 ------=_NextPart_000_019E_01D64310.031824E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Perhaps = not to be taken too seriously, but here=E2=80=99s prior art on GNAP = pronunciation.

As Leif mentioned few = mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the Smurfs comic and was = reprised in a cartoon episode as well.

You=E2=80=99ll find few examples around = 3:30

=C2=A0https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.= be&fbclid=3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJg= PbpQ

 

From: Txauth = <txauth-bounces@ietf.org> On Behalf Of Dick = Hardt
Sent: Monday, June 15, 2020 12:18 PM
To: Peter = Saint-Andre <stpeter@mozilla.com>
Cc: Mike Jones = <Michael.Jones@microsoft.com>; Jared Jennings = <jaredljennings@gmail.com>; Amanjeev Sethi = <aj@amanjeev.com>; Fabien Imbault = <fabien.imbault@gmail.com>; txauth@ietf.org
Subject: Re: = [Txauth] GNAP it is

 

Checking in again on = pronunciation.

 

Mike: do you still have concerns with a silent = 'G'?

 

Anyone else have concerns?

 

I'd like to nip pronunciation confusion in the bud by = having the recommended pronunciation in the = charter.

 

 

=E1= =90=A7

 

On = Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre <stpeter@mozilla.com> = wrote:

Looks = like we were caught gnapping. ;-)

OK, that's the last of my = snarky comments, let's get to work!

Peter

On 6/7/20 2:09 = PM, Dick Hardt wrote:
> It is if you are familiar with any of the = GNU projects.
>
> https://www.gnu.org/gnu/pronunciation.en.html
&g= t;
> A quick search on the internet has the "normal" = pronunciation of "gnu"
> to have a silent 'g'.
> =
> https://www.howtopronounce.com/gnu
> https://dictionary.cambridge.org/us/pronunciation/engli= sh/gnu
>
>
> =E1=90=A7
> =
> On Sun, Jun 7, 2020 at 12:51 PM Mike Jones <Michael.Jones@microsoft.com
> <mailto:Michael.Jones@microsoft.com>> wrote:
> =
>     I had assumed Guh-Nap =E2=80=93 parallel to = the pronunciation of GNU.  I
>     think = that=E2=80=99s the most natural way to read it.____
> =
>     __ __
>
>    =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;       -- Mike____
> =
>     __ __
>
>    =  *From:* Txauth <txauth-bounces@ietf.org
>    =  <mailto:txauth-bounces@ietf.org>> *On Behalf Of = *Dick Hardt
>     *Sent:* Sunday, June 7, 2020 = 12:45 PM
>     *To:* Amanjeev Sethi <aj@amanjeev.com = <mailto:aj@amanjeev.com>>
>    =  *Cc:* Fabien Imbault <fabien.imbault@gmail.com
>    =  <mailto:fabien.imbault@gmail.com>>; Jared = Jennings
>     <jaredljennings@gmail.com <mailto:jaredljennings@gmail.com>>;
>  =    txauth@ietf.org <mailto:txauth@ietf.org>
>    =  *Subject:* Re: [Txauth] GNAP it is____
>
>  =    __ __
>
>     Anyone have = objection to the recommended pronunciation being the
>  =    English word "nap", as in = "gnaw"?____
>
>    =  __ __
>
>     If not, then we = could add a pronunciation recommendation to the
>  =    Charter.____
>
>    =  __ __
>
>     =E1=90=A7____
> =
>     __ __
>
>    =  On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi <aj@amanjeev.com
>    =  <mailto:aj@amanjeev.com>> wrote:____
> =
>         Vote for 'G' silent, as in = 'lagnappe' ;)____
>
>        =  __ __
>
>         On = Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____
> =
>             I vote for G = silent. For the reason it's most common to
>      =        pronounce, especially for those not familiar = with open
>             source = usages.____
>
>            =  __ __
>
>          =    On Sat, Jun 6, 2020, 08:45 Dick Hardt <dick.hardt@gmail.com
>      =        <mailto:dick.hardt@gmail.com>> wrote:____
> =
>                =  The obvious pronunciation choices are:____
>
>  =               =  __ __
>
>          =        nap (silent g as in gnaw)____
> =
>                =  __ __
>
>          =        guh-nap (as in the GNU OS
>  =                - https://www.gnu.org/gnu/pronunciation.en..html
&= gt;                 <https://www.gnu.org/gnu/pronunciation.en.html>)_= ___
>
>              =    __ __
>
>        =          gee-nap (as in G-man - government = man
>                =  - https://en.wikipedia.org/wiki/G-man)____
> =
>                =  __ __
>
>          =        __ __
>
>    =              __ __
> =
>                =  =E1=90=A7____
> =
>                =  __ __
>
>          =        On Sat, Jun 6, 2020 at 1:34 AM Fabien = Imbault
>                =  <fabien.imbault@gmail.com
>    =              <mailto:fabien.imbault@gmail.com>> = wrote:____
>
>            =          So, let's adopt a GNAP! We can even = come with a
>              =        little mascot (a bit like go gopher) as = imagined
>                =      by http://elisegravel.com/blog/adopte-un-gnap/,
>= ;                    =  loved by little Canadians :-) ____
>
>  =                   =  __ __
>
>          =            Just to be sure, how do you = recommand we pronounce
>            =          it? ____
>
>  =                   =  __ __
>
>          =            Looking forward to the next = steps too.. ____
>
>          =            __ __
> =
>                  =    Thxs____
>
>          =            Fabien____
> =
>                  =    --____
>
>          =            Txauth mailing list____
> =
>                  =    Txauth@ietf.org <mailto:Txauth@ietf.org>____
>
>  =                    https://www.ietf.org/mailman/listinfo/txauth____>
>                =  --____
>
>            =      Txauth mailing list____
>
>  =                Txauth@ietf.org = <mailto:Txauth@ietf.org>____
>
>  =                https://www.ietf.org/mailman/listinfo/txauth____>
>            =  -- ____
>
>          =    Txauth mailing list____
>
>    =          Txauth@ietf.org <mailto:Txauth@ietf.org>____
>
>  =            https://www.ietf.org/mailman/listinfo/txauth____>
>            =  __ __
>
>        =  __ __
>
> =

------=_NextPart_000_019E_01D64310.031824E0-- From nobody Mon Jun 15 12:25:27 2020 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 1F3B23A0D1A for ; Mon, 15 Jun 2020 12:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, 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 BcR1ylnFbAi3 for ; Mon, 15 Jun 2020 12:25:19 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 366403A0D36 for ; Mon, 15 Jun 2020 12:25:19 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id g10so671028wmh.4 for ; Mon, 15 Jun 2020 12:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=XehgXnB2y3Sh35L3So8hcxwUE0GoztAqGsMPIAp8r8c=; b=ZIEKEUdIIj6+TFH6gI8/8xt2P6HHSJhOyvl2NE08eSzzzm2GfaUM+yAygn2U9jbY0o EDwA8j3d6o+k8UH5axEvpcbIFVJtvtDLM6yrxR6MSs9WY4rIo+g+5shkjVpBGMxIpe59 pu+fAYU9nm+jvvjRQoWrDpIkG0DoegHJdiiGPh+afRzh4LXwW90VoE8Mtvz0UUiWq2Xa mT0OCiOhv/46pAHtMvZlYtmXrE9OKHVZhv4r8ouGW513x3jBjEqHp7ZsndAeoeNXRh0t 6g1o2w4jEiRW1um05cP+c8EtveNPWL6132KY5CMHFm2ro/+imTAvQ3jWVX9gJ13V+kKl K4+g== 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:message-id :thread-topic:mime-version:content-transfer-encoding; bh=XehgXnB2y3Sh35L3So8hcxwUE0GoztAqGsMPIAp8r8c=; b=jvR/2Jwy+5gHJrXNte12YsjuakFadHb7XcPD2AB7Dlyu1TuXN+Hgk+KBMCeGRzZmh0 xOStdEaAmckJMN/tf8kwyEfyBbq02I4jURyhN881t0gAyHZrvvvfu5CKTgCsBnFlN8sm pZDFOo/FAQca/KrDC1r5yrs6G3Fb8R+X1J1ZTD/eE+PCgqAsN2Z/jhiSLCJsktCSW8Ps 0k1GkFpuZsf0GrcGRsRsWLjacJIUgFHRhwWDiZtxlwSPYizuHQEqEgSOgF4XdJ3TBppc 28uEO58TzQMuHKwGw5/CDSC5CQUIs+CSE8Uu0PBY04fYtr/cT006CV4s+uhLEUGbbHcd RA2A== X-Gm-Message-State: AOAM533b9JmUIwnropLsD9U8JJsBiJWivTXgRmOa2de0iftlRJr4tPOh 874o7tnp9SHQvQfmXdTj6AU= X-Google-Smtp-Source: ABdhPJwe5Xul4E6YyssTCF8fhjWJMiYBJ9YKDLkV3ZWFzCRqFx+TwYikLR1/b4ZX4Id03eiqpddYuw== X-Received: by 2002:a7b:c3c6:: with SMTP id t6mr780648wmj.159.1592249117628; Mon, 15 Jun 2020 12:25:17 -0700 (PDT) Received: from [10.0.0.140] (bzq-79-176-11-75.red.bezeqint.net. [79.176.11.75]) by smtp.gmail.com with ESMTPSA id q13sm26059348wrn.84.2020.06.15.12.25.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jun 2020 12:25:16 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.37.20051002 Date: Mon, 15 Jun 2020 22:25:15 +0300 From: Yaron Sheffer To: Roman Danyliw , "txauth@ietf.org" Message-ID: Thread-Topic: [Txauth] WG chair changes -- thank you Dick, welcome Leif Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Txauth] WG chair changes -- thank you Dick, welcome Leif 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, 15 Jun 2020 19:25:26 -0000 Thank you very much Dick for our (second) partnership, and welcome Leif! Yaron =EF=BB=BFOn 6/15/20, 22:21, "Txauth on behalf of Roman Danyliw" wrote: Hi! With the GNAP charter now in IESG review (scheduled for the June 25 tel= echat), we enter a difference phase of work. At this natural transition, th= e chairs of GNAP will also change. =20 Yaron has graciously agreed to continue on as co-chair. Thank you! Dick will step down to focus his attention on the GNAP specifications. = (With Yaron), Dick led us through multiple BoFs, charter refinements and ke= y scoping activities that allowed us to get to this point -- from mailing li= st to BoF to "almost a WG". Please join me in thanking Dick for his leaders= hip. Luckily for all of us, despite this change, he will still be quite inv= olved in the work. =20 Finally, I am pleased to announce that Leif Johansson will be stepping = in as the new co-chair. Leif brings both domain and prior WG leadership exp= erience. Please join me in welcoming Leif to this role. Regards, Roman --=20 Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth From nobody Mon Jun 15 12:38:37 2020 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 53BFB3A0D0C for ; Mon, 15 Jun 2020 12:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu76scVokhPU for ; Mon, 15 Jun 2020 12:38:33 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650120.outbound.protection.outlook.com [40.107.65.120]) (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 D24A33A0D0A for ; Mon, 15 Jun 2020 12:38:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iWQiaHJPD5u2tNuj9wi9NhFICyoVhteeCvMfmTlPH43XOZ8f6hIVWmruku870TikmA4GfE7iMZo0lilj3Kj2F+taWbpj/xurHu2TZOXeOyyc1BmZFAe3l/eEybXlr1jgrKWBV7PIa5/wuvsYDOWu7HlB/ZeIXio5QXj0F1sT+tyY4COJhMycKrD1FvsgJxxTlahw/r8HnrKMqk569wnJf5dtBeVtCCmCzkd2mOA3sOQ6sDZmj2lAS8HwxMTgk1msK2TWoDJCtD4pZFCssBgIdk88NveAJVm5hxiUEf+C9OocvVooqyDWID6vMk2k++TuCq/NOAnyCUchl6JDvj3Uvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mrOgg3bgQ9btTpcHl8gx5icual8kkvJdpeAqaSOF93w=; b=CVaYhA5sTF3OEjDvpmDOjJ4Ys7mEl3Rj2xTTCNcTTi2pobc0mZK1Rarm4HhvAIoRqV4nZl9jklAUUPdo+2hZgzlOvrQhnzObfYPI74AJKk0a5zRAzSu30Oj0e1SGMjtFAi9CZmh8SDTG/fvWqSNqZEKqkJxaSUaF51EFuQiYFO//+k0wZTx2yu3pgy8wsIue08w1NcoH9ouKGc64Dz99NdzTUuwvzIm+3X7hiFssiw53AHKSqLdQ8qWz3BClJ+DLCE2HF9Lh2X5lqvr8mZDtXygP8mq6PVTWdpwmvXIJV/x4h0DA37a/iyCFpXqUfEDIuCONsODJ80EazmKqEuYJPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mrOgg3bgQ9btTpcHl8gx5icual8kkvJdpeAqaSOF93w=; b=QosQ8stFHgq7vVqNMN7tt8B2Df4mgi3qpRsq4WQps/cAOY6UC4t9Zhi/srme/aakJapF4Ou3epFTk35kFpJQ8NVm49+ieoTvFR9IWLjzGPcwoKx97gABHB4QOu8j2FODaaBFkm/nQePo5RkPIDrrprUu0Lp5nqPE4FTK+wjO1Z4= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by BL0PR00MB0354.namprd00.prod.outlook.com (2603:10b6:207:1f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3144.0; Mon, 15 Jun 2020 19:38:30 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::b4e8:a29d:bbae:4d02]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::b4e8:a29d:bbae:4d02%9]) with mapi id 15.20.3144.000; Mon, 15 Jun 2020 19:38:30 +0000 From: Mike Jones To: "vittorio.bertocci@auth0.com" , 'Dick Hardt' , 'Peter Saint-Andre' CC: 'Jared Jennings' , 'Amanjeev Sethi' , 'Fabien Imbault' , "txauth@ietf.org" Thread-Topic: [Txauth] GNAP it is Thread-Index: AdZDTIo4wtNyMR30Q6+0pLO6pQv9dw== Date: Mon, 15 Jun 2020 19:38:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=9ec4fc49-0bd0-46e4-b19b-0fac87e6644b; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-15T19:35:48Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: auth0.com; dkim=none (message not signed) header.d=none;auth0.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 222c89bb-ccc3-40f1-a678-08d81163ae8f x-ms-traffictypediagnostic: BL0PR00MB0354: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: N9bCiuSYy+t/0dT9uFCUvsD+rYarPShj9E3zgOzQQxuqAqcMkwiyD/M3+UBwvJ8qswWO03LIXK4uD5CLr/xU0ygSwM82sRRaQDBIKn2/aFMdmyVf/i6dM6eY6WpkP7jBxBNfYEq8Yk34oWIV72sK7TkL6w9rT7/ka9X88T7Yp69+yQ2HBi4U5lVs6ShY/5+FO6jzNUpajDHCvlFBSx9l9PltROqDw+7pSUZHxw7wv23zrjsR1LYa3p65WzqSzh8tjLuAz1BMgMaTNsT6MnoJBogSSJmfVeSCQYlynFGPKHD8DYkZsVg3WL6Gm4Oml0Gum/Tg33sWB1HvfvPT6EIrb2rKG4WDvidMInIx6nPeNKNFdG2GPMurASfy49KKNOOO7RPvupIcyG2wZxSSop106gkoMWtbZ27vrbXqDaU2yeqtYYMTq772jL0wweijZthr3h0XSX5vp1KiRXki8F69wA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(346002)(366004)(39860400002)(136003)(6506007)(53546011)(186003)(71200400001)(26005)(21615005)(76236002)(966005)(82960400001)(316002)(82950400001)(86362001)(110136005)(54906003)(10290500003)(166002)(478600001)(66574014)(7696005)(8990500004)(4326008)(8676002)(2906002)(9686003)(76116006)(66946007)(5660300002)(33656002)(8936002)(66476007)(55016002)(52536014)(66556008)(64756008)(66446008)(99710200001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: YfTW0rxt6Bra56f4bDGVM4701KTdDa5iPv0jNguaF3EbDbGyRzI1R3Jguu+JIH8ErkradLfk6Yc0Sazs+/Ho00MF+iBnTaq3EQ9J+eGmOcphzLvFjLqCRVJRfYwdNXvWZr2W6KyRiedGQAKjTx2KC/YwSiroyyAXO+M4qcSqylanBrinhb7wRP3YYsxJm3if2nSt3tjFCPZQaS21/XCaSwA5AWjD3swOYwH3SiBFc7pS9doA/xjyPIe0lv/4t/F0pSWBw3RoO5zR6XEOZUMrPaVG4EzmB7GmvLUQkWRdb4qA3qP/feNksn2IUMi/SDCq784vhgqnj9dw8612pDwLBH57C3hhAHNH7u9PO9FQN0v6c/xwijWs3QgTF0TbV5kUpyEZsaMI6gMpfW5N69lqvtZM+/bggzzS8L4u+rdt0OCA8iEy1+gXwfVVeaBdcvP79D+fZxAgdqoHnDqBY6udEumcu/yuhVCyu9wUvSQCTV8= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0688D7AA407E0D8C31A1453DF59C0MN2PR00MB0688namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 222c89bb-ccc3-40f1-a678-08d81163ae8f X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 19:38:29.9516 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XAmUmX5VjQBJiEvWHiaMUbiKPYigytd5PMrYoy/08zxNdjFzBzKj/Snb8WcP4H5cfufyHNKxDvtThIK1CI2jvA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0354 Archived-At: Subject: Re: [Txauth] GNAP it is 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, 15 Jun 2020 19:38:35 -0000 --_000_MN2PR00MB0688D7AA407E0D8C31A1453DF59C0MN2PR00MB0688namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IGNhcmUgYSBsb3Qgb25lIHdheSBvciB0aGUgb3RoZXIuICBNeSBtYWluIHBvaW50 IGlzIHRoYXQgbm8gbWF0dGVyIHdoYXQgZ3VpZGFuY2Ugd2UgZ2l2ZSwgbWFueSBwZW9wbGUgYXJl IGxpa2VseSB0byBwcm9ub3VuY2UgdGhlIOKAnEfigJ0uICBJZiB3ZSB0cnkgdG8gaW5zaXN0IG9u IGl0IGJlaW5nIHNpbGVudCwgd2Ugc2hvdWxkIGdldCB1c2VkIHRvIHRoZSBmYWN0IHRoYXQgd2Xi gJlsbCBwcm9iYWJseSBiZSBoZWFyaW5nIGJvdGggcHJvbnVuY2lhdGlvbnMuDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN ClAuUy4gIFRoYW5rcyBmb3IgdGhlIFNtdXJmcyBsaW5rLCBWaXR0b3JpbyENCg0KRnJvbTogdml0 dG9yaW8uYmVydG9jY2lAYXV0aDAuY29tIDx2aXR0b3Jpby5iZXJ0b2NjaUBhdXRoMC5jb20+DQpT ZW50OiBNb25kYXksIEp1bmUgMTUsIDIwMjAgMTI6MjUgUE0NClRvOiAnRGljayBIYXJkdCcgPGRp Y2suaGFyZHRAZ21haWwuY29tPjsgJ1BldGVyIFNhaW50LUFuZHJlJyA8c3RwZXRlckBtb3ppbGxh LmNvbT4NCkNjOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyAnSmFy ZWQgSmVubmluZ3MnIDxqYXJlZGxqZW5uaW5nc0BnbWFpbC5jb20+OyAnQW1hbmplZXYgU2V0aGkn IDxhakBhbWFuamVldi5jb20+OyAnRmFiaWVuIEltYmF1bHQnIDxmYWJpZW4uaW1iYXVsdEBnbWFp bC5jb20+OyB0eGF1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbVHhhdXRoXSBHTkFQIGl0IGlz DQoNClBlcmhhcHMgbm90IHRvIGJlIHRha2VuIHRvbyBzZXJpb3VzbHksIGJ1dCBoZXJl4oCZcyBw cmlvciBhcnQgb24gR05BUCBwcm9udW5jaWF0aW9uLg0KQXMgTGVpZiBtZW50aW9uZWQgZmV3IG1h aWxzIGFnbywg4oCcR05BUOKAnSBhcHBlYXJlZCBvbiB0aGUgU211cmZzIGNvbWljIGFuZCB3YXMg cmVwcmlzZWQgaW4gYSBjYXJ0b29uIGVwaXNvZGUgYXMgd2VsbC4NCllvdeKAmWxsIGZpbmQgZmV3 IGV4YW1wbGVzIGFyb3VuZCAzOjMwDQogaHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1H RWw4SUJ2OTh2ZyZmZWF0dXJlPXlvdXR1LmJlJmZiY2xpZD1Jd0FSMEdWZkZlTmw0TTFPaEhLRTdG ZnlDcUtUREpJOTYwbVUtYWk4aExxTU84QV9xekNTLVdCSmdQYnBRDQoNCkZyb206IFR4YXV0aCA8 dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnPj4g T24gQmVoYWxmIE9mIERpY2sgSGFyZHQNClNlbnQ6IE1vbmRheSwgSnVuZSAxNSwgMjAyMCAxMjox OCBQTQ0KVG86IFBldGVyIFNhaW50LUFuZHJlIDxzdHBldGVyQG1vemlsbGEuY29tPG1haWx0bzpz dHBldGVyQG1vemlsbGEuY29tPj4NCkNjOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+OyBKYXJlZCBKZW5u aW5ncyA8amFyZWRsamVubmluZ3NAZ21haWwuY29tPG1haWx0bzpqYXJlZGxqZW5uaW5nc0BnbWFp bC5jb20+PjsgQW1hbmplZXYgU2V0aGkgPGFqQGFtYW5qZWV2LmNvbTxtYWlsdG86YWpAYW1hbmpl ZXYuY29tPj47IEZhYmllbiBJbWJhdWx0IDxmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208bWFpbHRv OmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbT4+OyB0eGF1dGhAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0 aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVHhhdXRoXSBHTkFQIGl0IGlzDQoNCkNoZWNraW5n IGluIGFnYWluIG9uIHByb251bmNpYXRpb24uDQoNCk1pa2U6IGRvIHlvdSBzdGlsbCBoYXZlIGNv bmNlcm5zIHdpdGggYSBzaWxlbnQgJ0cnPw0KDQpBbnlvbmUgZWxzZSBoYXZlIGNvbmNlcm5zPw0K DQpJJ2QgbGlrZSB0byBuaXAgcHJvbnVuY2lhdGlvbiBjb25mdXNpb24gaW4gdGhlIGJ1ZCBieSBo YXZpbmcgdGhlIHJlY29tbWVuZGVkIHByb251bmNpYXRpb24gaW4gdGhlIGNoYXJ0ZXIuDQoNCg0K 4ZCnDQoNCk9uIFN1biwgSnVuIDcsIDIwMjAgYXQgMToyMyBQTSBQZXRlciBTYWludC1BbmRyZSA8 c3RwZXRlckBtb3ppbGxhLmNvbTxtYWlsdG86c3RwZXRlckBtb3ppbGxhLmNvbT4+IHdyb3RlOg0K TG9va3MgbGlrZSB3ZSB3ZXJlIGNhdWdodCBnbmFwcGluZy4gOy0pDQoNCk9LLCB0aGF0J3MgdGhl IGxhc3Qgb2YgbXkgc25hcmt5IGNvbW1lbnRzLCBsZXQncyBnZXQgdG8gd29yayENCg0KUGV0ZXIN Cg0KT24gNi83LzIwIDI6MDkgUE0sIERpY2sgSGFyZHQgd3JvdGU6DQo+IEl0IGlzIGlmIHlvdSBh cmUgZmFtaWxpYXIgd2l0aCBhbnkgb2YgdGhlIEdOVSBwcm9qZWN0cy4NCj4NCj4gaHR0cHM6Ly93 d3cuZ251Lm9yZy9nbnUvcHJvbnVuY2lhdGlvbi5lbi5odG1sDQo+DQo+IEEgcXVpY2sgc2VhcmNo IG9uIHRoZSBpbnRlcm5ldCBoYXMgdGhlICJub3JtYWwiIHByb251bmNpYXRpb24gb2YgImdudSIN Cj4gdG8gaGF2ZSBhIHNpbGVudCAnZycuDQo+DQo+IGh0dHBzOi8vd3d3Lmhvd3RvcHJvbm91bmNl LmNvbS9nbnUNCj4gaHR0cHM6Ly9kaWN0aW9uYXJ5LmNhbWJyaWRnZS5vcmcvdXMvcHJvbnVuY2lh dGlvbi9lbmdsaXNoL2dudQ0KPg0KPg0KPiDhkKcNCj4NCj4gT24gU3VuLCBKdW4gNywgMjAyMCBh dCAxMjo1MSBQTSBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRv Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCj4gPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+PiB3cm90ZToN Cj4NCj4gICAgIEkgaGFkIGFzc3VtZWQgR3VoLU5hcCDigJMgcGFyYWxsZWwgdG8gdGhlIHByb251 bmNpYXRpb24gb2YgR05VLiAgSQ0KPiAgICAgdGhpbmsgdGhhdOKAmXMgdGhlIG1vc3QgbmF0dXJh bCB3YXkgdG8gcmVhZCBpdC5fX19fDQo+DQo+ICAgICBfXyBfXw0KPg0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2VfX19f DQo+DQo+ICAgICBfXyBfXw0KPg0KPiAgICAgKkZyb206KiBUeGF1dGggPHR4YXV0aC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzp0eGF1dGgtYm91bmNlc0BpZXRmLm9yZz4NCj4gICAgIDxtYWlsdG86 dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnR4YXV0aC1ib3VuY2VzQGlldGYub3JnPj4+ ICpPbiBCZWhhbGYgT2YgKkRpY2sgSGFyZHQNCj4gICAgICpTZW50OiogU3VuZGF5LCBKdW5lIDcs IDIwMjAgMTI6NDUgUE0NCj4gICAgICpUbzoqIEFtYW5qZWV2IFNldGhpIDxhakBhbWFuamVldi5j b208bWFpbHRvOmFqQGFtYW5qZWV2LmNvbT4gPG1haWx0bzphakBhbWFuamVldi5jb208bWFpbHRv OmFqQGFtYW5qZWV2LmNvbT4+Pg0KPiAgICAgKkNjOiogRmFiaWVuIEltYmF1bHQgPGZhYmllbi5p bWJhdWx0QGdtYWlsLmNvbTxtYWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPg0KPiAgICAg PG1haWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208bWFpbHRvOmZhYmllbi5pbWJhdWx0QGdt YWlsLmNvbT4+PjsgSmFyZWQgSmVubmluZ3MNCj4gICAgIDxqYXJlZGxqZW5uaW5nc0BnbWFpbC5j b208bWFpbHRvOmphcmVkbGplbm5pbmdzQGdtYWlsLmNvbT4gPG1haWx0bzpqYXJlZGxqZW5uaW5n c0BnbWFpbC5jb208bWFpbHRvOmphcmVkbGplbm5pbmdzQGdtYWlsLmNvbT4+PjsNCj4gICAgIHR4 YXV0aEBpZXRmLm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPiA8bWFpbHRvOnR4YXV0aEBpZXRm Lm9yZzxtYWlsdG86dHhhdXRoQGlldGYub3JnPj4NCj4gICAgICpTdWJqZWN0OiogUmU6IFtUeGF1 dGhdIEdOQVAgaXQgaXNfX19fDQo+DQo+ICAgICBfXyBfXw0KPg0KPiAgICAgQW55b25lIGhhdmUg b2JqZWN0aW9uIHRvIHRoZSByZWNvbW1lbmRlZCBwcm9udW5jaWF0aW9uIGJlaW5nIHRoZQ0KPiAg ICAgRW5nbGlzaCB3b3JkICJuYXAiLCBhcyBpbiAiZ25hdyI/X19fXw0KPg0KPiAgICAgX18gX18N Cj4NCj4gICAgIElmIG5vdCwgdGhlbiB3ZSBjb3VsZCBhZGQgYSBwcm9udW5jaWF0aW9uIHJlY29t bWVuZGF0aW9uIHRvIHRoZQ0KPiAgICAgQ2hhcnRlci5fX19fDQo+DQo+ICAgICBfXyBfXw0KPg0K PiAgICAg4ZCnX19fXw0KPg0KPiAgICAgX18gX18NCj4NCj4gICAgIE9uIFNhdCwgSnVuIDYsIDIw MjAgYXQgODowMyBBTSBBbWFuamVldiBTZXRoaSA8YWpAYW1hbmplZXYuY29tPG1haWx0bzphakBh bWFuamVldi5jb20+DQo+ICAgICA8bWFpbHRvOmFqQGFtYW5qZWV2LmNvbTxtYWlsdG86YWpAYW1h bmplZXYuY29tPj4+IHdyb3RlOl9fX18NCj4NCj4gICAgICAgICBWb3RlIGZvciAnRycgc2lsZW50 LCBhcyBpbiAnbGFnbmFwcGUnIDspX19fXw0KPg0KPiAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAg ICAgT24gU2F0LCBKdW4gNiwgMjAyMCwgYXQgMTA6NTIgQU0sIEphcmVkIEplbm5pbmdzIHdyb3Rl Ol9fX18NCj4NCj4gICAgICAgICAgICAgSSB2b3RlIGZvciBHIHNpbGVudC4gRm9yIHRoZSByZWFz b24gaXQncyBtb3N0IGNvbW1vbiB0bw0KPiAgICAgICAgICAgICBwcm9ub3VuY2UsIGVzcGVjaWFs bHkgZm9yIHRob3NlIG5vdCBmYW1pbGlhciB3aXRoIG9wZW4NCj4gICAgICAgICAgICAgc291cmNl IHVzYWdlcy5fX19fDQo+DQo+ICAgICAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAgICAgIE9u IFNhdCwgSnVuIDYsIDIwMjAsIDA4OjQ1IERpY2sgSGFyZHQgPGRpY2suaGFyZHRAZ21haWwuY29t PG1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbT4NCj4gICAgICAgICAgICAgPG1haWx0bzpkaWNr LmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+Pj4gd3JvdGU6X19f Xw0KPg0KPiAgICAgICAgICAgICAgICAgVGhlIG9idmlvdXMgcHJvbnVuY2lhdGlvbiBjaG9pY2Vz IGFyZTpfX19fDQo+DQo+ICAgICAgICAgICAgICAgICBfXyBfXw0KPg0KPiAgICAgICAgICAgICAg ICAgbmFwIChzaWxlbnQgZyBhcyBpbiBnbmF3KV9fX18NCj4NCj4gICAgICAgICAgICAgICAgIF9f IF9fDQo+DQo+ICAgICAgICAgICAgICAgICBndWgtbmFwIChhcyBpbiB0aGUgR05VIE9TDQo+ICAg ICAgICAgICAgICAgICAtIGh0dHBzOi8vd3d3LmdudS5vcmcvZ251L3Byb251bmNpYXRpb24uZW4u Lmh0bWwNCj4gICAgICAgICAgICAgICAgIDxodHRwczovL3d3dy5nbnUub3JnL2dudS9wcm9udW5j aWF0aW9uLmVuLmh0bWw+KV9fX18NCj4NCj4gICAgICAgICAgICAgICAgIF9fIF9fDQo+DQo+ICAg ICAgICAgICAgICAgICBnZWUtbmFwIChhcyBpbiBHLW1hbiAtIGdvdmVybm1lbnQgbWFuDQo+ICAg ICAgICAgICAgICAgICAtIGh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0ctbWFuKV9fX18N Cj4NCj4gICAgICAgICAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAgICAgICAgICBfXyBfXw0K Pg0KPiAgICAgICAgICAgICAgICAgX18gX18NCj4NCj4gICAgICAgICAgICAgICAgIOGQp19fX18N Cj4NCj4gICAgICAgICAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAgICAgICAgICBPbiBTYXQs IEp1biA2LCAyMDIwIGF0IDE6MzQgQU0gRmFiaWVuIEltYmF1bHQNCj4gICAgICAgICAgICAgICAg IDxmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208bWFpbHRvOmZhYmllbi5pbWJhdWx0QGdtYWlsLmNv bT4NCj4gICAgICAgICAgICAgICAgIDxtYWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPG1h aWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20+Pj4gd3JvdGU6X19fXw0KPg0KPiAgICAgICAg ICAgICAgICAgICAgIFNvLCBsZXQncyBhZG9wdCBhIEdOQVAhIFdlIGNhbiBldmVuIGNvbWUgd2l0 aCBhDQo+ICAgICAgICAgICAgICAgICAgICAgbGl0dGxlIG1hc2NvdCAoYSBiaXQgbGlrZSBnbyBn b3BoZXIpIGFzIGltYWdpbmVkDQo+ICAgICAgICAgICAgICAgICAgICAgYnkgaHR0cDovL2VsaXNl Z3JhdmVsLmNvbS9ibG9nL2Fkb3B0ZS11bi1nbmFwLywNCj4gICAgICAgICAgICAgICAgICAgICBs b3ZlZCBieSBsaXR0bGUgQ2FuYWRpYW5zIDotKSBfX19fDQo+DQo+ICAgICAgICAgICAgICAgICAg ICAgX18gX18NCj4NCj4gICAgICAgICAgICAgICAgICAgICBKdXN0IHRvIGJlIHN1cmUsIGhvdyBk byB5b3UgcmVjb21tYW5kIHdlIHByb25vdW5jZQ0KPiAgICAgICAgICAgICAgICAgICAgIGl0PyBf X19fDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgX18gX18NCj4NCj4gICAgICAgICAgICAgICAg ICAgICBMb29raW5nIGZvcndhcmQgdG8gdGhlIG5leHQgc3RlcHMgdG9vLi4gX19fXw0KPg0KPiAg ICAgICAgICAgICAgICAgICAgIF9fIF9fDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgVGh4c19f X18NCj4NCj4gICAgICAgICAgICAgICAgICAgICBGYWJpZW5fX19fDQo+DQo+ICAgICAgICAgICAg ICAgICAgICAgLS1fX19fDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgVHhhdXRoIG1haWxpbmcg bGlzdF9fX18NCj4NCj4gICAgICAgICAgICAgICAgICAgICBUeGF1dGhAaWV0Zi5vcmc8bWFpbHRv OlR4YXV0aEBpZXRmLm9yZz4gPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc8bWFpbHRvOlR4YXV0aEBp ZXRmLm9yZz4+X19fXw0KPg0KPiAgICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHhhdXRoX19fXw0KPg0KPiAgICAgICAgICAgICAgICAgLS1f X19fDQo+DQo+ICAgICAgICAgICAgICAgICBUeGF1dGggbWFpbGluZyBsaXN0X19fXw0KPg0KPiAg ICAgICAgICAgICAgICAgVHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc+IDxt YWlsdG86VHhhdXRoQGlldGYub3JnPG1haWx0bzpUeGF1dGhAaWV0Zi5vcmc+Pl9fX18NCj4NCj4g ICAgICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHhh dXRoX19fXw0KPg0KPiAgICAgICAgICAgICAtLSBfX19fDQo+DQo+ICAgICAgICAgICAgIFR4YXV0 aCBtYWlsaW5nIGxpc3RfX19fDQo+DQo+ICAgICAgICAgICAgIFR4YXV0aEBpZXRmLm9yZzxtYWls dG86VHhhdXRoQGlldGYub3JnPiA8bWFpbHRvOlR4YXV0aEBpZXRmLm9yZzxtYWlsdG86VHhhdXRo QGlldGYub3JnPj5fX19fDQo+DQo+ICAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHhhdXRoX19fXw0KPg0KPiAgICAgICAgICAgICBfXyBfXw0KPg0KPiAg ICAgICAgIF9fIF9fDQo+DQo+DQo= --_000_MN2PR00MB0688D7AA407E0D8C31A1453DF59C0MN2PR00MB0688namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5JIGRvbuKAmXQgY2FyZSBh IGxvdCBvbmUgd2F5IG9yIHRoZSBvdGhlci4mbmJzcDsgTXkgbWFpbiBwb2ludCBpcyB0aGF0IG5v IG1hdHRlciB3aGF0IGd1aWRhbmNlIHdlIGdpdmUsIG1hbnkgcGVvcGxlIGFyZSBsaWtlbHkgdG8g cHJvbm91bmNlIHRoZSDigJxH4oCdLiZuYnNwOyBJZiB3ZSB0cnkgdG8gaW5zaXN0IG9uIGl0IGJl aW5nIHNpbGVudCwgd2Ugc2hvdWxkIGdldCB1c2VkIHRvIHRoZQ0KIGZhY3QgdGhhdCB3ZeKAmWxs IHByb2JhYmx5IGJlIGhlYXJpbmcgYm90aCBwcm9udW5jaWF0aW9ucy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5QLlMuJm5i c3A7IFRoYW5rcyBmb3IgdGhlIFNtdXJmcyBsaW5rLCBWaXR0b3JpbyE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiB2aXR0b3Jpby5iZXJ0b2Nj aUBhdXRoMC5jb20gJmx0O3ZpdHRvcmlvLmJlcnRvY2NpQGF1dGgwLmNvbSZndDsNCjxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMTUsIDIwMjAgMTI6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+ ICdEaWNrIEhhcmR0JyAmbHQ7ZGljay5oYXJkdEBnbWFpbC5jb20mZ3Q7OyAnUGV0ZXIgU2FpbnQt QW5kcmUnICZsdDtzdHBldGVyQG1vemlsbGEuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWlrZSBK b25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OzsgJ0phcmVkIEplbm5pbmdz JyAmbHQ7amFyZWRsamVubmluZ3NAZ21haWwuY29tJmd0OzsgJ0FtYW5qZWV2IFNldGhpJyAmbHQ7 YWpAYW1hbmplZXYuY29tJmd0OzsgJ0ZhYmllbiBJbWJhdWx0JyAmbHQ7ZmFiaWVuLmltYmF1bHRA Z21haWwuY29tJmd0OzsgdHhhdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBb VHhhdXRoXSBHTkFQIGl0IGlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QZXJoYXBzIG5vdCB0byBiZSB0YWtlbiB0b28gc2VyaW91c2x5LCBidXQgaGVyZeKAmXMgcHJp b3IgYXJ0IG9uIEdOQVAgcHJvbnVuY2lhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFzIExlaWYgbWVudGlvbmVkIGZldyBtYWlscyBhZ28sIOKAnEdOQVDigJ0gYXBw ZWFyZWQgb24gdGhlIFNtdXJmcyBjb21pYyBhbmQgd2FzIHJlcHJpc2VkIGluIGEgY2FydG9vbiBl cGlzb2RlIGFzIHdlbGwuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllv deKAmWxsIGZpbmQgZmV3IGV4YW1wbGVzIGFyb3VuZCAzOjMwPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy55b3V0dWJlLmNvbS93 YXRjaD92PUdFbDhJQnY5OHZnJmFtcDtmZWF0dXJlPXlvdXR1LmJlJmFtcDtmYmNsaWQ9SXdBUjBH VmZGZU5sNE0xT2hIS0U3RmZ5Q3FLVERKSTk2MG1VLWFpOGhMcU1POEFfcXpDUy1XQkpnUGJwUSI+ aHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1HRWw4SUJ2OTh2ZyZhbXA7ZmVhdHVyZT15 b3V0dS5iZSZhbXA7ZmJjbGlkPUl3QVIwR1ZmRmVObDRNMU9oSEtFN0ZmeUNxS1RESkk5NjBtVS1h aThoTHFNTzhBX3F6Q1MtV0JKZ1BicFE8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBUeGF1dGggJmx0OzxhIGhyZWY9Im1h aWx0bzp0eGF1dGgtYm91bmNlc0BpZXRmLm9yZyI+dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5EaWNrIEhhcmR0PGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgSnVuZSAxNSwgMjAyMCAxMjoxOCBQTTxicj4NCjxiPlRvOjwvYj4gUGV0ZXIgU2FpbnQt QW5kcmUgJmx0OzxhIGhyZWY9Im1haWx0bzpzdHBldGVyQG1vemlsbGEuY29tIj5zdHBldGVyQG1v emlsbGEuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9 Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9z b2Z0LmNvbTwvYT4mZ3Q7OyBKYXJlZCBKZW5uaW5ncyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphcmVk bGplbm5pbmdzQGdtYWlsLmNvbSI+amFyZWRsamVubmluZ3NAZ21haWwuY29tPC9hPiZndDs7IEFt YW5qZWV2IFNldGhpICZsdDs8YSBocmVmPSJtYWlsdG86YWpAYW1hbmplZXYuY29tIj5hakBhbWFu amVldi5jb208L2E+Jmd0OzsNCiBGYWJpZW4gSW1iYXVsdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZh Ymllbi5pbWJhdWx0QGdtYWlsLmNvbSI+ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPC9hPiZndDs7 DQo8YSBocmVmPSJtYWlsdG86dHhhdXRoQGlldGYub3JnIj50eGF1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVHhhdXRoXSBHTkFQIGl0IGlzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWNraW5nIGluIGFnYWluIG9uIHByb251bmNpYXRp b24uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWtlOiBk byB5b3Ugc3RpbGwgaGF2ZSBjb25jZXJucyB3aXRoIGEgc2lsZW50ICdHJz88bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW55b25lIGVsc2UgaGF2 ZSBjb25jZXJucz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSdkIGxpa2UgdG8gbmlwIHByb251bmNpYXRpb24gY29uZnVzaW9uIGluIHRoZSBi dWQgYnkgaGF2aW5nIHRoZSByZWNvbW1lbmRlZCBwcm9udW5jaWF0aW9uJm5ic3A7aW4gdGhlIGNo YXJ0ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjEiIGhlaWdodD0iMSIgc3R5bGU9 IndpZHRoOi4wMTA0aW47aGVpZ2h0Oi4wMTA0aW4iIGlkPSJfeDAwMDBfaTEwMjUiIHNyYz0iaHR0 cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lYSmtkRUJuYldG cGJDNWpiMjAlM0QmYW1wO3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9MDMzYTZhNzItZjNkYi00 Mzg3LWE2NjItZDYzYTkwOGIzZGQ3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRlIj7hkKc8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4s IEp1biA3LCAyMDIwIGF0IDE6MjMgUE0gUGV0ZXIgU2FpbnQtQW5kcmUgJmx0OzxhIGhyZWY9Im1h aWx0bzpzdHBldGVyQG1vemlsbGEuY29tIj5zdHBldGVyQG1vemlsbGEuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9va3MgbGlrZSB3ZSB3 ZXJlIGNhdWdodCBnbmFwcGluZy4gOy0pPGJyPg0KPGJyPg0KT0ssIHRoYXQncyB0aGUgbGFzdCBv ZiBteSBzbmFya3kgY29tbWVudHMsIGxldCdzIGdldCB0byB3b3JrITxicj4NCjxicj4NClBldGVy PGJyPg0KPGJyPg0KT24gNi83LzIwIDI6MDkgUE0sIERpY2sgSGFyZHQgd3JvdGU6PGJyPg0KJmd0 OyBJdCBpcyBpZiB5b3UgYXJlIGZhbWlsaWFyIHdpdGggYW55IG9mIHRoZSBHTlUgcHJvamVjdHMu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmdudS5vcmcvZ251L3By b251bmNpYXRpb24uZW4uaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmdudS5vcmcv Z251L3Byb251bmNpYXRpb24uZW4uaHRtbDwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgQSBxdWlj ayBzZWFyY2ggb24gdGhlIGludGVybmV0IGhhcyB0aGUgJnF1b3Q7bm9ybWFsJnF1b3Q7IHByb251 bmNpYXRpb24gb2YgJnF1b3Q7Z251JnF1b3Q7PGJyPg0KJmd0OyB0byBoYXZlIGEgc2lsZW50ICdn Jy48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaG93dG9wcm9ub3Vu Y2UuY29tL2dudSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmhvd3RvcHJvbm91bmNlLmNv bS9nbnU8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2RpY3Rpb25hcnkuY2FtYnJpZGdl Lm9yZy91cy9wcm9udW5jaWF0aW9uL2VuZ2xpc2gvZ251IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL2RpY3Rpb25hcnkuY2FtYnJpZGdlLm9yZy91cy9wcm9udW5jaWF0aW9uL2VuZ2xpc2gvZ251 PC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtHYWR1Z2kmcXVvdDssc2Fucy1zZXJpZiI+4ZCnPC9zcGFuPjxicj4NCiZndDsg PGJyPg0KJmd0OyBPbiBTdW4sIEp1biA3LCAyMDIwIGF0IDEyOjUxIFBNIE1pa2UgSm9uZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2Js YW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+PGJyPg0KJmd0OyAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2Js YW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtJIGhhZCBhc3N1bWVkIEd1aC1OYXAg 4oCTIHBhcmFsbGVsIHRvIHRoZSBwcm9udW5jaWF0aW9uIG9mIEdOVS4mbmJzcDsgSTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwO3RoaW5rIHRoYXTigJlzIHRoZSBtb3N0IG5hdHVyYWwgd2F5 IHRvIHJlYWQgaXQuX19fXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 X18mbmJzcDtfXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2VfX19fPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtfXyZuYnNwO19fPGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsqRnJvbToqIFR4YXV0aCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnR4YXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoLWJvdW5jZXNA aWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1 dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyAqT24gQmVoYWxmIE9mICpEaWNrIEhhcmR0 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7KlNlbnQ6KiBTdW5kYXksIEp1bmUgNywgMjAy MCAxMjo0NSBQTTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOypUbzoqIEFtYW5qZWV2IFNl dGhpICZsdDs8YSBocmVmPSJtYWlsdG86YWpAYW1hbmplZXYuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YWpAYW1hbmplZXYuY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzphakBhbWFuamVl di5jb20iIHRhcmdldD0iX2JsYW5rIj5hakBhbWFuamVldi5jb208L2E+Jmd0OyZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsqQ2M6KiBGYWJpZW4gSW1iYXVsdCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmZhYmllbi5pbWJhdWx0QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZhYmllbi5p bWJhdWx0QGdtYWlsLmNvbTwvYT48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5mYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208L2E+Jmd0OyZndDs7IEphcmVkIEplbm5pbmdz PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Im1haWx0bzpqYXJlZGxq ZW5uaW5nc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qYXJlZGxqZW5uaW5nc0BnbWFpbC5j b208L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmphcmVkbGplbm5pbmdzQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmphcmVkbGplbm5pbmdzQGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0Ozs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWlsdG86dHhhdXRoQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+dHhhdXRoQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzp0eGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50eGF1dGhAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOypTdWJqZWN0OiogUmU6IFtU eGF1dGhdIEdOQVAgaXQgaXNfX19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDtfXyZuYnNwO19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtB bnlvbmUgaGF2ZSBvYmplY3Rpb24gdG8gdGhlIHJlY29tbWVuZGVkIHByb251bmNpYXRpb24mbmJz cDtiZWluZyB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtFbmdsaXNoIHdvcmQgJnF1 b3Q7bmFwJnF1b3Q7LCBhcyBpbiAmcXVvdDtnbmF3JnF1b3Q7P19fX188YnI+DQomZ3Q7IDxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO19fJm5ic3A7X188YnI+DQomZ3Q7IDxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwO0lmIG5vdCwgdGhlbiB3ZSBjb3VsZCBhZGQgYSBwcm9udW5jaWF0 aW9uJm5ic3A7cmVjb21tZW5kYXRpb24gdG8gdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7Q2hhcnRlci5fX19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtf XyZuYnNwO19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2FkdWdpJnF1b3Q7LHNhbnMtc2VyaWYiPuGQpzwvc3Bh bj5fX19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtfXyZuYnNwO19f PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtPbiBTYXQsIEp1biA2LCAy MDIwIGF0IDg6MDMgQU0gQW1hbmplZXYgU2V0aGkgJmx0OzxhIGhyZWY9Im1haWx0bzphakBhbWFu amVldi5jb20iIHRhcmdldD0iX2JsYW5rIj5hakBhbWFuamVldi5jb208L2E+PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86YWpAYW1hbmplZXYu Y29tIiB0YXJnZXQ9Il9ibGFuayI+YWpAYW1hbmplZXYuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOl9f X188YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Vm90ZSBmb3IgJ0cnIHNpbGVudCwgYXMgaW4gJ2xhZ25hcHBlJyA7KV9fX188YnI+DQomZ3Q7IDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X18mbmJzcDtfXzxicj4N CiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtPbiBTYXQs IEp1biA2LCAyMDIwLCBhdCAxMDo1MiBBTSwgSmFyZWQgSmVubmluZ3Mgd3JvdGU6X19fXzxicj4N CiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0kgdm90ZSBmb3IgRyBzaWxlbnQuIEZvciB0aGUgcmVhc29uIGl0J3MgbW9zdCBjb21t b24gdG88YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7cHJvbm91bmNlLCBlc3BlY2lhbGx5IGZvciB0aG9zZSBub3QgZmFtaWxpYXIgd2l0aCBv cGVuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3NvdXJjZSB1c2FnZXMuX19fXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fJm5ic3A7X188YnI+DQomZ3Q7IDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtP biBTYXQsIEp1biA2LCAyMDIwLCAwODo0NSBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJtYWlsdG86 ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNv bTwvYT48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdtYWlsLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTpfX19f PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgb2J2aW91cyBwcm9udW5jaWF0aW9uIGNob2lj ZXMgYXJlOl9fX188YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO19fJm5ic3A7X188YnI+DQomZ3Q7 IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO25hcCAoc2lsZW50IGcgYXMgaW4gZ25hdylfX19fPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtfXyZuYnNwO19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtndWgtbmFw IChhcyBpbiB0aGUgR05VIE9TPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v d3d3LmdudS5vcmcvZ251L3Byb251bmNpYXRpb24uZW4uLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5nbnUub3JnL2dudS9wcm9udW5jaWF0aW9uLmVuLi5odG1sPC9hPjxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwczovL3d3dy5nbnUub3JnL2dudS9wcm9udW5jaWF0aW9u LmVuLmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5nbnUub3JnL2dudS9wcm9udW5j aWF0aW9uLmVuLmh0bWw8L2E+Jmd0OylfX19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfXyZu YnNwO19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtnZWUtbmFwIChhcyBpbiBHLW1hbiAtIGdv dmVybm1lbnQgbWFuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZW4ud2lr aXBlZGlhLm9yZy93aWtpL0ctbWFuKV9fX18iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2VuLndp a2lwZWRpYS5vcmcvd2lraS9HLW1hbilfX19fPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 X18mbmJzcDtfXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X18mbmJzcDtfXzxicj4NCiZndDsg PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7X18mbmJzcDtfXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmIj7hkKc8L3Nw YW4+X19fXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X18mbmJzcDtfXzxicj4NCiZndDsgPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7T24gU2F0LCBKdW4gNiwgMjAyMCBhdCAxOjM0IEFNIEZhYmllbiBJbWJhdWx0 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9Im1haWx0bzpmYWJpZW4uaW1iYXVsdEBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5mYWJpZW4uaW1iYXVsdEBnbWFpbC5jb208L2E+PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZmFiaWVuLmltYmF1bHRAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZmFiaWVuLmltYmF1bHRAZ21haWwuY29tPC9hPiZndDsmZ3Q7IHdy b3RlOl9fX188YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U28sIGxldCdz IGFkb3B0IGEgR05BUCEgV2UgY2FuIGV2ZW4gY29tZSB3aXRoIGE8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2xpdHRsZSBtYXNjb3QgKGEgYml0IGxpa2UgZ28gZ29waGVyKSBhcyBpbWFnaW5l ZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YnkmbmJzcDs8YSBocmVmPSJodHRwOi8vZWxp c2VncmF2ZWwuY29tL2Jsb2cvYWRvcHRlLXVuLWduYXAvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDov L2VsaXNlZ3JhdmVsLmNvbS9ibG9nL2Fkb3B0ZS11bi1nbmFwLzwvYT4sPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtsb3ZlZCBieSBsaXR0bGUgQ2FuYWRpYW5zIDotKSZuYnNwO19fX188YnI+ DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7X18mbmJzcDtfXzxicj4NCiZndDsg PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtKdXN0IHRvIGJlIHN1cmUsIGhvdyBkbyB5b3Ug cmVjb21tYW5kIHdlIHByb25vdW5jZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aXQ/Jm5i c3A7X19fXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfXyZuYnNwO19f PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0xvb2tpbmcgZm9yd2FyZCB0 byB0aGUgbmV4dCBzdGVwcyB0b28uLiZuYnNwO19fX188YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7X18mbmJzcDtfXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtUaHhzX19fXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtG YWJpZW5fX19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tX19fXzxi cj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUeGF1dGggbWFpbGluZyBsaXN0 X19fXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJtYWls dG86VHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VHhhdXRoQGlldGYub3JnPC9hPiAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5UeGF1dGhAaWV0Zi5vcmc8L2E+Jmd0O19fX188YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90eGF1dGhfX19fIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90eGF1dGhfX19fPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LS1fX19f PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUeGF1dGggbWFpbGluZyBsaXN0X19fXzxicj4NCiZn dDsgPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0ibWFpbHRvOlR4YXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPlR4YXV0aEBpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 VHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VHhhdXRoQGlldGYub3JnPC9hPiZndDtf X19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aF9fX18iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aF9fX188L2E+PGJyPg0KJmd0OyA8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LS0m bmJzcDtfX19fPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7VHhhdXRoIG1haWxpbmcgbGlzdF9fX188YnI+DQomZ3Q7IDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 YSBocmVmPSJtYWlsdG86VHhhdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VHhhdXRoQGll dGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpUeGF1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5UeGF1dGhAaWV0Zi5vcmc8L2E+Jmd0O19fX188YnI+DQomZ3Q7IDxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0aF9fX18iIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3R4YXV0 aF9fX188L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7X18mbmJzcDtfXzxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtfXyZuYnNwO19fPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_MN2PR00MB0688D7AA407E0D8C31A1453DF59C0MN2PR00MB0688namp_-- From nobody Mon Jun 15 12:40:44 2020 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 CE3CD3A0A26 for ; Mon, 15 Jun 2020 12:40:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 CNoolssuic7m for ; Mon, 15 Jun 2020 12:40:41 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 A2B943A08FE for ; Mon, 15 Jun 2020 12:40:40 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id d27so5705439lfq.5 for ; Mon, 15 Jun 2020 12:40:40 -0700 (PDT) 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=H+JNIEU8X5w5X1gxdJzJlJXBHjt8/9faclpwlAXiuR4=; b=bWud26MEkbp3miMxhPIeiFahkP5aCnlVYN+0BseGLRudXPNGMyjIo1nccI6qhQ3VYi DF6YhX7t5pxV/QKFcsjMmQAOafruUNwAuc2ZIQlGJC9tvHfjwvlcFbq2BVJELy5tolk9 6/Nlyg9qDKvFDj/MLQktZvHwJqpSDlka7PgS54a3tlVIQukutSYA/qPxDk7EY2OJK10I cYaKNHghwuU3MdLLUpalRYcwx/FQMGPmn0B5EUiTktGDq3WYXWsYCgl7Mgsp3H3NHKeE bFt6AEv4CFlHF7gMA5NFVC7IWR4UhFSkoxMNHlITLFqHE3gKFEvcxG+/tfet9QkAUCxt thbQ== 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=H+JNIEU8X5w5X1gxdJzJlJXBHjt8/9faclpwlAXiuR4=; b=fZudAOMXiCAVxfBDZ0URrNQkUi73NvWLQyodRkVqcYw1Ale6JnCsYPy2zOWTor2eDg yA/HBFDb/7zuQUITwUCzAjhh2T87VuWK4m6S4JxIK2ux7BZ5KXTSGgfxZcQ/QM2KG+s1 9mTmRDHiSOSB7js1BRb9NX9cVNGH30HXGgO+YZMx+Ru+XNNN1t+qbcZ/s4C7mTbylY6p ElxhUqhXkhqw3PxDvbxnt+AZEAZBqAdCbNQ/GIHo14Pf3+hMUySM58RIaae/8sk32Qig Issv+y/3UG6z96RcR2FjurK8JH+kWams1HBbp+twDbFZZ451PtJQRNgd70zrFCpdnWcB SOdQ== X-Gm-Message-State: AOAM530XhVBQusQHNoL/yySvmp7cdcuMAe4CN0GZxBkURa7DuYeSMoDk 6bnvFz5HGxZP16k29GFc/SBTUWzSW3vMkm04YZFUYkrM X-Google-Smtp-Source: ABdhPJzO3RME8g1uijLgKWfrCybDGc/IjZEY6wgJ2tAsjUHgy0mvN8tsdob3QYbYOTQzR1S1Iyw2XZyUzfijA+PQuL8= X-Received: by 2002:ac2:5dc8:: with SMTP id x8mr9775832lfq.71.1592250038640; Mon, 15 Jun 2020 12:40:38 -0700 (PDT) MIME-Version: 1.0 References: <8db677bd-d054-136f-fbad-cae55237f7a8@mozilla.com> <019d01d6434a$af721ae0$0e5650a0$@auth0.com> In-Reply-To: <019d01d6434a$af721ae0$0e5650a0$@auth0.com> From: Dick Hardt Date: Mon, 15 Jun 2020 12:40:12 -0700 Message-ID: To: Vittorio Bertocci Cc: Peter Saint-Andre , Mike Jones , Jared Jennings , Amanjeev Sethi , Fabien Imbault , txauth@ietf.org, Leif Johansson Content-Type: multipart/alternative; boundary="000000000000f2660d05a8249903" Archived-At: Subject: Re: [Txauth] GNAP it is 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, 15 Jun 2020 19:40:43 -0000 --000000000000f2660d05a8249903 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Vittorio Thanks for sharing the video and where the word is pronounced -- guh-nap for those that have not watched it. ( I saw the usage of "gnap" in what Leif shared, but did not see pronunciation ) Are you concerned with the silent G pronunciation, or just sharing data? A concern voiced with guh-nap was the association with GNU work. (I'm hoping to check off this last co-chair item on my list ... ) =E1=90=A7 On Mon, Jun 15, 2020 at 12:25 PM wrote: > Perhaps not to be taken too seriously, but here=E2=80=99s prior art on GN= AP > pronunciation. > > As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the S= murfs comic and > was reprised in a cartoon episode as well. > > You=E2=80=99ll find few examples around 3:30 > > > https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbclid= =3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ > > > > *From:* Txauth *On Behalf Of *Dick Hardt > *Sent:* Monday, June 15, 2020 12:18 PM > *To:* Peter Saint-Andre > *Cc:* Mike Jones ; Jared Jennings < > jaredljennings@gmail.com>; Amanjeev Sethi ; Fabien > Imbault ; txauth@ietf.org > *Subject:* Re: [Txauth] GNAP it is > > > > Checking in again on pronunciation. > > > > Mike: do you still have concerns with a silent 'G'? > > > > Anyone else have concerns? > > > > I'd like to nip pronunciation confusion in the bud by having the > recommended pronunciation in the charter. > > > > > > =E1=90=A7 > > > > On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre > wrote: > > Looks like we were caught gnapping. ;-) > > OK, that's the last of my snarky comments, let's get to work! > > Peter > > On 6/7/20 2:09 PM, Dick Hardt wrote: > > It is if you are familiar with any of the GNU projects. > > > > https://www.gnu.org/gnu/pronunciation.en.html > > > > A quick search on the internet has the "normal" pronunciation of "gnu" > > to have a silent 'g'. > > > > https://www.howtopronounce.com/gnu > > https://dictionary.cambridge.org/us/pronunciation/english/gnu > > > > > > =E1=90=A7 > > > > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones > > wrote: > > > > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of GN= U. I > > think that=E2=80=99s the most natural way to read it.____ > > > > __ __ > > > > -- Mike____ > > > > __ __ > > > > *From:* Txauth > > *On Behalf Of *Dick Hardt > > *Sent:* Sunday, June 7, 2020 12:45 PM > > *To:* Amanjeev Sethi > > > *Cc:* Fabien Imbault > >; Jared Jennings > > >; > > txauth@ietf.org > > *Subject:* Re: [Txauth] GNAP it is____ > > > > __ __ > > > > Anyone have objection to the recommended pronunciation being the > > English word "nap", as in "gnaw"?____ > > > > __ __ > > > > If not, then we could add a pronunciation recommendation to the > > Charter.____ > > > > __ __ > > > > =E1=90=A7____ > > > > __ __ > > > > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi > > wrote:____ > > > > Vote for 'G' silent, as in 'lagnappe' ;)____ > > > > __ __ > > > > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____ > > > > I vote for G silent. For the reason it's most common to > > pronounce, especially for those not familiar with open > > source usages.____ > > > > __ __ > > > > On Sat, Jun 6, 2020, 08:45 Dick Hardt > > wrote:____ > > > > The obvious pronunciation choices are:____ > > > > __ __ > > > > nap (silent g as in gnaw)____ > > > > __ __ > > > > guh-nap (as in the GNU OS > > - https://www.gnu.org/gnu/pronunciation.en..html > > )____ > > > > __ __ > > > > gee-nap (as in G-man - government man > > - https://en.wikipedia.org/wiki/G-man)____ > > > > __ __ > > > > __ __ > > > > __ __ > > > > =E1=90=A7____ > > > > __ __ > > > > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault > > > > wrote:____ > > > > So, let's adopt a GNAP! We can even come with a > > little mascot (a bit like go gopher) as imagined > > by http://elisegravel.com/blog/adopte-un-gnap/, > > loved by little Canadians :-) ____ > > > > __ __ > > > > Just to be sure, how do you recommand we pronounce > > it? ____ > > > > __ __ > > > > Looking forward to the next steps too.. ____ > > > > __ __ > > > > Thxs____ > > > > Fabien____ > > > > --____ > > > > 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____ > > > > __ __ > > > > __ __ > > > > > > --000000000000f2660d05a8249903 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Vittorio

Thanks for sharing the vid= eo and where the word is pronounced -- guh-nap for those that have not watc= hed it. ( I saw the usage of "gnap" in what Leif shared, but did = not see pronunciation=C2=A0)

Are you concerned wit= h the silent G pronunciation, or just sharing data?

A concern voiced with guh-nap was the association with GNU work.

(I'm hoping to check off this last co-chair item on my= list ... )




3D==E1=90=A7

On Mon, Jun 15, 2020 at 12:25 PM <vittorio.bertocci@auth0.com&g= t; wrote:

Perhaps not to be taken too seriously, but here=E2=80=99s = prior art on GNAP pronunciation.

As= Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the Smurf= s comic and was reprised in a cartoon episode as well.

You=E2=80=99ll find few examples around 3:30=

=C2=A0https://www.y= outube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbclid=3DIwAR0G= VfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ

=C2=A0

From: Txauth <txauth-bounces@i= etf.org> On Behalf Of Dick Hardt
Sent: Monday, June= 15, 2020 12:18 PM
To: Peter Saint-Andre <stpeter@mozilla.com>
Cc:<= /b> Mike Jones <Michael.Jones@microsoft.com>; Jared Jennings <jaredljennings@gmail.co= m>; Amanjeev Sethi <aj@amanjeev.com>; Fabien Imbault <fabien.imbault@gmail.com>; txauth@ietf.org
<= b>Subject: Re: [Txauth] GNAP it is

=C2=A0

Checking in a= gain on pronunciation.

= =C2=A0

Mike: do you still have = concerns with a silent 'G'?

=C2=A0

Anyon= e else have concerns?

=C2=A0

I'd like to nip= pronunciation confusion in the bud by having the recommended pronunciation= =C2=A0in the charter.

=C2=A0

=C2=A0

=E1=90=A7

=C2=A0

On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre <stpeter@mozilla.com> wrote:<= /u>

Looks lik= e we were caught gnapping. ;-)

OK, that's the last of my snarky = comments, let's get to work!

Peter

On 6/7/20 2:09 PM, Dic= k Hardt wrote:
> It is if you are familiar with any of the GNU projec= ts.
>
> https://www.gnu.org/gnu/pronunciation.en.html
= >
> A quick search on the internet has the "normal" pro= nunciation of "gnu"
> to have a silent 'g'.
>=
> = https://www.howtopronounce.com/gnu
> https://dic= tionary.cambridge.org/us/pronunciation/english/gnu
>
> > =E1=90=A7
>= ;
> On Sun, Jun 7, 2020 at 12:51 PM Mike Jones <Michael.Jones@microsoft.com=
> <mailto:Michael.Jones@microsoft.com>> wrote:
>
&g= t;=C2=A0 =C2=A0 =C2=A0I had assumed Guh-Nap =E2=80=93 parallel to the pronu= nciation of GNU.=C2=A0 I
>=C2=A0 =C2=A0 =C2=A0think that=E2=80=99s th= e most natural way to read it.____
>
>=C2=A0 =C2=A0 =C2=A0__= =C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2= =A0 =C2=A0 =C2=A0*From:* Txauth <txauth-bounces@ietf.org
>=C2=A0 =C2=A0 =C2= =A0<mailto:= txauth-bounces@ietf.org>> *On Behalf Of *Dick Hardt
>=C2=A0= =C2=A0 =C2=A0*Sent:* Sunday, June 7, 2020 12:45 PM
>=C2=A0 =C2=A0 = =C2=A0*To:* Amanjeev Sethi <aj@amanjeev.com <mailto:aj@amanjeev.com>>
>=C2=A0 =C2=A0 =C2=A0*C= c:* Fabien Imbault <fabien.imbault@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mai= lto:fabien.im= bault@gmail.com>>; Jared Jennings
>=C2=A0 =C2=A0 =C2=A0<= jaredljenning= s@gmail.com <mailto:jaredljennings@gmail.com>>;
>=C2=A0 =C2=A0 = =C2=A0txauth@ietf.org<= /a> <mailto:txauth@= ietf.org>
>=C2=A0 =C2=A0 =C2=A0*Subject:* Re: [Txauth] GNAP it= is____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2= =A0 =C2=A0 =C2=A0Anyone have objection to the recommended pronunciation=C2= =A0being the
>=C2=A0 =C2=A0 =C2=A0English word "nap", as in= "gnaw"?____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
&g= t;
>=C2=A0 =C2=A0 =C2=A0If not, then we could add a pronunciation=C2= =A0recommendation to the
>=C2=A0 =C2=A0 =C2=A0Charter.____
> >=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0=E1=90=A7____
> >=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0On= Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi <aj@amanjeev.com
>=C2=A0 =C2=A0 =C2=A0&l= t;mailto:aj@amanjeev.c= om>> wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Vote for 'G' silent, as in 'lagnappe' ;)____
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings= wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I vote for G silent. For the reason it's most common to
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pronounce, especially for thos= e not familiar with open
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0source usages.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0On Sat, Jun 6, 2020, 08:45 Dick Hardt <dick.hardt@gmail.com
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dick.hardt@gmail.com>> wro= te:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0The obvious pronunciation choices are:____
>
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
&g= t;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0na= p (silent g as in gnaw)____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0guh-nap (as in the GNU OS
&= gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0h= ttps://www.gnu.org/gnu/pronunciation.en..html
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.gnu.org/gnu/p= ronunciation.en.html>)____
>
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gee-nap (as in G-man - = government man
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0-=C2=A0https://en.wikipedia.org/wiki/G-man)____
>
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E1=90=A7____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020 at 1:34 AM Fab= ien Imbault
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<fab= ien.imbault@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0<mailto:fabien.imbault@gmail.com>> wrote:____
> <= br>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0So, let's adopt a GNAP! We can even come with a
>=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0littl= e mascot (a bit like go gopher) as imagined
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by=C2=A0http://elisegrav= el.com/blog/adopte-un-gnap/,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loved by little Canadians :-)=C2= =A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Just to be sure, how= do you recommand we pronounce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it?=C2=A0____
>
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__= =C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Looking forward to the next steps too..=C2=A0___= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thxs____
>
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Fabien____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--____
>
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list_= ___
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0T= xauth@ietf.org <mailto:Txauth@ietf.org>____
>
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf= .org/mailman/listinfo/txauth____
>
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--____
>
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list____=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Txauth@ietf.org<= /a> <mailto:Txauth@= ietf.org>____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/txauth___= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--=C2= =A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txa= uth mailing list____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Txauth@ietf.= org <mailto:Txa= uth@ietf.org>____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/txauth____
&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
> <= u>

--000000000000f2660d05a8249903-- From nobody Mon Jun 15 12:42:57 2020 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 7EFF93A0D24 for ; Mon, 15 Jun 2020 12:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 ZP3iNyaExn1q for ; Mon, 15 Jun 2020 12:42:53 -0700 (PDT) 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 D31B53A0D22 for ; Mon, 15 Jun 2020 12:42:52 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id e4so20677419ljn.4 for ; Mon, 15 Jun 2020 12:42:52 -0700 (PDT) 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=2i/YE+WzFUPhHt9CRnw5ki2SVXBuMpr5iEr+OuT17EQ=; b=g+F74WxmGthwMdovFrdMeDCGY9qjsh1kzjYYIbU7bHOrQ6D0sRPK7nswor6N6/TTRI TAj/xyQcG1k2Mnm/9wK5iLIuBLSzEikriIKTPhf5Vlycq/xcRUXYNwKEWXyBUj4MB1+K lzzq842fjkR+xjdkOKYlCcDYXoUyzokcZMgfh4mCjs8CWhgPOcSUkrlQze4nBZayau8J 2uRR7odYM9DkjoIMafPB+q/2uSl8ppeJatCmA17n39ppbe/4yGEQwAVufAZLIxQVMR2b 31bhF3ZFD1jme8ht9BeQptmO+DDXjLjjrMBr99E0IiH6axTx7ayHCH46vu7qjwn8dAVj ROVw== 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=2i/YE+WzFUPhHt9CRnw5ki2SVXBuMpr5iEr+OuT17EQ=; b=eX1G29DNIao617PIhaonRQQsmfdxNLka6S8KNH2scM3Mz1E4OCa4d3kIN567Ety1yp XWPVbDA9O34UJj/4sdvtmORPbHKb/62pNxe2L/tEZpUT97Kk3go71pGBBmKLA2SJzTsk 6DsLQuSgsyXPAvmXEVYUyF+t5iea6q5M8Nl69zOSxhHXS9Uc7qaA80IbpD3sH6fPFBM4 Q7rzVZY/jJqGJKE6lb2VFDyWp9mS8yzVswzkLQdHIwZnBXPa6/p71okEGgPEucc0kP8l mfIzIGo/Ew6/7ovjDqi227+vTammbAesGgIPxFsuChFVR+L5QppI+3z3TH41EOfOfE0+ q4FQ== X-Gm-Message-State: AOAM533I4raO9Ialnp1qr7qT8WP9Bkju9XZL9d5pm/zj4KZbP7Ez8Kc+ PyrM7DPfMsWaojK/2RSw6M7vOnOOnl+oYqr1BDQ= X-Google-Smtp-Source: ABdhPJy3n9EriN/c8rwJqFIQGY1S+CT3N+IhNxrZhbRjAmuh/ytxiYMLMU3fPI7Zt2/jEGdt0CDEB/ZsuIwQJ2tBrJI= X-Received: by 2002:a2e:140a:: with SMTP id u10mr13577463ljd.56.1592250170789; Mon, 15 Jun 2020 12:42:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Mon, 15 Jun 2020 12:42:24 -0700 Message-ID: To: Mike Jones Cc: "vittorio.bertocci@auth0.com" , Peter Saint-Andre , Jared Jennings , Amanjeev Sethi , Fabien Imbault , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d2d7d405a824a1d6" Archived-At: Subject: Re: [Txauth] GNAP it is 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, 15 Jun 2020 19:42:55 -0000 --000000000000d2d7d405a824a1d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mike I agree that some people will mispronounce it, but if there is a recommended pronunciation, then there will be consistency amongst those of us that know it rather than inconsistency between us. =E1=90=A7 On Mon, Jun 15, 2020 at 12:38 PM Mike Jones wrote: > I don=E2=80=99t care a lot one way or the other. My main point is that n= o matter > what guidance we give, many people are likely to pronounce the =E2=80=9CG= =E2=80=9D. If we > try to insist on it being silent, we should get used to the fact that we= =E2=80=99ll > probably be hearing both pronunciations. > > > > -- Mike > > > > P.S. Thanks for the Smurfs link, Vittorio! > > > > *From:* vittorio.bertocci@auth0.com > *Sent:* Monday, June 15, 2020 12:25 PM > *To:* 'Dick Hardt' ; 'Peter Saint-Andre' < > stpeter@mozilla.com> > *Cc:* Mike Jones ; 'Jared Jennings' < > jaredljennings@gmail.com>; 'Amanjeev Sethi' ; 'Fabien > Imbault' ; txauth@ietf.org > *Subject:* RE: [Txauth] GNAP it is > > > > Perhaps not to be taken too seriously, but here=E2=80=99s prior art on GN= AP > pronunciation. > > As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the S= murfs comic and > was reprised in a cartoon episode as well. > > You=E2=80=99ll find few examples around 3:30 > > > https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbclid= =3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ > > > > *From:* Txauth *On Behalf Of *Dick Hardt > *Sent:* Monday, June 15, 2020 12:18 PM > *To:* Peter Saint-Andre > *Cc:* Mike Jones ; Jared Jennings < > jaredljennings@gmail.com>; Amanjeev Sethi ; Fabien > Imbault ; txauth@ietf.org > *Subject:* Re: [Txauth] GNAP it is > > > > Checking in again on pronunciation. > > > > Mike: do you still have concerns with a silent 'G'? > > > > Anyone else have concerns? > > > > I'd like to nip pronunciation confusion in the bud by having the > recommended pronunciation in the charter. > > > > > > =E1=90=A7 > > > > On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre > wrote: > > Looks like we were caught gnapping. ;-) > > OK, that's the last of my snarky comments, let's get to work! > > Peter > > On 6/7/20 2:09 PM, Dick Hardt wrote: > > It is if you are familiar with any of the GNU projects. > > > > https://www.gnu.org/gnu/pronunciation.en.html > > > > A quick search on the internet has the "normal" pronunciation of "gnu" > > to have a silent 'g'. > > > > https://www.howtopronounce.com/gnu > > https://dictionary.cambridge.org/us/pronunciation/english/gnu > > > > > > =E1=90=A7 > > > > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones > > wrote: > > > > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of GN= U. I > > think that=E2=80=99s the most natural way to read it.____ > > > > __ __ > > > > -- Mike____ > > > > __ __ > > > > *From:* Txauth > > *On Behalf Of *Dick Hardt > > *Sent:* Sunday, June 7, 2020 12:45 PM > > *To:* Amanjeev Sethi > > > *Cc:* Fabien Imbault > >; Jared Jennings > > >; > > txauth@ietf.org > > *Subject:* Re: [Txauth] GNAP it is____ > > > > __ __ > > > > Anyone have objection to the recommended pronunciation being the > > English word "nap", as in "gnaw"?____ > > > > __ __ > > > > If not, then we could add a pronunciation recommendation to the > > Charter.____ > > > > __ __ > > > > =E1=90=A7____ > > > > __ __ > > > > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi > > wrote:____ > > > > Vote for 'G' silent, as in 'lagnappe' ;)____ > > > > __ __ > > > > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____ > > > > I vote for G silent. For the reason it's most common to > > pronounce, especially for those not familiar with open > > source usages.____ > > > > __ __ > > > > On Sat, Jun 6, 2020, 08:45 Dick Hardt > > wrote:____ > > > > The obvious pronunciation choices are:____ > > > > __ __ > > > > nap (silent g as in gnaw)____ > > > > __ __ > > > > guh-nap (as in the GNU OS > > - https://www.gnu.org/gnu/pronunciation.en..html > > )____ > > > > __ __ > > > > gee-nap (as in G-man - government man > > - https://en.wikipedia.org/wiki/G-man)____ > > > > __ __ > > > > __ __ > > > > __ __ > > > > =E1=90=A7____ > > > > __ __ > > > > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault > > > > wrote:____ > > > > So, let's adopt a GNAP! We can even come with a > > little mascot (a bit like go gopher) as imagined > > by http://elisegravel.com/blog/adopte-un-gnap/, > > loved by little Canadians :-) ____ > > > > __ __ > > > > Just to be sure, how do you recommand we pronounce > > it? ____ > > > > __ __ > > > > Looking forward to the next steps too.. ____ > > > > __ __ > > > > Thxs____ > > > > Fabien____ > > > > --____ > > > > 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____ > > > > __ __ > > > > __ __ > > > > > > --000000000000d2d7d405a824a1d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mike

I agree that some people will m= ispronounce it, but if there is a recommended pronunciation, then there wil= l be consistency amongst those of us that know it rather than inconsistency= between us.




=3D""=E1=90=A7

On Mon, Jun 15, 2020 at 12:38 PM Mike J= ones <Michael.Jones@micro= soft.com> wrote:

I don=E2=80=99t c= are a lot one way or the other.=C2=A0 My main point is that no matter what = guidance we give, many people are likely to pronounce the =E2=80=9CG=E2=80= =9D.=C2=A0 If we try to insist on it being silent, we should get used to th= e fact that we=E2=80=99ll probably be hearing both pronunciations.=

=C2=A0<= /u>

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

=C2=A0<= /u>

P.S.=C2=A0 Thanks= for the Smurfs link, Vittorio!

=C2=A0<= /u>

From: vittorio.bertocci@auth0.com <vittorio.bertocci@auth0= .com>
Sent: Monday, June 15, 2020 12:25 PM
To: 'Dick Hardt' <dick.hardt@gmail.com>; 'Peter Saint-Andre'= ; <stpeter@mozi= lla.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; 'Jared Jennings= 9; <jaredl= jennings@gmail.com>; 'Amanjeev Sethi' <aj@amanjeev.com>; 'Fabien Imb= ault' <fabien.imbault@gmail.com>; txauth@ietf.org
Subject: RE: [Txauth] GNAP it is

=C2=A0

Perhaps not to be taken too seriously, but here=E2= =80=99s prior art on GNAP pronunciation.

As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80= =9D appeared on the Smurfs comic and was reprised in a cartoon episode as w= ell.

You=E2=80=99ll find few examples around 3:30<= u>

=C2=A0https://www.youtube.co= m/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbclid=3DIwAR0GVfFeNl4M1= OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ

=C2=A0

From: Txauth <txauth-bounces@ietf.org> On Behalf Of Dick Hardt
Sent: Monday, June 15, 2020 12:18 PM
To: Peter Saint-Andre <stpeter@mozilla.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; Jared Jennings <jaredljennings@g= mail.com>; Amanjeev Sethi <aj@amanjeev.com>; Fabien Imbault <fabien.imbault@gmail.com>; txauth@ietf.org Subject: Re: [Txauth] GNAP it is

=C2=A0

Checking in again on pronunciation.

=C2=A0

Mike: do you still have concerns with a silent '= G'?

=C2=A0

Anyone else have concerns?

=C2=A0

I'd like to nip pronunciation confusion in the b= ud by having the recommended pronunciation=C2=A0in the charter.

=C2=A0

=C2=A0

=E1=90=A7

=C2=A0

On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre <= ;stpeter@mozilla.c= om> wrote:

Looks like we were caught gnapping. ;-)

OK, that's the last of my snarky comments, let's get to work!

Peter

On 6/7/20 2:09 PM, Dick Hardt wrote:
> It is if you are familiar with any of the GNU projects.
>
> https://www.gnu.org/gnu/pronunciation.en.html
>
> A quick search on the internet has the "normal" pronunciatio= n of "gnu"
> to have a silent 'g'.
>
> https= ://www.howtopronounce.com/gnu
> https://dictionary.cambridge.org/us/pronunciation/english/gnu
>
>
> =E1=90=A7
>
> On Sun, Jun 7, 2020 at 12:51 PM Mike Jones <Michael.Jones@microsoft.com > <mailto:Michael.Jones@microsoft.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I had assumed Guh-Nap =E2=80=93 parallel to the pro= nunciation of GNU.=C2=A0 I
>=C2=A0 =C2=A0 =C2=A0think that=E2=80=99s the most natural way to read i= t.____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0*From:* Txauth <txauth-bounces@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:txauth-bounces@ietf.org>> *On Behalf Of *Dic= k Hardt
>=C2=A0 =C2=A0 =C2=A0*Sent:* Sunday, June 7, 2020 12:45 PM
>=C2=A0 =C2=A0 =C2=A0*To:* Amanjeev Sethi <aj@amanjeev.com <mailto:aj@amanjeev.com>>
>=C2=A0 =C2=A0 =C2=A0*Cc:* Fabien Imbault <fabien.imbault@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:fabien.imbault@gmail.com>>; Jared Jennings<= br> >=C2=A0 =C2=A0 =C2=A0<jaredljennings@gmail.com <mailto:jaredljennings@gmail.com>&= gt;;
>=C2=A0 =C2=A0 =C2=A0txauth@ietf.org <mailto:txauth@ietf.org>
>=C2=A0 =C2=A0 =C2=A0*Subject:* Re: [Txauth] GNAP it is____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0Anyone have objection to the recommended pronunciat= ion=C2=A0being the
>=C2=A0 =C2=A0 =C2=A0English word "nap", as in "gnaw"= ;?____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0If not, then we could add a pronunciation=C2=A0reco= mmendation to the
>=C2=A0 =C2=A0 =C2=A0Charter.____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0=E1= =90=A7____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi <<= a href=3D"mailto:aj@amanjeev.com" target=3D"_blank">aj@amanjeev.com
>=C2=A0 =C2=A0 =C2=A0<mailto:aj@amanjeev.com>> wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vote for 'G' silent, as in &#= 39;lagnappe' ;)____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020, at 10:52 AM, Jar= ed Jennings wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I vote for G silent. Fo= r the reason it's most common to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pronounce, especially f= or those not familiar with open
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0source usages.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020, 08= :45 Dick Hardt <dick.hardt@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dick.hardt@gmail.com>&= gt; wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The obvio= us pronunciation choices are:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nap (sile= nt g as in gnaw)____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0guh-nap (= as in the GNU OS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0= https://www.gnu.org/gnu/pronunciation.en..html
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http= s://www.gnu.org/gnu/pronunciation.en.html>)____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gee-nap (= as in G-man - government man
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0https:= //en.wikipedia.org/wiki/G-man)____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E1=90=A7____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, J= un 6, 2020 at 1:34 AM Fabien Imbault
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<fabien.imbault@gma= il.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailt= o:fabien.imba= ult@gmail.com>> wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0So, let's adopt a GNAP! We can even come with a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0little mascot (a bit like go gopher) as imagined
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0by=C2=A0http://elisegravel.com/blog/adopte-un-gnap/,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0loved by little Canadians :-)=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Just to be sure, how do you recommand we pronounce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0it?=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Looking forward to the next steps too..=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Thxs____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Fabien____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0--____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Txauth mailing list____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Txauth@ietf.org<= /a> <mailto:Txauth@= ietf.org>____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0https://www.ietf.org/mailman/listinfo/txauth____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--____ >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth ma= iling list____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth@ietf.org <mailt= o:Txauth@ietf.org&= gt;____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://www.ietf.org/mailman/listinfo/txauth____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--=C2=A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list____=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth@ietf.org <mailto:Txauth@ietf.org>____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.or= g/mailman/listinfo/txauth____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>

--000000000000d2d7d405a824a1d6-- From nobody Mon Jun 15 12:46:09 2020 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 5F1A13A0B00 for ; Mon, 15 Jun 2020 12:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=sunet.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foFf4t95Rwez for ; Mon, 15 Jun 2020 12:46:06 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86883A0A7D for ; Mon, 15 Jun 2020 12:46:05 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id 9so20638514ljv.5 for ; Mon, 15 Jun 2020 12:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=subject:to:references:from:autocrypt:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=h7DBPIkqR2GTx4nlz5EUfZwMknoBBVjxiOd8X0+TWWQ=; b=bxRQTor4bwfEy3LFKVh4j3YYFyUgCHSvvkvuEOdS8uScZfsjxsIp6Fa2+LZY+qBbQU R9RvutJ2AxfdmfsYi2b+v8AOfvG1DuOLrZtXJaViAAEWJRmgwDI7oK8yAmFSvE4g9v4C peubZDCzk+V3zFEs3JQ1dLn8fr+wInhWM5TVr7TeSwYM3pi6PgkBBqCwR7EU4MSVGLba X3uNm/44Za5HJMnR2tFnBVob+M4GVwJTc54Ox8qPod4BoM2S+a9whF1wript9y9mzlzU RcRsCwF+ADcR9BQfVEONnTv8yDNnmSn7zDPMQ1xQr/yVfre4J/9fyX/CT0jCacwRc4Q5 Hsvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:autocrypt:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=h7DBPIkqR2GTx4nlz5EUfZwMknoBBVjxiOd8X0+TWWQ=; b=mums11j1jmCsdTu7rTCS7hroxhkueRsKlrLnYMARW+2J1MkOQsSkDpe6hzFeWMd0yp QKxzpcAZFTcT1MSDLr9Ox8uv3PzClx6JQwED9TWSsPIy70PgrB1glnJyob0IvYHCsS5Y w4moZfVlo5xlDq+4uG8RA+pcRKpcwXcutz00kztMG7ceID35SjTBpvkEmszwmKj/I9LB 2PQXmqg8Qk8KPoP7Xm6bPwlThIpHCN8rAuCFZr8Wc3FE6r+Dby0NFILpYUdwZFRn3O5x I3Ap/BK7xIkOvRwY6CkUXeaRyHL6qPjlOxa2mtM7gbbRerMZWpC3ocfn/JabiVx3LU/W bWSg== X-Gm-Message-State: AOAM533OmXs5rQiaan4tvPTKn5w0vkoPBLWHLk6/C9BG/nhMO5iQYAuA AplsfkZDIoS3/w8BngI2dN/qPBjOV73VzQ== X-Google-Smtp-Source: ABdhPJxDXIDOOZ1paWAvmWCWUFNsJcSAWkZ8SNJfJRkpfyRSqewRNqGjRD3s84RECEUmDY5hW5wI8w== X-Received: by 2002:a2e:b53b:: with SMTP id z27mr14036130ljm.173.1592250363219; Mon, 15 Jun 2020 12:46:03 -0700 (PDT) Received: from [10.0.0.129] (h-158-174-22-10.NA.cust.bahnhof.se. [158.174.22.10]) by smtp.gmail.com with ESMTPSA id 144sm2113871lfm.87.2020.06.15.12.46.02 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jun 2020 12:46:02 -0700 (PDT) To: txauth@ietf.org References: From: Leif Johansson Autocrypt: addr=leifj@sunet.se; prefer-encrypt=mutual; keydata= xsBNBFJK9qIBCACypED81H1N4YmhMJrb4uOtTDzo+lFZDVVOcK11+NhTFl+AZZFnWH/7UPn+ q5ZZBd/IhONfb5QGw5FzTyBWHsbAteXgCvHAIyumwhQzhZnow6myyC6/MwDhomT5rb3MkCKC yQMNfj/yMgL6ZRsXVhlGOLMmOekRfKe2wiC5BhRaQQwPZPwgFS5D0Tro8Xfxjk98u8rNpQXi 9walRAffRY+byhkPiBj0sVA2RXK9Dx2DL3EY0xx07r6Qhs2XkbXNDDCHRuChhHSHwWC16VS9 x7Nhfg2EwKqmMGRNREikjwzDl/aHKz+FXTLONdmc83sRyklqgH90f3na6s/RT5XTb08xABEB AAHNHUxlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U+wsB+BBMBCAAoAhsDBgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCW7Yg8gUJDw7ExQAKCRDXOtZDCtR41io7CACOVmQcjoS7cfuF 43NhvpfFjSn91qShubrWx/p0+v/1MRyGajeMKcBd9HPDsN/lhMuY6k2zI1Qsrsycv51QQ+d0 +lPFxO3LKcrzaKqfKV3UZP3eVsMQgyP21iFIFAw424aAeBjWRhhnzlvsiP3RzF4NNb7goMWR PLWlld4M+MGqlM+T8M2Jbxl2OejedK5HCGm00IzXS7NojDGdIiXHbx0S0RloNb7ssQdFdHAH M6hO30lCwTM5jnNbejXhFUlMqYdRjWPUAbFwX3Pw9Wpkr5xz5xYbx8xPZBIG6ROp8ExxP31V NTm+DTnwJS5LLMbV1aDLYIzYlEossP2NFhLtwVDEzsBNBFJK9qIBCAC+k1tFOeDS4gMxEgRk fiVLHFemwJWQiGZHYhtDgjh6w6mB8G3WZ+/gD2CMp5DgHFRC1sW2iMj3gOzrfyxzd9AmWbhX YceR6EFkTc6OVsaIb+eHH/Zo3DKyB1Dq9CA5fjjnEQzti+KKSZYWzB0Fkt7qrfOS6YM1zMjE UxUUwsl1qirx5DuByWLDX7ULU7H/xmPVhHUVZO8XEaFV2m+ICx8Y6B98KMeJ0Qz8b8wp2g7v WEkwS2R6IjF0kMrRxnxUvwA6EUiZuFphhuY/lWCJusLl1olgOE+BKMEUStJWEi0s+pd8FL1v OLeNKbIUFro0+oZr9byABpkPNjMxKV36uj1dABEBAAHCwGUEGAEIAA8CGwwFAlu2H5wFCQ8O w3cACgkQ1zrWQwrUeNbSVAgAmRS6XxztiU9pczUwElOnolmnAIUocSXdfllZABxLX1MkZ4Yn 0jEbJKMpPOAMu7cQs4gni/AprnMae23taqJprwWCE6lTcOEhdPNKSFhdL4eE+UCd9Z9S/8PC M0GkjDF9FAWcrIBmySiHmZfAwKbHk3+AhDmY2PzN+mOzgU7t855+OtcoI02PDEXJGTCU9Mcl YtMNAlrmMmbMUApLSIoFluY35nlBVDFD3bDuCb59Nbs9aBJ9bu956G04XUcYt9sTsnkPppzX 82jyCc6Oeg9He8F1ep7AEoscflUKuwn9YF/sblqq27GO4d/BQPtaNw0iGz1H1C1QWKES4tk4 bZRWFA== Message-ID: <47826e44-e512-950f-6e80-f4b20902c6d5@sunet.se> Date: Mon, 15 Jun 2020 21:46:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Txauth] WG chair changes -- thank you Dick, welcome Leif 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, 15 Jun 2020 19:46:08 -0000 On 2020-06-15 21:21, Roman Danyliw wrote: > Hi! > > With the GNAP charter now in IESG review (scheduled for the June 25 telechat), we enter a difference phase of work. At this natural transition, the chairs of GNAP will also change. > > Yaron has graciously agreed to continue on as co-chair. Thank you! > > Dick will step down to focus his attention on the GNAP specifications. (With Yaron), Dick led us through multiple BoFs, charter refinements and key scoping activities that allowed us to get to this point -- from mailing list to BoF to "almost a WG". Please join me in thanking Dick for his leadership. Luckily for all of us, despite this change, he will still be quite involved in the work. > > Finally, I am pleased to announce that Leif Johansson will be stepping in as the new co-chair. Leif brings both domain and prior WG leadership experience. Please join me in welcoming Leif to this role. > > Regards, > Roman > Thank you Roman. This marks the conclusion of the preparatory work in GNAP. Our goal now is to come up with a set of specifications. MVH leifj From nobody Mon Jun 15 12:54:40 2020 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 DDEA73A0D37 for ; Mon, 15 Jun 2020 12:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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=auth0.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 O7w-Olxt7-5f for ; Mon, 15 Jun 2020 12:54:37 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B9D3A0D35 for ; Mon, 15 Jun 2020 12:54:37 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id i27so20655984ljb.12 for ; Mon, 15 Jun 2020 12:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=cWmV1VNSf2osrfJUfEBgZVlvPjx8zQyWOJ0E15Lu5wE=; b=Rrv+BOyLSitNLk0DkuPZ0eAsOwRDQhP1L7QlVA8Rb/E8+dy7DBHAoxSX5rGLgx+LON AvPW6nAwpPDV4du6oioATGnTh726Lmk8+5dF27IIurWQYwnpTg77kyF9qVSAPQFc2KRq 1Wo7gbL+SY/rt67S+EMpz+ELGChVCqMRoKAsQC60FpWzBtLFSajZhHZVZIrsh1VTUU6h 9tP7GipS/7ayb/owAaFa2BlP0pMBUtoSPSkvMv644S9PcpuL4xA+yNsoA42AcY5B3/Mi vFHEGhk3jsplab1Fb1xRVrvo3T7nyvsJdkBfepk4pFTuxQ0nHH23FleNIx/fY529pWp9 UYsg== 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:reply-to :from:date:message-id:subject:to:cc; bh=cWmV1VNSf2osrfJUfEBgZVlvPjx8zQyWOJ0E15Lu5wE=; b=HB3wQXxbejnQsQbDuRAK9ijPWoh/uTB7CoHceHQta4EXpSt2xnL9hEv5I9pD/yq93J QfjUR+lSYry8Awa/rRoIu05XxyJvDleoDg0pkMmdGTarOrIkPDcrALctjxaUEsZhv3W6 kSz6f7QgariTHkTBSD4iyPcxIgq0hSUSPn4C96m14MIczwh6RHdcj3XV9MoZ+i1knHzI jqS4jci3Fpjd2z2tO6V8gGQLC10auePugElxZWrwmjckt/QEVRM/zycVNPW1HxxUf1k4 3/s4AGyO8w2dohN6+RGFjOqtRufpCufSos+Y4KNN38C3ZQYTr1JHB8SN8yisPobcRZby qKfw== X-Gm-Message-State: AOAM533fXMzUi6i9H4Yc5W8FFHOVV4rgnOvGabIKOLUsiUt+t28OuSdm ++WTqaTV21Oc/1wM5468Vd6T82TgkHZiFKYqtG538w== X-Google-Smtp-Source: ABdhPJwrn4m2MWDsZBRtso05x+zNRARP9X3wTtCAZECroMVhgyQElFvPYEn3raJWpPBQ4QBpNw9ScOIrhUf7AAo0L3s= X-Received: by 2002:a2e:b4eb:: with SMTP id s11mr12470612ljm.452.1592250875137; Mon, 15 Jun 2020 12:54:35 -0700 (PDT) MIME-Version: 1.0 References: <8db677bd-d054-136f-fbad-cae55237f7a8@mozilla.com> <019d01d6434a$af721ae0$0e5650a0$@auth0.com> In-Reply-To: Reply-To: Vittorio@auth0.com From: Vittorio Bertocci Date: Mon, 15 Jun 2020 12:54:22 -0700 Message-ID: To: Dick Hardt Cc: Amanjeev Sethi , Fabien Imbault , Jared Jennings , Leif Johansson , Mike Jones , Peter Saint-Andre , txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000ce608b05a824cbc8" Archived-At: Subject: Re: [Txauth] GNAP it is 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, 15 Jun 2020 19:54:40 -0000 --000000000000ce608b05a824cbc8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have no concerns, sorry for not having been clear on that. I was just sharing data. Any pronunciation works for me. On Mon, Jun 15, 2020 at 12:40 Dick Hardt wrote: > Hey Vittorio > > Thanks for sharing the video and where the word is pronounced -- guh-nap > for those that have not watched it. ( I saw the usage of "gnap" in what > Leif shared, but did not see pronunciation ) > > Are you concerned with the silent G pronunciation, or just sharing data? > > A concern voiced with guh-nap was the association with GNU work. > > (I'm hoping to check off this last co-chair item on my list ... ) > > > > > =E1=90=A7 > > On Mon, Jun 15, 2020 at 12:25 PM wrote: > >> Perhaps not to be taken too seriously, but here=E2=80=99s prior art on G= NAP >> pronunciation. >> >> As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the = Smurfs comic and >> was reprised in a cartoon episode as well. >> >> You=E2=80=99ll find few examples around 3:30 >> >> >> https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbclid= =3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ >> >> >> >> *From:* Txauth *On Behalf Of *Dick Hardt >> *Sent:* Monday, June 15, 2020 12:18 PM >> *To:* Peter Saint-Andre >> *Cc:* Mike Jones ; Jared Jennings < >> jaredljennings@gmail.com>; Amanjeev Sethi ; Fabien >> Imbault ; txauth@ietf.org >> *Subject:* Re: [Txauth] GNAP it is >> >> >> >> Checking in again on pronunciation. >> >> >> >> Mike: do you still have concerns with a silent 'G'? >> >> >> >> Anyone else have concerns? >> >> >> >> I'd like to nip pronunciation confusion in the bud by having the >> recommended pronunciation in the charter. >> >> >> >> >> >> =E1=90=A7 >> >> >> >> On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre >> wrote: >> >> Looks like we were caught gnapping. ;-) >> >> OK, that's the last of my snarky comments, let's get to work! >> >> Peter >> >> On 6/7/20 2:09 PM, Dick Hardt wrote: >> > It is if you are familiar with any of the GNU projects. >> > >> > https://www.gnu.org/gnu/pronunciation.en.html >> > >> > A quick search on the internet has the "normal" pronunciation of "gnu" >> > to have a silent 'g'. >> > >> > https://www.howtopronounce.com/gnu >> > https://dictionary.cambridge.org/us/pronunciation/english/gnu >> > >> > >> > =E1=90=A7 >> > >> > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones > > > wrote: >> > >> > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of G= NU. I >> > think that=E2=80=99s the most natural way to read it.____ >> > >> > __ __ >> > >> > -- Mike____ >> > >> > __ __ >> > >> > *From:* Txauth > > > *On Behalf Of *Dick Hardt >> > *Sent:* Sunday, June 7, 2020 12:45 PM >> > *To:* Amanjeev Sethi > >> > *Cc:* Fabien Imbault > > >; Jared Jennings >> > >; >> > txauth@ietf.org >> > *Subject:* Re: [Txauth] GNAP it is____ >> > >> > __ __ >> > >> > Anyone have objection to the recommended pronunciation being the >> > English word "nap", as in "gnaw"?____ >> > >> > __ __ >> > >> > If not, then we could add a pronunciation recommendation to the >> > Charter.____ >> > >> > __ __ >> > >> > =E1=90=A7____ >> > >> > __ __ >> > >> > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi > > > wrote:____ >> > >> > Vote for 'G' silent, as in 'lagnappe' ;)____ >> > >> > __ __ >> > >> > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____ >> > >> > I vote for G silent. For the reason it's most common to >> > pronounce, especially for those not familiar with open >> > source usages.____ >> > >> > __ __ >> > >> > On Sat, Jun 6, 2020, 08:45 Dick Hardt > > > wrote:____ >> > >> > The obvious pronunciation choices are:____ >> > >> > __ __ >> > >> > nap (silent g as in gnaw)____ >> > >> > __ __ >> > >> > guh-nap (as in the GNU OS >> > - https://www.gnu.org/gnu/pronunciation.en..html >> > )____ >> > >> > __ __ >> > >> > gee-nap (as in G-man - government man >> > - https://en.wikipedia.org/wiki/G-man)____ >> > >> > __ __ >> > >> > __ __ >> > >> > __ __ >> > >> > =E1=90=A7____ >> > >> > __ __ >> > >> > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault >> > > > > wrote:____ >> > >> > So, let's adopt a GNAP! We can even come with a >> > little mascot (a bit like go gopher) as imagined >> > by http://elisegravel.com/blog/adopte-un-gnap/, >> > loved by little Canadians :-) ____ >> > >> > __ __ >> > >> > Just to be sure, how do you recommand we pronounce >> > it? ____ >> > >> > __ __ >> > >> > Looking forward to the next steps too.. ____ >> > >> > __ __ >> > >> > Thxs____ >> > >> > Fabien____ >> > >> > --____ >> > >> > 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____ >> > >> > __ __ >> > >> > __ __ >> > >> > >> >> --000000000000ce608b05a824cbc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have no concerns, sorry for not having been clear = on that. I was just sharing data. Any pronunciation works for me.=C2=A0

On Mon, Jun 15, 2020 at 12:40 Dick Hardt <dick.hardt@gmail.com> wrote:
Hey Vittorio

Thanks f= or sharing the video and where the word is pronounced -- guh-nap for those = that have not watched it. ( I saw the usage of "gnap" in what Lei= f shared, but did not see pronunciation=C2=A0)

Are= you concerned with the silent G pronunciation, or just sharing data?
=

A concern voiced with guh-nap was the association with = GNU work.

(I'm hoping to check off this last c= o-chair item on my list ... )



<= /div>

3D""= =E1=90=A7

On Mon, Jun 15, 2020 at = 12:25 PM <vittorio.bertocci@auth0.com> wrote:

Perhaps not to be taken too seriously, but here=E2=80=99s prior art on G= NAP pronunciation.

As Leif mentione= d few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the Smurfs comic and wa= s reprised in a cartoon episode as well.

You=E2=80=99ll find few examples around 3:30

=C2=A0https://www.youtube.com/wat= ch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbclid=3DIwAR0GVfFeNl4M1OhHKE= 7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ

=C2=A0

From: Txauth <txauth-bounces@ietf.org>= ; On Behalf Of Dick Hardt
Sent: Monday, June 15, 2020 12:1= 8 PM
To: Peter Saint-Andre <stpeter@mozilla.com>
Cc: Mike Jones= <Micha= el.Jones@microsoft.com>; Jared Jennings <jaredljennings@gmail.com>; Ama= njeev Sethi <aj@ama= njeev.com>; Fabien Imbault <fabien.imbault@gmail.com>; txauth@ietf.org
Subject:= Re: [Txauth] GNAP it is

<= /u>=C2=A0

Checking in again on pronun= ciation.

=C2=A0<= /p>

Mike: do you still have concerns with = a silent 'G'?

=C2=A0

Anyone else have co= ncerns?

=C2=A0=

I'd like to nip pronunciation= confusion in the bud by having the recommended pronunciation=C2=A0in the c= harter.

=C2=A0=

=C2=A0

=E1=90=A7

=C2=A0

On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre <stpeter@mozilla.com> wrote:=

Looks= like we were caught gnapping. ;-)

OK, that's the last of my sna= rky comments, let's get to work!

Peter

On 6/7/20 2:09 PM,= Dick Hardt wrote:
> It is if you are familiar with any of the GNU pr= ojects.
>
> https://www.gnu.org/gnu/pronunciation.en.html=
>
> A quick search on the internet has the "normal"= pronunciation of "gnu"
> to have a silent 'g'.
= >
> https://www.howtopronounce.com/gnu
> https:/= /dictionary.cambridge.org/us/pronunciation/english/gnu
>
>=
> =E1=90=A7>
> On Sun, Jun 7, 2020 at 12:51 PM Mike Jones <Michael.Jones@microsoft= .com
> <mailto:Michael.Jones@microsoft.com>> wrote:
> >=C2=A0 =C2=A0 =C2=A0I had assumed Guh-Nap =E2=80=93 parallel to the p= ronunciation of GNU.=C2=A0 I
>=C2=A0 =C2=A0 =C2=A0think that=E2=80=99= s the most natural way to read it.____
>
>=C2=A0 =C2=A0 =C2=A0= __=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --= Mike____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>= =C2=A0 =C2=A0 =C2=A0*From:* Txauth <txauth-bounces@ietf.org
>=C2=A0 =C2=A0 = =C2=A0<mailto:txauth-bounces@ietf.org>> *On Behalf Of *Dick Hardt
>=C2= =A0 =C2=A0 =C2=A0*Sent:* Sunday, June 7, 2020 12:45 PM
>=C2=A0 =C2=A0= =C2=A0*To:* Amanjeev Sethi <aj@amanjeev.com <mailto:aj@amanjeev.com>>
>=C2=A0 =C2=A0 =C2= =A0*Cc:* Fabien Imbault <fabien.imbault@gmail.com
>=C2=A0 =C2=A0 =C2=A0<= mailto:fabien= .imbault@gmail.com>>; Jared Jennings
>=C2=A0 =C2=A0 =C2=A0&= lt;jaredljenn= ings@gmail.com <mailto:jaredljennings@gmail.com>>;
>=C2=A0 =C2=A0= =C2=A0txauth@ietf.org= <mailto:txauth= @ietf.org>
>=C2=A0 =C2=A0 =C2=A0*Subject:* Re: [Txauth] GNAP i= t is____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2= =A0 =C2=A0 =C2=A0Anyone have objection to the recommended pronunciation=C2= =A0being the
>=C2=A0 =C2=A0 =C2=A0English word "nap", as in= "gnaw"?____
>
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
&g= t;
>=C2=A0 =C2=A0 =C2=A0If not, then we could add a pronunciation=C2= =A0recommendation to the
>=C2=A0 =C2=A0 =C2=A0Charter.____
> >=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0=E1=90=A7____
> >=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0On= Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi <aj@amanjeev.com
>=C2=A0 =C2=A0 =C2=A0&l= t;mailto:aj@amanjeev.c= om>> wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Vote for 'G' silent, as in 'lagnappe' ;)____
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings= wrote:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0I vote for G silent. For the reason it's most common to
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pronounce, especially for thos= e not familiar with open
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0source usages.____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0On Sat, Jun 6, 2020, 08:45 Dick Hardt <dick.hardt@gmail.com
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dick.hardt@gmail.com>> wro= te:____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0The obvious pronunciation choices are:____
>
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
&g= t;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0na= p (silent g as in gnaw)____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0guh-nap (as in the GNU OS
&= gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0h= ttps://www.gnu.org/gnu/pronunciation.en..html
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.gnu.org/gnu/p= ronunciation.en.html>)____
>
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gee-nap (as in G-man - = government man
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0-=C2=A0https://en.wikipedia.org/wiki/G-man)____
>
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E1=90=A7____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020 at 1:34 AM Fab= ien Imbault
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<fab= ien.imbault@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0<mailto:fabien.imbault@gmail.com>> wrote:____
> <= br>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0So, let's adopt a GNAP! We can even come with a
>=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0littl= e mascot (a bit like go gopher) as imagined
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by=C2=A0http://elisegrav= el.com/blog/adopte-un-gnap/,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loved by little Canadians :-)=C2= =A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Just to be sure, how= do you recommand we pronounce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it?=C2=A0____
>
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__= =C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Looking forward to the next steps too..=C2=A0___= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thxs____
>
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Fabien____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--____
>
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list_= ___
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0T= xauth@ietf.org <mailto:Txauth@ietf.org>____
>
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf= .org/mailman/listinfo/txauth____
>
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--____
>
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list____=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Txauth@ietf.org<= /a> <mailto:Txauth@= ietf.org>____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/txauth___= _
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--=C2= =A0____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txa= uth mailing list____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Txauth@ietf.= org <mailto:Txa= uth@ietf.org>____
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/txauth____
&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>
> <= u>

--000000000000ce608b05a824cbc8-- From nobody Mon Jun 15 13:56:59 2020 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 AF28B3A0F33 for ; Mon, 15 Jun 2020 13:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 iDETUdW2VXKU for ; Mon, 15 Jun 2020 13:56:55 -0700 (PDT) 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 4E0C03A0F32 for ; Mon, 15 Jun 2020 13:56:55 -0700 (PDT) Received: from [192.168.1.14] (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 05FKul4l030784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Jun 2020 16:56:48 -0400 From: Justin Richer Message-Id: <5443710B-05DB-4C4D-AC4B-0D8D173E131B@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_863B57DC-5C8B-4749-AC30-1CEE9C86C642" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 15 Jun 2020 16:56:47 -0400 In-Reply-To: Cc: "vittorio.bertocci@auth0.com" , Dick Hardt , Peter Saint-Andre , Fabien Imbault , Jared Jennings , Amanjeev Sethi , "txauth@ietf.org" To: Mike Jones References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] GNAP it is 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, 15 Jun 2020 20:56:58 -0000 --Apple-Mail=_863B57DC-5C8B-4749-AC30-1CEE9C86C642 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Mike, in that we should get used to answering to both. In my head, it reads with a hard =E2=80=9CG=E2=80=9D, at least partially = because of the Smurfs video=E2=80=99s legacy. =E2=80=94 Justin > On Jun 15, 2020, at 3:38 PM, Mike Jones = wrote: >=20 > I don=E2=80=99t care a lot one way or the other. My main point is = that no matter what guidance we give, many people are likely to = pronounce the =E2=80=9CG=E2=80=9D. If we try to insist on it being = silent, we should get used to the fact that we=E2=80=99ll probably be = hearing both pronunciations. > =20 > -- Mike > =20 > P.S. Thanks for the Smurfs link, Vittorio! > =20 > From: vittorio.bertocci@auth0.com = >=20 > Sent: Monday, June 15, 2020 12:25 PM > To: 'Dick Hardt' >; = 'Peter Saint-Andre' > > Cc: Mike Jones >; 'Jared Jennings' = >; 'Amanjeev = Sethi' >; 'Fabien Imbault' = >; = txauth@ietf.org > Subject: RE: [Txauth] GNAP it is > =20 > Perhaps not to be taken too seriously, but here=E2=80=99s prior art on = GNAP pronunciation. > As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on = the Smurfs comic and was reprised in a cartoon episode as well. > You=E2=80=99ll find few examples around 3:30 > = https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbclid=3D= IwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ = > =20 > From: Txauth > On Behalf Of Dick Hardt > Sent: Monday, June 15, 2020 12:18 PM > To: Peter Saint-Andre > > Cc: Mike Jones >; Jared Jennings = >; Amanjeev = Sethi >; Fabien Imbault = >; = txauth@ietf.org > Subject: Re: [Txauth] GNAP it is > =20 > Checking in again on pronunciation. > =20 > Mike: do you still have concerns with a silent 'G'? > =20 > Anyone else have concerns? > =20 > I'd like to nip pronunciation confusion in the bud by having the = recommended pronunciation in the charter. > =20 > =20 > =E1=90=A7 > =20 > On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre > wrote: > Looks like we were caught gnapping. ;-) >=20 > OK, that's the last of my snarky comments, let's get to work! >=20 > Peter >=20 > On 6/7/20 2:09 PM, Dick Hardt wrote: > > It is if you are familiar with any of the GNU projects. > >=20 > > https://www.gnu.org/gnu/pronunciation.en.html = > >=20 > > A quick search on the internet has the "normal" pronunciation of = "gnu" > > to have a silent 'g'. > >=20 > > https://www.howtopronounce.com/gnu = > > https://dictionary.cambridge.org/us/pronunciation/english/gnu = > >=20 > >=20 > > =E1=90=A7 > >=20 > > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones = > > >> wrote: > >=20 > > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of = GNU. I > > think that=E2=80=99s the most natural way to read it.____ > >=20 > > __ __ > >=20 > > -- = Mike____ > >=20 > > __ __ > >=20 > > *From:* Txauth > > >> *On Behalf Of *Dick Hardt > > *Sent:* Sunday, June 7, 2020 12:45 PM > > *To:* Amanjeev Sethi = >> > > *Cc:* Fabien Imbault > > >>; Jared Jennings > > = >>; > > txauth@ietf.org > > > *Subject:* Re: [Txauth] GNAP it is____ > >=20 > > __ __ > >=20 > > Anyone have objection to the recommended pronunciation being the > > English word "nap", as in "gnaw"?____ > >=20 > > __ __ > >=20 > > If not, then we could add a pronunciation recommendation to the > > Charter.____ > >=20 > > __ __ > >=20 > > =E1=90=A7____ > >=20 > > __ __ > >=20 > > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi > > >> wrote:____ > >=20 > > Vote for 'G' silent, as in 'lagnappe' ;)____ > >=20 > > __ __ > >=20 > > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____ > >=20 > > I vote for G silent. For the reason it's most common to > > pronounce, especially for those not familiar with open > > source usages.____ > >=20 > > __ __ > >=20 > > On Sat, Jun 6, 2020, 08:45 Dick Hardt = > > >> wrote:____ > >=20 > > The obvious pronunciation choices are:____ > >=20 > > __ __ > >=20 > > nap (silent g as in gnaw)____ > >=20 > > __ __ > >=20 > > guh-nap (as in the GNU OS > > - https://www.gnu.org/gnu/pronunciation.en..html = > > >)____ > >=20 > > __ __ > >=20 > > gee-nap (as in G-man - government man > > - https://en.wikipedia.org/wiki/G-man)____ = > >=20 > > __ __ > >=20 > > __ __ > >=20 > > __ __ > >=20 > > =E1=90=A7____ > >=20 > > __ __ > >=20 > > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault > > > > >> wrote:____ > >=20 > > So, let's adopt a GNAP! We can even come with a > > little mascot (a bit like go gopher) as imagined > > by http://elisegravel.com/blog/adopte-un-gnap/ = , > > loved by little Canadians :-) ____ > >=20 > > __ __ > >=20 > > Just to be sure, how do you recommand we = pronounce > > it? ____ > >=20 > > __ __ > >=20 > > Looking forward to the next steps too.. ____ > >=20 > > __ __ > >=20 > > Thxs____ > >=20 > > Fabien____ > >=20 > > --____ > >=20 > > Txauth mailing list____ > >=20 > > Txauth@ietf.org = >____ > >=20 > > https://www.ietf.org/mailman/listinfo/txauth____ = > >=20 > > --____ > >=20 > > Txauth mailing list____ > >=20 > > Txauth@ietf.org = >____ > >=20 > > https://www.ietf.org/mailman/listinfo/txauth____ = > >=20 > > -- ____ > >=20 > > Txauth mailing list____ > >=20 > > Txauth@ietf.org = >____ > >=20 > > 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 = --Apple-Mail=_863B57DC-5C8B-4749-AC30-1CEE9C86C642 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with Mike, in that we should get used to answering to both.

In my head, it reads = with a hard =E2=80=9CG=E2=80=9D, at least partially because of the = Smurfs video=E2=80=99s legacy.

 =E2=80=94 Justin

On Jun 15, 2020, at 3:38 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

I don=E2=80=99t care a lot = one way or the other.  My main point is that no matter what = guidance we give, many people are likely to pronounce the =E2=80=9CG=E2=80= =9D.  If we try to insist on it being silent, we should get used to = the fact that we=E2=80=99ll probably be hearing both pronunciations.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
P.S.  = Thanks for the Smurfs link, Vittorio!
 
From: vittorio.bertocci@auth0.com <vittorio.bertocci@auth0.com> 
Sent: Monday, June 15, 2020 12:25 = PM
To: 'Dick Hardt' <dick.hardt@gmail.com>; = 'Peter Saint-Andre' <stpeter@mozilla.com>
Cc: Mike = Jones <Michael.Jones@microsoft.com>; 'Jared Jennings' <jaredljennings@gmail.com>; = 'Amanjeev Sethi' <aj@amanjeev.com>; = 'Fabien Imbault' <fabien.imbault@gmail.com>; txauth@ietf.org
Subject: RE: [Txauth] GNAP it is
 
Perhaps not to be taken too seriously, but here=E2=80=99s = prior art on GNAP pronunciation.
As Leif mentioned few mails ago, = =E2=80=9CGNAP=E2=80=9D appeared on the Smurfs comic and was reprised in = a cartoon episode as well.
You=E2=80=99ll find few examples around = 3:30
 https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyou= tu.be&fbclid=3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WB= JgPbpQ
 
From: Txauth <txauth-bounces@ietf.org> On Behalf = Of Dick Hardt
Sent: Monday, June 15, 2020 12:18 = PM
To: Peter Saint-Andre <stpeter@mozilla.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; Jared Jennings <jaredljennings@gmail.com>; = Amanjeev Sethi <aj@amanjeev.com>; = Fabien Imbault <fabien.imbault@gmail.com>; txauth@ietf.org
Subject: Re: [Txauth] GNAP it is
 
Checking in again on pronunciation.
 
Mike: do you still have concerns with a = silent 'G'?
 
Anyone else have concerns?
 
I'd like to nip pronunciation confusion = in the bud by having the recommended pronunciation in the = charter.
 
 
=E1=90=A7
 
On Sun, = Jun 7, 2020 at 1:23 PM Peter Saint-Andre <stpeter@mozilla.com> = wrote:
Looks like we were = caught gnapping. ;-)

OK, that's the last of = my snarky comments, let's get to work!

Peter

On 6/7/20 2:09 PM, Dick = Hardt wrote:
> It is if you are familiar with any of = the GNU projects.
> 
> https://www.gnu.org/gnu/pronunciation.en.html
> 
> A quick search on the internet has the "normal" = pronunciation of "gnu"
> to have a silent 'g'.
> 
> https://www.howtopronounce.com/gnu
> https://dictionary.cambridge.org/us/pronunciation/english/gnu
> 
> 
> =E1=90=A7
> 
> On Sun, = Jun 7, 2020 at 12:51 PM Mike Jones <Michael.Jones@microsoft.com
> = <mailto:Michael.Jones@microsoft.com>> wrote:
> 
>     I had assumed Guh-Nap =E2=80=93 = parallel to the pronunciation of GNU.  I
>  =    think that=E2=80=99s the most natural way to read = it.____
> 
>  =    __ __
> 
>  =   =             &n= bsp;           &nbs= p;            =             &n= bsp;      -- Mike____
> 
>  =    __ __
> 
>  =    *From:* Txauth <txauth-bounces@ietf.org
>    =  <mailto:txauth-bounces@ietf.org>> *On Behalf Of *Dick = Hardt
>     *Sent:* Sunday, June 7, 2020 = 12:45 PM
>     *To:* Amanjeev Sethi = <aj@amanjeev.com <mailto:aj@amanjeev.com>>
>     *Cc:* Fabien Imbault <fabien.imbault@gmail.com
>    =  <mailto:fabien.imbault@gmail.com>>; Jared Jennings
>     <jaredljennings@gmail.com <mailto:jaredljennings@gmail.com>>;
>  =    txauth@ietf.org <mailto:txauth@ietf.org>
>     *Subject:* Re: [Txauth] GNAP it = is____
> 
>  =    __ __
> 
>  =    Anyone have objection to the recommended = pronunciation being the
>    =  English word "nap", as in "gnaw"?____
> 
>  =    __ __
> 
>  =    If not, then we could add a = pronunciation recommendation to the
>    =  Charter.____
> 
>  =    __ __
> 
>  =    =E1=90=A7____
> 
>  =    __ __
> 
>  =    On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi <aj@amanjeev.com
>     <mailto:aj@amanjeev.com>> = wrote:____
> 
>  =        Vote for 'G' silent, as in 'lagnappe' = ;)____
> 
>  =        __ __
> 
>  =        On Sat, Jun 6, 2020, at 10:52 AM, Jared = Jennings wrote:____
> 
>  =            I vote for G silent. For the = reason it's most common to
>        =      pronounce, especially for those not familiar with = open
>            =  source usages.____
> 
>  =            __ __
> 
>             On Sat, = Jun 6, 2020, 08:45 Dick Hardt <dick.hardt@gmail.com
>    =          <mailto:dick.hardt@gmail.com>> wrote:____
> 
>                =  The obvious pronunciation choices are:____
> 
>  =                __ __
> 
>                =  nap (silent g as in gnaw)____
> 
>  =                __ __
> 
>                =  guh-nap (as in the GNU OS
>      =            - https://www.gnu.org/gnu/pronunciation.en..html
>                =  <https://www.gnu.org/gnu/pronunciation.en.html>)____
> 
>                =  __ __
> 
>  =                gee-nap (as in = G-man - government man
>        =          - https://en.wikipedia.org/wiki/G-man)____
> 
>                =  __ __
> 
>  =                __ __
> 
>                =  __ __
> 
>  =                =E1=90=A7____=
> 
>                =  __ __
> 
>  =                On Sat, Jun 6, = 2020 at 1:34 AM Fabien Imbault
>      =            <fabien.imbault@gmail.com
>    =              <mailto:fabien.imbault@gmail.com>> wrote:____
> 
>                =      So, let's adopt a GNAP! We can even come with a
>                =      little mascot (a bit like go gopher) as imagined
>                =      by http://elisegravel.com/blog/adopte-un-gnap/,
>                =      loved by little Canadians :-) ____
> 
>                =      __ __
> 
>  =                   =  Just to be sure, how do you recommand we pronounce
>                =      it? ____
> 
>  =                   =  __ __
> 
>  =                   =  Looking forward to the next steps too.. ____
> 
>                =      __ __
> 
>  =                   =  Thxs____
> 
>  =                   =  Fabien____
> 
>  =                   =  --____
> 
>  =                   =  Txauth mailing list____
> 
>  =                    Txauth@ietf.org <mailto:Txauth@ietf.org>____
> 
>                =      https://www.ietf.org/mailman/listinfo/txauth____
> 
>                =  --____
> 
>  =                Txauth mailing = list____
> 
>  =                Txauth@ietf.org <mailto:Txauth@ietf.org>____
> 
>                =  https://www.ietf.org/mailman/listinfo/txauth____
> 
>            =  -- ____
> 
>  =            Txauth mailing list____
> 
>             Txauth@ietf.org <mailto: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=_863B57DC-5C8B-4749-AC30-1CEE9C86C642-- From nobody Mon Jun 15 14:07:42 2020 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 D88273A10D4 for ; Mon, 15 Jun 2020 14:07:40 -0700 (PDT) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 B-GIIxMekK1V for ; Mon, 15 Jun 2020 14:07:39 -0700 (PDT) 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 86B6C3A10D2 for ; Mon, 15 Jun 2020 14:07:39 -0700 (PDT) Received: from [192.168.1.14] (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 05FL7awg002522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Jun 2020 17:07:37 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Justin Richer In-Reply-To: Date: Mon, 15 Jun 2020 17:07:36 -0400 Cc: "rdd@cert.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "txauth@ietf.org" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] WG chair changes -- thank you Dick, welcome Leif 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, 15 Jun 2020 21:07:41 -0000 Thank you very much, Dick, for helping get this group off the ground. = Welcome, Leif! I look forward to continuing to work with you, and the rest of the = community, as we push the boundaries with our new protocol work! =E2=80=94 Justin > On Jun 15, 2020, at 3:21 PM, Roman Danyliw wrote: >=20 > Hi! >=20 > With the GNAP charter now in IESG review (scheduled for the June 25 = telechat), we enter a difference phase of work. At this natural = transition, the chairs of GNAP will also change. =20 >=20 > Yaron has graciously agreed to continue on as co-chair. Thank you! >=20 > Dick will step down to focus his attention on the GNAP specifications. = (With Yaron), Dick led us through multiple BoFs, charter refinements = and key scoping activities that allowed us to get to this point -- from = mailing list to BoF to "almost a WG". Please join me in thanking Dick = for his leadership. Luckily for all of us, despite this change, he will = still be quite involved in the work. =20 >=20 > Finally, I am pleased to announce that Leif Johansson will be stepping = in as the new co-chair. Leif brings both domain and prior WG leadership = experience. Please join me in welcoming Leif to this role. >=20 > Regards, > Roman >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Mon Jun 15 15:15:09 2020 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 3F8173A0E74 for ; Mon, 15 Jun 2020 15:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 SwGC84YeTo0S for ; Mon, 15 Jun 2020 15:15:02 -0700 (PDT) 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 398A63A0F10 for ; Mon, 15 Jun 2020 15:14:54 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id d7so10510028lfi.12 for ; Mon, 15 Jun 2020 15:14:54 -0700 (PDT) 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=Jb0hRZLNaj7TnhqX6dX45TKz2i9Dbix0QAigmjoG+T8=; b=X0XiXSGNWl3apmdkRB7mhYIMCsXiFVhMU89OyATMJA4wQQzPc8eCdYTlfEZO/2N/km r4A+hA576h4qfj/Zh+2UCrvcP1KIXd+PLwcA0ZHTYTjXrlJU2XhwpWI+Ev2Al/1VPc52 05aq5gPXSqx1hZWwOAMDqIsKOuMCXrqWuTwYTl37hpkYnPVgsPrgQhSF1vcfeka7ETdh wXHL3954ho2s+jbigc+7+2H4N4kZ00QbTvcYLRZi2aydouTnWQJJLAXHucYeOXmuuLou OxqqN8DbNhsNRg53ROpc+m8ol5Ju54iGeC9Ujn7/YLCIy49mYOaw108YJDP/RJgOABEA aAMw== 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=Jb0hRZLNaj7TnhqX6dX45TKz2i9Dbix0QAigmjoG+T8=; b=BzYnr0bw+M0Ats2UeXQZBmn8Ob4gzDR+rdk9FROhvrXKuZu3xa6qSq4bXLZFT9BFU/ jsE+FcguBiL8Cq08KuNSJmBwkFzmV64HxCQCAIkvkXLVXnu2jZd6qypetrMCF6PcRS7H S+oh3gOw1Jn2reSqBn7NKVGfbf1b778yaZ9fgpgUfT5xVAseBj6Lu0mS6KZjNxCg8L8i VTFQENyySsyIuihSWur4p1r2Dh9qODMnTzql0p8R4KYmEbH7roZFynIMbE6o6liVJvKw 8P6L4VjlsBkCudjSNeWKW73xwZfPlPtxc5greCUpTRbXoNefRsk3ItvlHRnorY6Iw32o k7LQ== X-Gm-Message-State: AOAM533rardtXuLGBT6iFgxYlXsHAl+AAR2wH8ZNMny+jiVfgZIO6Qmw 4FtsHPyGjsK5ZjfhLAnwynxdOFP21Ukv6TfTHQY= X-Google-Smtp-Source: ABdhPJwD9y7dMYMf5YvclRrFsELrkyUOVoMu2eNxbP1jlkdh5Rih+pGOwWDIMj5lZrQLVEOJJ+xEFnqBzNVWLdDulDc= X-Received: by 2002:ac2:489a:: with SMTP id x26mr49539lfc.111.1592259292019; Mon, 15 Jun 2020 15:14:52 -0700 (PDT) MIME-Version: 1.0 References: <5443710B-05DB-4C4D-AC4B-0D8D173E131B@mit.edu> In-Reply-To: <5443710B-05DB-4C4D-AC4B-0D8D173E131B@mit.edu> From: Dick Hardt Date: Mon, 15 Jun 2020 15:14:26 -0700 Message-ID: To: Justin Richer Cc: Mike Jones , "vittorio.bertocci@auth0.com" , Peter Saint-Andre , Fabien Imbault , Jared Jennings , Amanjeev Sethi , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007dbf2905a826c1b8" Archived-At: Subject: Re: [Txauth] GNAP it is 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, 15 Jun 2020 22:15:07 -0000 --0000000000007dbf2905a826c1b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree we should be prepared for both. Can we agree that we can be consistent? Personally I don't care which we choose -- I only care that we choose one. I was working to address the concern that you (Justin) had brought up: This is ok, but it has a couple downsides. The pronunciation of a hard =E2= =80=9Cg=E2=80=9D or not is going to potentially be confusing, as is the fact that it looks like it=E2=80=99s part of the GNU project because of that. On Mon, Jun 15, 2020 at 1:56 PM Justin Richer wrote: > I agree with Mike, in that we should get used to answering to both. > > In my head, it reads with a hard =E2=80=9CG=E2=80=9D, at least partially = because of the > Smurfs video=E2=80=99s legacy. > > =E2=80=94 Justin > > On Jun 15, 2020, at 3:38 PM, Mike Jones < > Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: > > I don=E2=80=99t care a lot one way or the other. My main point is that n= o matter > what guidance we give, many people are likely to pronounce the =E2=80=9CG= =E2=80=9D. If we > try to insist on it being silent, we should get used to the fact that we= =E2=80=99ll > probably be hearing both pronunciations. > > -- Mike > > P.S. Thanks for the Smurfs link, Vittorio! > > *From:* vittorio.bertocci@auth0.com > *Sent:* Monday, June 15, 2020 12:25 PM > *To:* 'Dick Hardt' ; 'Peter Saint-Andre' < > stpeter@mozilla.com> > *Cc:* Mike Jones ; 'Jared Jennings' < > jaredljennings@gmail.com>; 'Amanjeev Sethi' ; 'Fabien > Imbault' ; txauth@ietf.org > *Subject:* RE: [Txauth] GNAP it is > > Perhaps not to be taken too seriously, but here=E2=80=99s prior art on GN= AP > pronunciation. > As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the S= murfs comic and > was reprised in a cartoon episode as well. > You=E2=80=99ll find few examples around 3:30 > > https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbclid= =3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ > > *From:* Txauth *On Behalf Of *Dick Hardt > *Sent:* Monday, June 15, 2020 12:18 PM > *To:* Peter Saint-Andre > *Cc:* Mike Jones ; Jared Jennings < > jaredljennings@gmail.com>; Amanjeev Sethi ; Fabien > Imbault ; txauth@ietf.org > *Subject:* Re: [Txauth] GNAP it is > > Checking in again on pronunciation. > > Mike: do you still have concerns with a silent 'G'? > > Anyone else have concerns? > > I'd like to nip pronunciation confusion in the bud by having the > recommended pronunciation in the charter. > > > =E1=90=A7 > > On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre > wrote: > > Looks like we were caught gnapping. ;-) > > OK, that's the last of my snarky comments, let's get to work! > > Peter > > On 6/7/20 2:09 PM, Dick Hardt wrote: > > It is if you are familiar with any of the GNU projects. > > > > https://www.gnu.org/gnu/pronunciation.en.html > > > > A quick search on the internet has the "normal" pronunciation of "gnu" > > to have a silent 'g'. > > > > https://www.howtopronounce.com/gnu > > https://dictionary.cambridge.org/us/pronunciation/english/gnu > > > > > > =E1=90=A7 > > > > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones > > wrote: > > > > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of GN= U. I > > think that=E2=80=99s the most natural way to read it.____ > > > > __ __ > > > > -- Mike____ > > > > __ __ > > > > *From:* Txauth > > *On Behalf Of *Dick Hardt > > *Sent:* Sunday, June 7, 2020 12:45 PM > > *To:* Amanjeev Sethi > > > *Cc:* Fabien Imbault > >; Jared Jennings > > >; > > txauth@ietf.org > > *Subject:* Re: [Txauth] GNAP it is____ > > > > __ __ > > > > Anyone have objection to the recommended pronunciation being the > > English word "nap", as in "gnaw"?____ > > > > __ __ > > > > If not, then we could add a pronunciation recommendation to the > > Charter.____ > > > > __ __ > > > > =E1=90=A7____ > > > > __ __ > > > > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi > > wrote:____ > > > > Vote for 'G' silent, as in 'lagnappe' ;)____ > > > > __ __ > > > > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____ > > > > I vote for G silent. For the reason it's most common to > > pronounce, especially for those not familiar with open > > source usages.____ > > > > __ __ > > > > On Sat, Jun 6, 2020, 08:45 Dick Hardt > > wrote:____ > > > > The obvious pronunciation choices are:____ > > > > __ __ > > > > nap (silent g as in gnaw)____ > > > > __ __ > > > > guh-nap (as in the GNU OS > > - https://www.gnu.org/gnu/pronunciation.en..html > > )____ > > > > __ __ > > > > gee-nap (as in G-man - government man > > - https://en.wikipedia.org/wiki/G-man)____ > > > > __ __ > > > > __ __ > > > > __ __ > > > > =E1=90=A7____ > > > > __ __ > > > > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault > > > > wrote:____ > > > > So, let's adopt a GNAP! We can even come with a > > little mascot (a bit like go gopher) as imagined > > by http://elisegravel.com/blog/adopte-un-gnap/, > > loved by little Canadians :-) ____ > > > > __ __ > > > > Just to be sure, how do you recommand we pronounce > > it? ____ > > > > __ __ > > > > Looking forward to the next steps too.. ____ > > > > __ __ > > > > Thxs____ > > > > Fabien____ > > > > --____ > > > > 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____ > > > > __ __ > > > > __ __ > > > > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > > > --0000000000007dbf2905a826c1b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree we should be prepared for both. C= an we agree that we can be consistent? Personally I don't care which we= choose -- I only care that we choose one.

=
I was working=C2=A0to address the concern that you (Justin= ) had brought up:

This is ok, but it has a couple downsides= . The pronunciation of a hard =E2=80=9Cg=E2=80=9D or not is going to potent= ially be confusing, as is the fact that it looks like it=E2=80=99s part of = the GNU project because of that.



On Mon, Jun 15, 2020 at 1:56 PM Justin Richer <jricher@mit.edu> wrote:
I agree with Mike, in that we should get used to answering to bot= h.

In my head, it reads with a hard =E2=80=9CG=E2=80=9D,= at least partially because of the Smurfs video=E2=80=99s legacy.

=C2=A0=E2=80=94 Justin

On Jun 15, 2020, at 3:38 PM, Mike Jones <Michael.Jones= =3D40microsoft.com@dmarc.ietf.org> wrote:

I don=E2=80=99t car= e a lot one way or the other.=C2=A0 My main point is that no matter what gu= idance we give, many people are likely to pronounce the =E2=80=9CG=E2=80=9D= .=C2=A0 If we try to insist on it being silent, we should get used to the f= act that we=E2=80=99ll probably be hearing both pronunciations.
=C2=A0
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 -- Mike
=C2=A0
P.S.=C2=A0 Thanks for the Smurfs link, Vittorio!=
=C2= =A0
From:=C2=A0= vittorio.bertocci@auth0.com=C2=A0<vittorio.bertocci@auth0.com>=C2=A0
<= b>Sent:=C2=A0Monday, June 15, 2020 12:25 PM
To:<= span>=C2=A0'Dick Hardt' <di= ck.hardt@gmail.com>; 'Peter Saint-Andre' <stpeter@mozilla.com>
Cc:=C2=A0M= ike Jones <Michael.Jones@microsoft.= com>; 'Jared Jennings' <jaredljennings@gmail.com>; 'Amanjeev Sethi' <aj@amanjeev.com>; 'Fabien Imbault' <fabien.imbault@gmail.com>;=C2=A0txauth@ietf.org
Subject:= =C2=A0RE: [Txauth] GNAP it is
=C2=A0
Perhaps not to be taken too seriousl= y, but here=E2=80=99s prior art on GNAP pronunciation.
<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared o= n the Smurfs comic and was reprised in a cartoon episode as well.=
You=E2=80=99ll find few examples around 3:30<= /u>
=C2=A0
<= div style=3D"border-style:solid none none;border-top-width:1pt;border-top-c= olor:rgb(225,225,225);padding:3pt 0in 0in">
From:=C2= =A0Txauth <txauth-bounces@ietf.o= rg>=C2=A0On Behalf Of=C2=A0Dick Har= dt
Sent:=C2=A0Monday, June 15, 2020 12:18 PM
T= o:=C2=A0Peter Saint-Andre <stpeter@mozilla.com>
Cc:=C2=A0Mike Jones <= ;Michael.Jones@microsoft.com>; = Jared Jennings <jaredljennings@gmail.c= om>; Amanjeev Sethi <aj@amanjeev.com= >; Fabien Imbault <fabien.imbault@= gmail.com>;=C2=A0txauth@ietf.o= rg
Subject:=C2=A0Re: [Txauth] GNAP it is<= u>
=C2=A0
Checki= ng in again on pronunciation.
=C2= =A0
Mike: do you still have concerns with = a silent 'G'?
=C2=A0=
Anyone else have concerns?<= /div>
=C2=A0
= I'd like to nip pronunciation confusion in the bud by having the recomm= ended pronunciation=C2=A0in the charter.
=C2=A0
=C2=A0
=E1=90=A7
=C2=A0
On Sun, Jun 7, 2020 at 1:23 PM Pet= er Saint-Andre <stpeter@mozilla.com>= wrote:
Looks like we were c= aught gnapping. ;-)

OK, that's the last of my snarky comments, l= et's get to work!

Peter

On 6/7/20 2:09 PM, Dick Hardt wro= te:
> It is if you are familiar with any of the GNU projects.
>= =C2=A0
>=C2=A0https://www.gnu.org/gnu/pronunciation.en.html
>= ;=C2=A0
> A quick search on the internet has the "n= ormal" pronunciation of "gnu"
> to have a silent '= g'.
>=C2=A0
>=C2=A0https://www.howtopronounce.com/gnu
>= =C2=A0https://dictionary.cambridge.org/us/pronunciation/english/gnu
>= =C2=A0
>=C2=A0
>=C2=A0=E1=90=A7
>= =C2=A0
> On Sun, Jun 7, 2020 at 12:51 PM Mike Jones <Michael.Jones@microsoft.com
> <= mailto:Michael.Jones@microsoft.com= >> wrote:
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0I had= assumed Guh-Nap =E2=80=93 parallel to the pronunciation of GNU.=C2=A0 I>=C2=A0 =C2=A0 =C2=A0think that=E2=80=99s the most natural way to read = it.____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__>=C2=A0
>=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 -- Mike____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0__=C2= =A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0*From:* Txauth = <txauth-bounces@ietf.org
>=C2= =A0 =C2=A0 =C2=A0<mailto:txauth-bounces= @ietf.org>> *On Behalf Of *Dick Hardt
>=C2=A0 =C2=A0 =C2=A0= *Sent:* Sunday, June 7, 2020 12:45 PM
>=C2=A0 =C2=A0 =C2=A0*To:* Aman= jeev Sethi <aj@amanjeev.com=C2=A0<mailto:aj@amanjeev.com>>
>= =C2=A0 =C2=A0 =C2=A0*Cc:* Fabien Imbault <fabien.imbault@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:fabien.imbault@gmail.com>>; Jared J= ennings
>=C2=A0 =C2=A0 =C2=A0<ja= redljennings@gmail.com=C2=A0<mailto:jaredljennings@gmail.com>>;
>=C2=A0 =C2=A0 = =C2=A0txauth@ietf.org=C2=A0<ma= ilto:txauth@ietf.org>
>=C2=A0 =C2=A0 = =C2=A0*Subject:* Re: [Txauth] GNAP it is____
>=C2=A0
= >=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0= =C2=A0 =C2=A0Anyone have objection to the recommended pronunciation=C2=A0b= eing the
>=C2=A0 =C2=A0 =C2=A0English word "nap", as in &qu= ot;gnaw"?____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0__= =C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0If not, then= we could add a pronunciation=C2=A0recommendation to the
>=C2=A0 =C2= =A0 =C2=A0Charter.____
>=C2=A0
>=C2=A0 =C2=A0 =C2= =A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0=E1=90=A7____
>= =C2=A0
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Seth= i <aj@amanjeev.com
>=C2=A0 =C2=A0 =C2= =A0<mailto:aj@amanjeev.com>> wrote:__= __
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vote= for 'G' silent, as in 'lagnappe' ;)____
>=C2= =A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020= , at 10:52 AM, Jared Jennings wrote:____
>=C2=A0
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I vote for G silent. For th= e reason it's most common to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0pronounce, especially for those not familiar with open
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0source usages.____
><= span>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_= _=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020, 08:45 Dick Hardt <dick.hardt@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0<mailto:dick.hardt@gma= il.com>> wrote:____
>=C2=A0
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The obvious pronunciati= on choices are:____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0na= p (silent g as in gnaw)____
>=C2=A0
>=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>= =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0guh-nap (as in the GNU OS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0https://www.gnu.org/gnu/pronunciation.en..html
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.gnu.org/gnu/pronunciation.e= n.html>)____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ge= e-nap (as in G-man - government man
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0https://en.wikipedia.org/wiki/G-man)____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__= =C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>= ;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=E1=90=A7= ____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
= >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, J= un 6, 2020 at 1:34 AM Fabien Imbault
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<fabien= .imbault@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<mailto:fabien.imbaul= t@gmail.com>> wrote:____
>=C2=A0
>=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0So, l= et's adopt a GNAP! We can even come with a
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0little mascot (a bit= like go gopher) as imagined
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by=C2=A0http://elisegravel.com/blog/adopte-un-gnap/,
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0loved by little Canadians :-)=C2=A0____
>=C2=A0
&g= t;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Just to be sure, how do yo= u recommand we pronounce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it?=C2=A0____
>=C2=A0<= br>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Looking forward to = the next steps too..=C2=A0____
>=C2=A0
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0_= _
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thxs____
>=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Fabien____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--____
>= =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list____
>=C2=A0<= br>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Txauth@ietf.org=C2=A0&l= t;mailto:Txauth@ietf.org>____
>= =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0= https://www.ietf.org/mailman/listinfo/txauth____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-= -____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth@ietf.org=C2=A0<mailto:Txauth@ietf.org>____
>=C2=A0=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/= listinfo/txauth____
>=C2=A0
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--=C2=A0____
>=C2=A0
&= gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list____<= br>>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Txauth@ietf.org=C2=A0<m= ailto:Txauth@ietf.org>____
>=C2= =A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/li= stinfo/txauth____
>=C2=A0
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>= ;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0>=C2=A0
--=C2=A0
Txauth maili= ng list
Txauth@ietf.org
https://www.ietf.org/mailman/l= istinfo/txauth

--0000000000007dbf2905a826c1b8-- From nobody Mon Jun 15 16:43:15 2020 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 C705B3A0F09 for ; Mon, 15 Jun 2020 16:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.682 X-Spam-Level: X-Spam-Status: No, score=-0.682 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 U7khVXZQClvz for ; Mon, 15 Jun 2020 16:43:12 -0700 (PDT) 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 243EC3A0F08 for ; Mon, 15 Jun 2020 16:43:12 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id x18so21265033lji.1 for ; Mon, 15 Jun 2020 16:43:12 -0700 (PDT) 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=evWiu0hrcfFIUW9Yz33D5XWdief2GWehL/kuJWj4PDs=; b=g06Xc5eaujsyPZhNjgx5i6LmaUhirwIRIhQLKBfXNJTBJjWvJagveSawYlvGJBacDd 5vRX7hD2l1GDjnjFdT0pCTGKPKoFAel9Dvjd4IIefGRnZV+z74ndAE0RqM3/cWdAeEtm Px5CND5dtUI7bJJf6XVba3DBA9TtiNoFxX1h+qS6DfSwXtw2KcP9xAeoi2ZftqUq1TU/ /pU+czVpJtLPEQhVYia4xW5E2BRTKpvO4tGJDCyBN+p0FlYMOufM4ng6Ce4Tc45X4r60 zAs2fQaPI/8vs9IKX3WW4BFs43IGMZ1PMJV9HNQGXOciPQRWlZXZ6VaeGlIOlnJUlqPA 45jA== 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=evWiu0hrcfFIUW9Yz33D5XWdief2GWehL/kuJWj4PDs=; b=WlM0JVSC+dJdZUxrNblrOB8AhPWi6xRvfCmpw9GIiTj/WsTL/F6UhrCeVP4Z8hChE0 IAhSmkmqyC0GYzvigk53jcxjco0btcDMOxYrA7eXEVRztJon0P0jQSMV//UGMxQ4G4u0 oIIGrzSRtLETNphgZ2e3dZoAw4biPDW1XBB78U9fM3WrvT0QwdC6IwOb1o2OrCdcfZz9 VPV6c1JyD9tzzYYuC0ZziF1m89II6W7BANPAeYaQJNVNvv3OZJAkwSTx63b8KXrhPtnI VwUAh0llg2aE+ONSI1V0vBJlA+bSbQGyCwFWtT1VlLDZ/qHT9aV0Bg6f1KFL42oUfPKw sGzA== X-Gm-Message-State: AOAM533g9qXBVPU7RBU5Za8lQl5BjJW+IrVqvuMu1JQ0u22+8N6eEgGg Lnf/yEr+LZnvybj/YPL5Bn3sjLvWbzBMUi7sMxDSEfHG X-Google-Smtp-Source: ABdhPJxBaiJ4+Y36G8VSiX0bRrkC00az7X/p8Zt2tsuZbNLVoPkuHsTGcDk/l7TUDl7CbANxB7gKX4rxZfn/sh+1xBY= X-Received: by 2002:a2e:8e78:: with SMTP id t24mr58601ljk.314.1592264589875; Mon, 15 Jun 2020 16:43:09 -0700 (PDT) MIME-Version: 1.0 References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> <20200614044315.GD11992@kduck.mit.edu> In-Reply-To: <20200614044315.GD11992@kduck.mit.edu> From: Dick Hardt Date: Mon, 15 Jun 2020 16:42:43 -0700 Message-ID: To: Benjamin Kaduk Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000044a18105a827fd2e" Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 15 Jun 2020 23:43:14 -0000 --00000000000044a18105a827fd2e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable inline ... On Sat, Jun 13, 2020 at 9:43 PM Benjamin Kaduk wrote: > Hi all, > > Sorry for jumping in so late (and with so little to say). But, > > On Mon, Jun 08, 2020 at 11:58:03AM -0700, Dick Hardt wrote: > > On Mon, Jun 8, 2020 at 5:29 AM Justin Richer wrote: > > > > > > > > > > These are input proposals, everything is up for debate. That=E2=80=99= s why > we=E2=80=99re > > > debating. > > > > > > > Yes, we are debating the pros and cons of each proposal. > > maybe it's just me, but the phrasing of "debating the pros and cons of ea= ch > proposal" makes it sound like a fixed evaluation, where we have two input= s, > tally the plusses and minuses in each's column, and at the end decide wha= t > is "better". I'd much rather describe what we're doing now as exploring > what properties we could have in GNAP and considering which of those > properties we believe will make for a successful protocol. > Hopefully everyone is already doing this, and I will happily apologize fo= r > wasting your time to read this message. But I do want to avoid this as a > question of "is X or Z a better protocol?", and ensure that we feel that = we > have the freedom to do the right thing. > Hey Ben, thanks for pointing out my sloppy language, and the possible misinterpretation. I think we are debating the pros and cons of each of the proposal's *to provide a feature* in the protocol, specifically the 4 areas I had concerns in XYZ, and my proposals to address each of those. /Dick =E1=90=A7 --00000000000044a18105a827fd2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
inline ...=C2=A0

=
On Sat, Jun 13, 2020 at 9:43 PM Benja= min Kaduk <kaduk@mit.edu> wrote:=
Hi all,

Sorry for jumping in so late (and with so little to say).=C2=A0 But,

On Mon, Jun 08, 2020 at 11:58:03AM -0700, Dick Hardt wrote:
> On Mon, Jun 8, 2020 at 5:29 AM Justin Richer <jricher@mit.edu> wrote:
> <snip>
>
> >
> > These are input proposals, everything is up for debate. That=E2= =80=99s why we=E2=80=99re
> > debating.
> >
>
> Yes, we are debating the pros and cons of each proposal.

maybe it's just me, but the phrasing of "debating the pros and con= s of each
proposal" makes it sound like a fixed evaluation, where we have two in= puts,
tally the plusses and minuses in each's column, and at the end decide w= hat
is "better".=C2=A0 I'd much rather describe what we're do= ing now as exploring
what properties we could have in GNAP and considering which of those
properties we believe will make for a successful protocol.
Hopefully everyone is already doing this, and I will happily apologize for<= br> wasting your time to read this message.=C2=A0 But I do want to avoid this a= s a
question of "is X or Z a better protocol?", and ensure that we fe= el that we
have the freedom to do the right thing.

Hey Ben, thanks for pointing out my sloppy language, and the possible misi= nterpretation.

I think we are debating the pros an= d cons of each of the proposal's to provide a feature in the pro= tocol, specifically the 4 areas I had concerns in XYZ, and my proposals to = address each of those.


/Dick
<= div>

=C2=A0
3D""=E1=90= =A7
--00000000000044a18105a827fd2e-- From nobody Mon Jun 15 17:19:55 2020 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 AC95E3A0F12 for ; Mon, 15 Jun 2020 17:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 M3AGWh0rSA5z for ; Mon, 15 Jun 2020 17:19:49 -0700 (PDT) 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 9E6433A0F0F for ; Mon, 15 Jun 2020 17:19:48 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id n23so21343093ljh.7 for ; Mon, 15 Jun 2020 17:19:48 -0700 (PDT) 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=5zYyXNXDoHuOHmjcAwbuOJGe7DtCRnMBwIDkwkg1Dnk=; b=joy4vj6TI6lwfQgRj/9fn5utT8GlZXCpDD6jtJmSBoyud6fgqH0xUS7xQmc9GcEi27 XJtz3Mhv/S2MvXuvbq6Nw8pHvcmYhBAAL+NXVwCXBnRC2QQyXYs5JEzty2tHgy0tcHEc tqgLuEaTmdUcsPfINCsTYVDgBLKeN0F+78h1lwJlnjKoSLzxA/O+jNLGWB9or4nmPNim yxnBoKlnPsFXsTY+hTYsoIZ6d4ZOOpF6GdC3OsSYh0OprzkfuopvbaQk9ilArBrNkeau s8ydEdKo07r274jrWp4cAI1lt8ZDoadFKxOSS4oJE6aUmLJkV80S5FTIdhE1hDvy+U1E +vQw== 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=5zYyXNXDoHuOHmjcAwbuOJGe7DtCRnMBwIDkwkg1Dnk=; b=hCRAR2fvfpknudN98TTZWFnRNwFs85u4SLN8HZxJ99iruxK6YOLxnrSPFeIAImvd7y OMJ+r0pRg3Xfd652j7J20KvXoAXVnYYp/KVtA1VI/BZINmzmcbkAUbQryIF/onmEFQAh WooEzmabCcQbaqeCBIthkNbE2mYO07JT+qxtI2yjK7u2PNNCctok8w1YjEC1mSVwDs/w fcy2cYHE/A3SqGkyKQXeSdjbDJ7VjFLmV/jLxGIlYoOQQUEOzuhS0G4nLUkOEDJ9pP+i 0cJ3I65kxgwnSqHrE7eXSeemaNGLOngVPef8Zb9dA5QNwtsIt9H7RNrri+uKQYxX/8kP UhJQ== X-Gm-Message-State: AOAM530XBdCENyOO72/ua0pugDbdoxUjaPM881aHc1Aul/ddYR6lW8iK ZhAdrloB2wCr7p8t7EXjbh89y0baczJ5MiXCOaE= X-Google-Smtp-Source: ABdhPJyh77bzW6eS5tK5OlKfdin7p4wshBvoslaCFmrxXEa7NqFNzgYzdpzezKypxPN0dX/s+1b7o/ePHQhg8Y5LOv8= X-Received: by 2002:a05:651c:3cc:: with SMTP id f12mr102394ljp.244.1592266786358; Mon, 15 Jun 2020 17:19:46 -0700 (PDT) MIME-Version: 1.0 References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> In-Reply-To: From: Dick Hardt Date: Mon, 15 Jun 2020 17:19:19 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000304b0805a82880db" Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 16 Jun 2020 00:19:54 -0000 --000000000000304b0805a82880db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 10, 2020 at 7:54 AM Justin Richer wrote: > > On Jun 9, 2020, at 4:11 PM, Dick Hardt wrote: > > Comments inline > > Last item will be broken out to new thread. > > On Tue, Jun 9, 2020 at 9:10 AM Justin Richer wrote: > >> >> >> On Jun 8, 2020, at 5:33 PM, Dick Hardt wrote: >> >> >> >> On Mon, Jun 8, 2020 at 1:02 PM Justin Richer wrote: >> >> >> >>> A GS implementation can decide to only return an authorization from >>> doing a GET on the AZ URL. Returning only an AZ URL is an option in XAu= th. >>> Similarly, we could do the same for a Grant URI. >>> >>> >>> And that=E2=80=99s a lot of complex code paths for both the GS and clie= nt to >>> deal with. With more ways that it might happen, the client has to be >>> prepared for any of them =E2=80=94 and get them all right. >>> >> >> I don't see it being complex. The data either moves by reference or by >> value. Both parties will have to enable support by reference. Passing by >> value is an optimization so that the client does not have to make an >> additional call. >> >> >> =E2=80=9CBoth parties will have to enable=E2=80=9D is where the complexi= ty comes into >> play. It=E2=80=99s putting a requirement on the client to anticipate sev= eral >> different ways to get the same information. >> > > As I understand it, XYZ works the same way. The client may get a handle t= o > the transaction in an Interaction Response or a Wait Response, or the > client receives a transaction response. > > There could be only one way in XAuth (pass by reference), but I expect > that people will prefer an optimization of pass by value when it can be > done and deal with the complexity that they may get the data in two > different ways, just as in XYZ. > > > It=E2=80=99s not the same. What you=E2=80=99re missing, I believe, is tha= t this is one of > the benefits of having a single endpoint, as XYZ is defined today. The > =E2=80=9Cgrant response=E2=80=9D comes from exactly one place regardless = of where in the > transaction it happens. This is why I think this is something the working > group as a whole needs to weigh in on, to figure out the pros and cons of > different designs. I personally don=E2=80=99t like the complexity, and a = definitely > don=E2=80=99t like the restrictions imposed by XAuth today, but there are= benefits > that might outweigh and justify that move. > I think having a single endpoint is a disadvantage. The client (and server) have to parse the JSON to understand what happened. When the client wants to get a grant, it fetches the URL, as there is only one way for the client to ask for the grant. In XYZ, the client creates some JSON that signals to the AS that it wants a grant. Seems similar complexity on the client. But on the server, the server has to parse the JSON to understand what the client wants to do. I agree that the different published endpoints in OAuth 2 created additional complexity, but in XAuth, there is only one published endpoints. All other URIs are that endpoint with what could be considered parameters added for context. > > > >> >> >> >> >>> >>> >>> >>>> >>>> Using a different URI, optionally, isn=E2=80=99t the problem, and that= could >>>> easily be added to the. Removal of the separate handle is the problem = I >>>> have with the XAuth approach. >>>> >>> >>> In XAuth, the Grant URI is the GS URI + TBD + handle >>> >>> Given we have asymmetric crypto as a requirement, it is unclear what >>> having two pieces of random signal provide. >>> >>> >>> Asymmetric crypto is an implementation requirement in both the input >>> drafts but it isn=E2=80=99t a requirement in the charter, and there are= likely >>> symmetric use cases and key proofing mechanisms that are going to be >>> desirable for a lot of people. >>> >>> >>> >>>> >>>> >>>> >>>>> >>>>> Additionally, I find XAuth=E2=80=99s restrictions on the structure of= the >>>>> Grant URI potentially problematic, namely that it has to start with t= he >>>>> server=E2=80=99s URL. This will lead to deployments needing to bend t= heir setups >>>>> with proxies or redirectors to make things fit, which you yourself ha= ve >>>>> said is going to be an issue for things like supporting a short redir= ect >>>>> URL vs. a long redirect URL. Your complaint there was one of latency = and >>>>> complexity, why does that not apply here? But most fundamentally, I d= o not >>>>> see what value this restriction brings to the system. If the value is >>>>> coming back from the GS endpoint, and the client is getting all of it= s >>>>> pointers from there, what=E2=80=99s the point of dictating how that h= as to look? >>>>> >>>> >>>> Requiring the Grant URI to start with the GS URI is open to discussion= . >>>> It is not clear to me why a deployment would need to have a redirector= . >>>> Large scale deployments I have worked on have a router / proxy that ro= utes >>>> requests to internal services. Having all the URIs start with the GS U= RI >>>> enables all GNAP operations to be routed in the same place. >>>> >>>> >>>> You still haven=E2=80=99t addressed why you think that this is a reaso= nable >>>> requirement or assumption here but not when dealing with long/short UR= Ls >>>> for QR codes. What is the difference? >>>> >>> >>> Short URLs generally use a short host name as well as a short path. >>> >>> Most REST interfaces have the pattern I am proposing. A mental model >>> many developers are familiar with. >>> >>> >>> This is assuming a lot on the part of the GS implementation, still, and >>> all of my arguments stand. >>> >>> >>> That is not entirely correct. A pre-registered client can still pass >>> its key by value, and a dynamic client can still use a >>> (dynamically-acquired) handle. In all cases, the client is identifying >>> itself by its key. The difference is how the server looks up that key = =E2=80=94 >>> it=E2=80=99s either from the handle, or it=E2=80=99s from the key value= itself. >>> >> >> I don't understand this. >> >> How is the Client authenticating that it is a specific pre-registered >> client? >> >> >> *The client is identified by its key.* >> > > And you think that will be an easy concept for developers to migrate to > from the mental model they have now? And what is the value? I believe you= r > proposal for other pre-registered clients to migrate was to use the Clien= t > ID as the Key Handle. So the Key Handle may represent any of the > pre-registered clients, but represents each instance of a dynamic client. > Does not seem like it is any different than how a Client ID is used today= . > > Tom has started a new thread on other aspects of this section. > > > Not only do I think OAuth developers can migrate, *I think it=E2=80=99s e= ssential > that we do* in order to make this useful to non-OAuth developers. Vast > swaths of the internet are already building out key-based systems, not > using OAuth. In my own experience, I can say for a fact that the > awkwardness of needing a client identifier ahead of time is one of the > problems. The fact that there=E2=80=99s a place to use a legacy client ID= within > the protocol is a bonus feature, and important for migration. But it=E2= =80=99s even > more important that it=E2=80=99s not > > And we should look at history before we declare something impossible. We > managed to get web developers away from thinking about accessing an API > with a username and password and toward thinking in terms of accessing it > with a token. This is a shift of the same kind, and an important one at > that. > > To me, this is one of the important fundamental shifts of this work away > from the limits of OAuth=E2=80=99s models and assumptions, and one of the= ones that > will make this work applicable far outside of the space that OAuth 2 has > already carved. I don=E2=80=99t see a compelling reason to limit ourselve= s. > > If your primary goal is to keep OAuth 2 developers safe and happy, then i= n > all honesty, just keep using OAuth 2. Why wouldn=E2=80=99t you? Use PAR a= nd RAR and > DPoP for advanced functionality. It=E2=80=99s a combination that, if a bi= t > patched-together, does work. Move to a new protocol when it does somethin= g > you can=E2=80=99t do, or it=E2=80=99s otherwise a better fit for what you= =E2=80=99re trying to > solve. And when you=E2=80=99re in a position to move, there=E2=80=99s a m= igration path. > That doesn=E2=80=99t mean it=E2=80=99s a direct re-use, it means you can = migrate =E2=80=94 move, > change =E2=80=94 without tearing absolutely everything out. But you still= need to > move, and that=E2=80=99s expected. > > In all honesty, I think the gap between OAuth 2 and XYZ is less than the > gap between OAuth 1 and OAuth 2, especially if you=E2=80=99re looking at = using > OAuth 2 with PAR, RAR, etc. I don=E2=80=99t see a compelling reason to ar= tificially > limit the new protocol with the constraints of the old, particularly when > there=E2=80=99s a migration path between them. XYZ can make use of some o= f the > familiar pieces of OAuth 2 without causing all clients to depend on them. > That=E2=80=99s the difference between migration and straight re-use. > Of course you think it is straightforward. It is the mental model you made up! I agree we should not artificially limit the new protocol, but there is also no need to burn everything down because we can. > > > >> In XAuth, if the server wants to protect itself from a session fixation >> attack in a given request, and it wants to support both "redirect" and >> "user_code" modes, >> the server will return only those two modes and not "indirect". The >> >> In XAuth, if the server wants to protect itself from a session fixation >> attack in a given request, and it wants to support both "redirect" and >> "user_code" modes, >> the server MUST return callback, redirect, and user_code. The client doe= s >> not know that the "indirect" mode is not supported, and may try that. >> >> >> In XYZ, if the server wants to protect against a session fixation attack= , >> it will reject a request that doesn=E2=80=99t have a =E2=80=9Ccallback= =E2=80=9D field in it. The AS >> always gets to choose which things it supports for any given request. If >> the client wants to support both =E2=80=9Credirect=E2=80=9D and =E2=80= =9Cuser_code=E2=80=99 modes AND has >> the ability to handle session fixation issues, it sends the =E2=80=9Cred= irect=E2=80=9D, >> =E2=80=9Cuser_code=E2=80=99, and =E2=80=9Ccallback=E2=80=9D fields in it= s interaction request. >> > > If the client chooses to present the interaction_url as a scannable > barcode, which is an option if it receives one, it will then get an error > when it tries to do a transaction continue request as the AS protects > itself. Unfortunately the user has scanned the barcode and is now at the > AS. I don't see how the client learns it is not able to do what I call an > "indirect" mode interaction. Would you explain how this situation is > prevented in XYZ? > > > If the client has made a request with =E2=80=9Credirect=E2=80=9D and =E2= =80=9Ccallback=E2=80=9D in its > request, and then decides to display the interaction URL as a scannable > code, then the AS will just redirect to the client=E2=80=99s callback URL= when it=E2=80=99s > done, whatever that URL was. If the client sends a =E2=80=9Ccallback=E2= =80=9D URL that it > can=E2=80=99t get information from, then that=E2=80=99s a poorly-written = client, isn=E2=80=99t it? > Let me provide more clarity on the scenario. The client is a web app that can redirect the user to the AS, and receive a callback, it can display a code and URI to enter the code, or it can show a scannable code for the user to scan on their mobile phone. The user may be using the web app on a PC, and the AS is on their phone. The user chooses to scan the barcode with their phone. After authenticating with the AS, the AS redirects back to the callback URL. But the webpage is now on the user's mobile device, not the web app on the PC. > > If the client can=E2=80=99t get to the information in the callback URL un= less it=E2=80=99s > on the same device, then the client isn=E2=80=99t going to show the user = a > scannable code to be read by a secondary device. Why would it? > Because it is a better experience for the user per above. The AS parameters don't differentiate between a scannable URL and a URL that can only be redirected, so the client will think it can do anything. Additionally, in XAuth, the client can provide an informational URI for the AS to redirect after a scannable code or a user code flow. > > > > >> >> >>> >>> >>> For example: >>> >>> How is a transaction updated? >>> How are separate access tokens refreshed? >>> Refreshing an access token in XYZ returns a full transaction response >>> per Section 9.3 which refers to Section 8. >>> >>> Would you address these questions? > > > Transactions are updated by sending the transaction handle back with > additional information. This is no different from the request made after = a > front channel callback, or what would be made in a challenge-response > format. I haven=E2=80=99t written up a way to create a new transaction bu= ilding on > an old one (which I think is an important advanced use case), but it woul= d > amount to having a separate field in the initial transaction request to > have the transaction handle of the old transaction in it. > So the AS needs to understand that various combinations of fields to know if it is updating or creating a transaction. Seems like complicated logic at the AS to understand what the Client wants to do compared to a URI and HTTP method. > > Multiple access tokens cannot be refreshed separately in the current > implementation of XYZ. This is a noted gap in the spec, and I=E2=80=99m o= pen to > ideas on how it would be handled. > URIs for each authorization. :) > > > >> >>> >>> By using URIs and methods, XAuth has an easy to understand API for CRUD >>> operations on Grants and Authorizations. >>> >>> >>> +--------------+-----------+--------+-----------------------------+ >>> | request | http verb | uri | response | >>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>> | Create Grant | POST | GS URI | interaction, wait, or grant | >>> +--------------+-----------+--------+-----------------------------+ >>> | List Grants | GET | GS URI | grant list | >>> +--------------+-----------+--------+-----------------------------+ >>> | Verify Grant | PATCH | Grant | grant | >>> | | | URI | | >>> +--------------+-----------+--------+-----------------------------+ >>> | Read Grant | GET | Grant | wait, or grant | >>> | | | URI | | >>> +--------------+-----------+--------+-----------------------------+ >>> | Update Grant | PUT | Grant | interaction, wait, or grant | >>> | | | URI | | >>> +--------------+-----------+--------+-----------------------------+ >>> | Delete Grant | DELETE | Grant | success | >>> | | | URI | | >>> +--------------+-----------+--------+-----------------------------+ >>> | Read AuthZ | GET | AZ URI | authorization | >>> +--------------+-----------+--------+-----------------------------+ >>> | Update AuthZ | PUT | AZ URI | authorization | >>> +--------------+-----------+--------+-----------------------------+ >>> | Delete AuthZ | DELETE | AZ URI | success | >>> +--------------+-----------+--------+-----------------------------+ >>> | GS Options | OPTIONS | GS URI | metadata | >>> +--------------+-----------+--------+-----------------------------+ >>> | Grant | OPTIONS | Grant | metadata | >>> | Options | | URI | | >>> +--------------+-----------+--------+-----------------------------+ >>> | AuthZ | OPTIONS | AZ URI | metadata | >>> | Options | | | | >>> +--------------+-----------+--------+-----------------------------+ >>> >>> >>> >>> >>> While this looks good on paper, there are very pragmatic reasons that >>> many APIs have moved away from purely RESTful patterns over the last >>> decade, including limitations on what can be sent with GET and DELETE >>> requests, for example. I don=E2=80=99t think it=E2=80=99s as clean a wi= n as you=E2=80=99re >>> presenting it, but I think it=E2=80=99s worth checking out. >>> >> >> Agreed that RESTful does not work for everything. It does look like it >> maps well here. >> >> >> I disagree that it maps well. I think this is an over-application of a >> design pattern and the details will be problematic in implementation. >> > > What aspect does not map well? > > What do you think will be problematic? > > It seems much simpler to route a request based on URI and verb(XAuth), > then parse and inspect a JSON payload (XYZ) > > > See above. > I don't see what is problematic from above. Would you elaborate? > > > >> >> >> >>> >>> >>>> >>>> >>>>> >>>>> The modes in XAuth are much more limiting, as the mixing of different >>>>> interaction methods is already something that we need to start figuri= ng >>>>> out. Let=E2=80=99s say, for example, a client can do a redirect, acce= pt a >>>>> CIBA-style ping, or do a direct app2app communication. There=E2=80=99= s a natural >>>>> preference the client will have here: if it can talk to another app >>>>> directly, it=E2=80=99ll try that first. If that doesn=E2=80=99t work,= it can get a push >>>>> notification sent, and if all that fails, it can pop open a browser. = If >>>>> I have to pick just one of those modes when I make the request, then = the >>>>> client needs to make three different requests to the AS before I get >>>>> anything that works. >>>>> >>>> >>>> Have you read the revised draft? As I noted above, I have added >>>> negotiation. The Client can state all the modes it wants, the GS can >>>> respond with the modes it will support, and the Client can offer the U= ser >>>> any modes returned from the GS. >>>> >>>> >>>> Yes, did you read what I wrote? I think we=E2=80=99re talking past eac= h other. >>>> >>> >>> This is not how XAuth is written currently. The Client can list all of >>> the modes it wants to use. The Server will return all the modes that fi= t in >>> its policy for the Grant Request. Why would the Client need to make >>> different requests? >>> >>> per >>> >>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.2 >>> >>> >>> The interaction object contains one or more interaction mode objects pe= r >>> Section 5 >>> >>> Three modes are defined here: >>> >>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-5 >>> >>> More modes may defined in extensions, or in this document. >>> >>> >>> Yes, this is an improvement, and I=E2=80=99m glad you=E2=80=99re moving= your thinking in >>> this direction. However, it=E2=80=99s still not as clear how things com= bine to >>> solve different use cases, and it conflates the means of getting the us= er >>> TO the interaction page with the way of getting them BACK from it. It= =E2=80=99s >>> these flexible combinations that I think are important, and I don=E2=80= =99t think >>> XAuth gets this quite right yet. >>> >> >> I think how the user gets to and from the server is CRITICAL to the >> server if it wants to protect itself from a session fixation attack. >> See above where the client does not know what it can actually do that th= e >> server will allow. >> >> >> It is critical that the server knows how to protect itself, yes. It=E2= =80=99s not >> critical that the way there and the way back are tightly bound to each >> other in this way. I think that model is limiting. >> > > What other way back are you envisioning there could be besides a URI > redirect? > > Rolling between mobile apps is a URI redirect. What else could happen? > > I expect there will be new ways of transferring control to a GS, or that > the GS will reach out to the user directly. > > > Push notifications on a mobile platform, > Push notifications between the AS and a third party Client? How would that work? > COAP-style subscriptions at the HTTP layer, messages coming in over a > blockchain fabric through a separate entity=E2=80=A6 > I think you are mixing up how the client and AS communicate, with how the AS redirects the user back to the client. We already have a channel for the client and AS to communicate. The only reasons we need to get the user back is to protect from sessions fixation, and to provide a better experience. > > I think your view of what a client is and how it could communicate and > interact is limited, and that=E2=80=99s informing XAuth=E2=80=99s design. > I think your view of my view is limited. :) > > > >> >> >> >> >>> >>> It is an OR in that if the client is using the type "oauth_scope", they >>> cannot have an "authorization_details" attribute, they can only have "s= cope" >>> >>> If the client is using the type "oauth_rich", the client MUST >>> include "authorization_details", and MAY include "scope" >>> >>> I have updated the the doc to better capture that: >>> >>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.4.4 >>> >>> and example 2 now is of type "oauth_rich" >>> >>> https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-3.2 >>> >>> >>> It was not clear to me that both could be sent with that mode, so thank >>> you for updating that. But the client still has to choose one or the ot= her >>> up front. Why not have a mechanism that it can send both at all times? = Why >>> have a =E2=80=9Cmode=E2=80=9D type switch at all? XYZ allows clients to= make these combined >>> requests with a single consistent syntax. >>> >>> And by completely externalizing this to OAuth 2, I would argue that we >>> lose an opportunity to more clearly define how resources are described = and >>> used, and we inherit the same combination issues that are facing RAR to= day. >>> We can do better because we get to define the context. >>> >> >> This group can define a new syntax if it wants, and it will be >> unencumbered by the OAuth 2 and RAR legacy if deployments that want to u= se >> the OAuth 2 and RAR syntax can use them directly. Ie, there can be a typ= e >> "gnap" or some such. >> >> > You did not respond to this response. > > > What I=E2=80=99m proposing in XYZ is exactly the new syntax that incorpor= ates both > RAR and scope natively by using handles and polymorphic JSON. Other > resource request syntaxes could also be defined and added. > Unclear how polymorphic JSON helps with RAR and scope. My impression was that it signalled the difference between an array of resources vs a single resource. Your extension mechanism would be to add a JSON object at the top level, or inject it within the schema you are defining? IE, just use the extensibility of JSON? I think having the client clearly indicate the schema it is using is crisper and less likely to get wrong. Also, I think that the AS may want to know if the client is intending to be using only oauth_scopes, or has been updated to use RAR. =E1=90=A7 --000000000000304b0805a82880db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jun 10, 2020 at 7:54 AM Justi= n Richer <jricher@mit.edu> wro= te:

On = Jun 9, 2020, at 4:11 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Comments inline

Last item will be broken out to new thread.

On Tue, Jun 9, 2020 at 9:10 AM= Justin Richer <jri= cher@mit.edu> wrote:


On Jun 8, 2020= , at 5:33 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



On Mon, Jun 8, 2020 at 1:02 PM Justin Richer <<= a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>= wrote:

<snip>
A GS implementation can decide to only return an auth= orization from doing a GET on the AZ URL. Returning only an AZ URL is an op= tion in XAuth. Similarly, we could do the same for a Grant URI.=C2=A0
=

And that=E2=80=99s a lot= of complex code paths for both the GS and client to deal with. With more w= ays that it might happen, the client has to be prepared for any of them =E2= =80=94 and get them all right.=C2=A0
I don't see it being complex. The data either moves by refe= rence or by value. Both parties will have to enable support by reference. P= assing by value is an optimization so that the client does not have to make= an additional call.

=E2=80=9CBoth parties will have to enable=E2=80=9D is where the complexit= y comes into play. It=E2=80=99s putting a requirement on the client to anti= cipate several different ways to get the same information.

As I understand=C2=A0it, XYZ works the sa= me way. The client may get a handle to the transaction in an Interaction Re= sponse or a Wait Response, or the client receives a transaction response.

There could be only one way in XAuth (pass by refer= ence), but I expect that people will prefer an optimization of pass by valu= e when it can be done and deal with the complexity that they may get the da= ta in two different ways, just as in XYZ.

It=E2=80=99s not the same. What you=E2=80=99re missi= ng, I believe, is that this is one of the benefits of having a single endpo= int, as XYZ is defined today. The =E2=80=9Cgrant response=E2=80=9D comes fr= om exactly one place regardless of where in the transaction it happens. Thi= s is why I think this is something the working group as a whole needs to we= igh in on, to figure out the pros and cons of different designs. I personal= ly don=E2=80=99t like the complexity, and a definitely don=E2=80=99t like t= he restrictions imposed by XAuth today, but there are benefits that might o= utweigh and justify that move.=C2=A0
I think having a single endpoint is a disadvantage. The client = (and server) have to parse the JSON to understand what happened.=C2=A0

When the client wants to get a grant, it fetches the U= RL,=C2=A0as there is only one way for the client to ask for the grant. In X= YZ, the client creates some JSON that signals to the AS that it wants a gra= nt. Seems similar complexity on the client.=C2=A0

= But on the server, the server has to parse the JSON to understand what the = client wants to do.=C2=A0

I agree that the differe= nt published endpoints in OAuth 2 created additional complexity, but in XAu= th, there is only one published endpoints. All other URIs are that endpoint= with what could be considered parameters added for context.

=
=C2=A0

= =C2=A0

=C2=A0<snip>

=C2=A0

Using a diff= erent URI, optionally, isn=E2=80=99t the problem, and that could easily be = added to the. Removal of the separate handle is the problem I have with the= XAuth approach.

In XAuth= , the Grant URI is the GS URI=C2=A0+ TBD=C2=A0+ handle

=
Given we have asymmetric=C2=A0crypto as a requirement, it is unclear w= hat having two pieces of random signal=C2=A0provide.

Asymmetric crypto is an implementation re= quirement in both the input drafts but it isn=E2=80=99t a requirement in th= e charter, and there are likely symmetric use cases and key proofing mechan= isms that are going to be desirable for a lot of people.

=C2= =A0

=C2=A0

Additionally, I find XAuth=E2=80=99s re= strictions on the structure of the Grant URI potentially problematic, namel= y that it has to start with the server=E2=80=99s URL. This will lead to dep= loyments needing to bend their setups with proxies or redirectors to make t= hings fit, which you yourself have said is going to be an issue for things = like supporting a short redirect URL vs. a long redirect URL. Your complain= t there was one of latency and complexity, why does that not apply here? Bu= t most fundamentally, I do not see what value this restriction brings to th= e system. If the value is coming back from the GS endpoint, and the client = is getting all of its pointers from there, what=E2=80=99s the point of dict= ating how that has to look?

Requiring the Grant URI to start with the GS URI is open to discussion. = It is not clear to me why a deployment would need to have a redirector. Lar= ge scale deployments I have worked on have a router / proxy that routes req= uests to internal services. Having all the URIs start with the GS URI enabl= es all GNAP operations to be routed in the same place.

You still haven=E2=80=99t addressed why= you think that this is a reasonable requirement or assumption here but not= when dealing with long/short URLs for QR codes. What is the difference?

Short URLs generally use a = short host name as well as a short path.=C2=A0

Mos= t REST interfaces have the pattern I am proposing. A mental model many deve= lopers are familiar with.=C2=A0
This is assuming a lot on the part of the GS implementation, s= till, and all of my arguments stand.=C2=A0


That is not entirely correct.=C2= =A0A pre-registered = client can still pass its key by value, and a dynamic client can sti= ll use a (dynamically-acquired) handle. In all cases, the client is identif= ying itself by its key. The difference is how the server looks up that key = =E2=80=94 it=E2=80=99s either from the handle, or it=E2=80=99s from the key= value itself.=C2=A0

I don't understand=C2= =A0this.=C2= =A0

How is the Client authenticating that it is a = specific pre-registered client?
The client is identified by its key.
<= /blockquote>

And you think that will be an easy concept = for developers to migrate to from the mental model they have now? And what = is the value? I believe your proposal for other pre-registered clients to m= igrate was to use the Client ID as the Key Handle. So the Key Handle may re= present any of the pre-registered clients, but represents each instance of = a dynamic client. Does not seem like it is any different than how a Client = ID is used today.

Tom has started a new thread on = other aspects of this section.
Not only do I think OAuth developers can migrate, I think it= =E2=80=99s essential that we do in order to make this useful to non-OAu= th developers. Vast swaths of the internet are already building out key-bas= ed systems, not using OAuth. In my own experience, I can say for a fact tha= t the awkwardness of needing a client identifier ahead of time is one of th= e problems. The fact that there=E2=80=99s a place to use a legacy client ID= within the protocol is a bonus feature, and important for migration. But i= t=E2=80=99s even more important that it=E2=80=99s not=C2=A0

<= /div>
And we should look at history before we declare something impossi= ble. We managed to get web developers away from thinking about accessing an= API with a username and password and toward thinking in terms of accessing= it with a token. This is a shift of the same kind, and an important one at= that.

To me, this is one of the important fundame= ntal shifts of this work away from the limits of OAuth=E2=80=99s models and= assumptions, and one of the ones that will make this work applicable far o= utside of the space that OAuth 2 has already carved. I don=E2=80=99t see a = compelling reason to limit ourselves.

If your prim= ary goal is to keep OAuth 2 developers safe and happy, then in all honesty,= just keep using OAuth 2. Why wouldn=E2=80=99t you? Use PAR and RAR and DPo= P for advanced functionality. It=E2=80=99s a combination that, if a bit pat= ched-together, does work. Move to a new protocol when it does something you= can=E2=80=99t do, or it=E2=80=99s otherwise a better fit for what you=E2= =80=99re trying to solve. And when you=E2=80=99re in a position to move, th= ere=E2=80=99s a migration path. That doesn=E2=80=99t mean it=E2=80=99s a di= rect re-use, it means you can migrate =E2=80=94 move, change =E2=80=94 with= out tearing absolutely everything out. But you still need to move, and that= =E2=80=99s expected.=C2=A0

In all honesty, I think= the gap between OAuth 2 and XYZ is less than the gap between OAuth 1 and O= Auth 2, especially if you=E2=80=99re looking at using OAuth 2 with PAR, RAR= , etc. I don=E2=80=99t see a compelling reason to artificially limit the ne= w protocol with the constraints of the old, particularly when there=E2=80= =99s a migration path between them. XYZ can make use of some of the familia= r pieces of OAuth 2 without causing all clients to depend on them. That=E2= =80=99s the difference between migration and straight re-use.

Of course you think it is straightforw= ard. It is the mental model you made up!=C2=A0

I a= gree we should not artificially limit the new protocol, but there is also n= o need to burn everything down because we can.


=C2=A0

=C2=A0<snip>
In XAuth, if the server wants to protect itself f= rom a session fixation attack in a given request, and it wants to support b= oth "redirect" and "user_code" modes,=C2=A0
t= he server will return only those two modes and not "indirect". Th= e=C2=A0

In XAuth, if the server wants to prot= ect itself from a session fixation attack in a given request, and it wants = to support both "redirect" and "user_code" modes,=C2=A0=
the server MUST return=C2=A0callback, redirect,= and user_code. The client does not know that the "indirect" mode= is not supported, and may try that.

=

In XYZ, if the server wants to protect aga= inst a session fixation attack, it will reject a request that doesn=E2=80= =99t have a =E2=80=9Ccallback=E2=80=9D field in it. The AS always gets to c= hoose which things it supports for any given request. If the client wants t= o support both =E2=80=9Credirect=E2=80=9D and =E2=80=9Cuser_code=E2=80=99 m= odes AND has the ability to handle session fixation issues, it sends the = =E2=80=9Credirect=E2=80=9D, =E2=80=9Cuser_code=E2=80=99, and =E2=80=9Ccallb= ack=E2=80=9D fields in its interaction request.=C2=A0

If the client chooses to present the interacti= on_url as a scannable barcode, which is an option if it receives=C2=A0one, = it will then get an error when it tries to do a transaction continue reques= t as the AS protects itself. Unfortunately the user has scanned the barcode= and is now at the AS. I don't see how the client learns it is not able= to do what I call an "indirect" mode interaction. Would you expl= ain how this situation is prevented in XYZ?

If the client has made a request with =E2=80=9Cred= irect=E2=80=9D and =E2=80=9Ccallback=E2=80=9D in its request, and then deci= des to display the interaction URL as a scannable code, then the AS will ju= st redirect to the client=E2=80=99s callback URL when it=E2=80=99s done, wh= atever that URL was. If the client sends a =E2=80=9Ccallback=E2=80=9D URL t= hat it can=E2=80=99t get information from, then that=E2=80=99s a poorly-wri= tten client, isn=E2=80=99t it?

Let me provide more clarity on the scenario.

The client is a web app that can redirect the user to the AS, and receive = a callback, it can display a code and URI to enter the code, or it can show= a scannable code for the user to scan on their mobile phone. The user may = be using the web app on a PC, and the AS is on their phone. The user choose= s to scan the barcode=C2=A0with their phone. After authenticating with the = AS, the AS redirects back to the callback URL. But the webpage is now on th= e user's mobile device, not the web app on the PC.
=C2=A0

If the client can=E2=80=99t get= to the information in the callback URL unless it=E2=80=99s on the same dev= ice, then the client isn=E2=80=99t going to show the user a scannable code = to be read by a secondary device. Why would it?

Because it is a better experience for the user per a= bove.=C2=A0

The AS parameters don't differenti= ate between a scannable URL and a URL that can only be redirected, so the c= lient will think it can do anything.=C2=A0

Additio= nally, in XAuth, the client can provide an informational URI for the AS to = redirect after a scannable code or a user code flow.=C2=A0

=C2=A0
=C2=A0


<snip>
=C2=A0

=

For ex= ample:=C2=A0

How is a transaction updated?=C2=A0
How are separate access tokens refreshed?=C2=A0
Refreshi= ng an access token in XYZ returns a full transaction response per Section 9= .3 which refers to Section 8.
Would you ad= dress these questions?

<= div>Transactions are updated by sending the transaction handle back with ad= ditional information. This is no different from the request made after a fr= ont channel callback, or what would be made in a challenge-response format.= I haven=E2=80=99t written up a way to create a new transaction building on= an old one (which I think is an important advanced use case), but it would= amount to having a separate field in the initial transaction request to ha= ve the transaction handle of the old transaction in it.=C2=A0

So the AS needs to understand that var= ious combinations of fields to know if it is updating or creating a transac= tion. Seems like complicated logic at the AS to understand what the Client = wants to do compared to a URI and HTTP method.=C2=A0
=C2=A0

Multiple access tokens cannot= be refreshed separately in the current implementation of XYZ. This is a no= ted gap in the spec, and I=E2=80=99m open to ideas on how it would be handl= ed.

URIs for each authori= zation. :)
=C2=A0

=
=C2=A0

<= div>
By using URIs and methods, XAuth has an easy to und= erstand API for CRUD operations on Grants and Authorizations.

    +--------------+---------=
--+--------+-----------------------------+
    | request      | http verb | uri    | response                    |
    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
    | Create Grant | POST      | GS URI | interaction, wait, or grant |
    +--------------+-----------+--------+-----------------------------+
    | List Grants  | GET       | GS URI | grant list                  |
    +--------------+-----------+--------+-----------------------------+
    | Verify Grant | PATCH     | Grant  | grant                       |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read Grant   | GET       | Grant  | wait, or grant              |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Update Grant | PUT       | Grant  | interaction, wait, or grant |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Delete Grant | DELETE    | Grant  | success                     |
    |              |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | Read AuthZ   | GET       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Update AuthZ | PUT       | AZ URI | authorization               |
    +--------------+-----------+--------+-----------------------------+
    | Delete AuthZ | DELETE    | AZ URI | success                     |
    +--------------+-----------+--------+-----------------------------+
    | GS Options   | OPTIONS   | GS URI | metadata                    |
    +--------------+-----------+--------+-----------------------------+
    | Grant        | OPTIONS   | Grant  | metadata                    |
    | Options      |           | URI    |                             |
    +--------------+-----------+--------+-----------------------------+
    | AuthZ        | OPTIONS   | AZ URI | metadata                    |
    | Options      |           |        |                             |
    +--------------+-----------+--------+-----------------------------+
=C2=A0

While this looks good on paper, there are very pragmatic reasons that many= APIs have moved away from purely RESTful patterns over the last decade, in= cluding limitations on what can be sent with GET and DELETE requests, for e= xample. I don=E2=80=99t think it=E2=80=99s as clean a win as you=E2=80=99re= presenting it, but I think it=E2=80=99s worth checking out.

Agreed that RESTful does not work for everyth= ing. It does look like it maps well here.

I disagree that it maps well. I think this is an ove= r-application of a design pattern and the details will be problematic in im= plementation.

What aspect= does not map well?

What do you think will be prob= lematic?

It seems much simpler to route a request = based on URI and verb(XAuth), then parse and inspect a JSON payload (XYZ)

See above.

I don't see what is problemati= c from above. Would you elaborate?
=C2=A0
=

=C2=A0

=C2=A0


=C2=A0

The modes i= n XAuth are much more limiting, as the mixing of different interaction meth= ods is already something that we need to start figuring out. Let=E2=80=99s = say, for example, a client can do a redirect, accept a CIBA-style ping, or = do a direct app2app communication. There=E2=80=99s a natural preference the= client will have here: if it can talk to another app directly, it=E2=80=99= ll try that first. If that doesn=E2=80=99t work, it can get a push notifica= tion sent, and if all that fails, it can pop open a browser.=C2=A0If I have to pick just = one of those modes when I make the request, then the client needs to make t= hree different requests to the AS before I get anything that works.=C2=A0

Have you read the r= evised draft? As I noted above, I have added negotiation. The Client can st= ate all the modes it wants, the GS can respond with the modes it will suppo= rt, and the Client can offer the User any modes returned from the GS.
=

Yes, did you read what I= wrote? I think we=E2=80=99re talking past each other.

This=C2=A0is not how XAuth is written currently. The= Client can list all of the modes it wants to use. The Server will return a= ll the modes that fit in its policy for the Grant Request. Why would the Cl= ient need to make different requests?

per


The interaction object contains one or more interaction mode objects= per Section 5

Three modes are defined here:


Mo= re modes may defined in extensions, or in this document.
<= /div>

Yes, this is an improvement, and I=E2= =80=99m glad you=E2=80=99re moving your thinking in this direction. However= , it=E2=80=99s still not as clear how things combine to solve different use= cases, and it conflates the means of getting the user TO the interaction p= age with the way of getting them BACK from it. It=E2=80=99s these flexible = combinations that I think are important, and I don=E2=80=99t think XAuth ge= ts this quite right yet.=C2=A0

I think how the user gets to and from the server is CRITICAL to the s= erver if it wants to protect itself from a session fixation attack.
See above where the client does not know what it can actually do that th= e server will allow.

It is critical that the server knows how to protect itself, yes. It=E2=80= =99s not critical that the way there and the way back are tightly bound to = each other in this way. I think that model is limiting.

What other way back are you envisioning ther= e could be besides a URI redirect?

Rolling between= mobile apps is a URI redirect. What else could happen?

I expect there will be new ways of transferring control to a GS, or t= hat the GS will reach out to the user directly.

<= /div>

Push notifications on a mobile = platform,

Push notificat= ions between the AS and a third party Client? How would that work?
=C2=A0
COAP-style subscriptions at the H= TTP layer, messages coming in over a blockchain fabric through a separate e= ntity=E2=80=A6

I think yo= u are mixing up how the client and AS communicate, with how the AS redirect= s the user back to the client. We already have a channel for the client and= AS to communicate. The only reasons we need to get the user back is to pro= tect from sessions fixation, and to provide a better experience.
= =C2=A0

I think your view of = what a client is and how it could communicate and interact is limited, and = that=E2=80=99s informing XAuth=E2=80=99s design.

I think your view of my view is limited. :)
=C2=A0

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

=C2=A0<= /div>
<snip>

It is an OR in that if the client is using= the type "oauth_scope", they cannot have an "authorization_= details" attribute, they can only have "scope"
If the client is using the type "oauth_rich", the cli= ent MUST include=C2=A0"authorization_details", and MAY include &q= uot;scope"
=C2=A0
I have updated the the doc to be= tter capture that:


and example 2 now is of type "oauth_rich&quo= t;



It was not clear to me = that both could be sent with that mode, so thank you for updating that. But= the client still has to choose one or the other up front. Why not have a m= echanism that it can send both at all times? Why have a =E2=80=9Cmode=E2=80= =9D type switch at all? XYZ allows clients to make these combined requests = with a single consistent syntax.

And by completely= externalizing this to OAuth 2, I would argue that we lose an opportunity t= o more clearly define how resources are described and used, and we inherit = the same combination issues that are facing RAR today. We can do better bec= ause we get to define the context.

<= /div>
This group can define a new syntax if it wants, and it will be un= encumbered by the OAuth 2 and RAR legacy if deployments that want to use th= e OAuth 2 and RAR syntax can use them directly. Ie, there can be a type &qu= ot;gnap" or some such.

You did not respond to this response.=C2= =A0


= What I=E2=80=99m proposing in XYZ is exactly the new syntax that incorporat= es both RAR and scope natively by using handles and polymorphic JSON. Other= resource request syntaxes could also be defined and added.

Unclear how polymorphic JSON helps with = RAR and scope. My impression was that it signalled the difference between a= n array of resources vs a single resource.

Your ex= tension mechanism would be to add a JSON object at the top level, or inject= it within the schema you are defining? IE, just use the extensibility of J= SON?

I think having the client clearly indicate th= e schema it is using is crisper and less likely to get wrong.=C2=A0

Also, I think that the AS may want to know if the client = is intending to be using only oauth_scopes, or has been updated to use RAR.= =C2=A0
=C2=A0
3D""=E1=90=A7
--000000000000304b0805a82880db-- From nobody Mon Jun 15 17:39:15 2020 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 7617B3A0F26 for ; Mon, 15 Jun 2020 17:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 dX8RUc4MC08Y for ; Mon, 15 Jun 2020 17:39:11 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54BE3A0F24 for ; Mon, 15 Jun 2020 17:39:10 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id i27so21374265ljb.12 for ; Mon, 15 Jun 2020 17:39:10 -0700 (PDT) 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=JMjL/C0+mLyqFpWM5hFbYL2GA7+XkuR27rVBCvr/qMM=; b=FWXpPsyvdJITYMJyGc9ha2msRM5YHmqrrbrpRuD094cILnjD0Uwk4WUEYF9gAyBBT6 oNzjvQ3X/dxOO5SQ0dhUKP3UiaKYuoKjOl7jES9Vp5wspPPLbD/8Lpy9pigQIIeVD6dL llSbDxJ+YRnfQD2B38lDLz4cU2cCn1QqlwHw7h7kRXoz4voZPpedL/VCvH7st/RUXjSP 5cjIjhufC9/uyF2WnFHMllry+qbUpaAhLXAksEh2ZYNs+23mIuxyiTJvVLxlwYCtKgNE yv7UDpKVeH2mrXAHEFFUX4eO9RHEsSgaNFJBdLrD5LbdWLTsjYm1/uMYP9P375NhqP5t ex6A== 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=JMjL/C0+mLyqFpWM5hFbYL2GA7+XkuR27rVBCvr/qMM=; b=A7zegYJDXMFO+QCVq+bzIvE+GR+auiIw54jHzUZYFfNF7tZEA8TTEwuR4RxZK8DWNp hUiNGJuOKVd8M4zFkHHSCTZ0hvfZ7jrqCNbB0Kp5xK1f0xHu5lhbazFldARozQb9mcva nBr4AClV/tW/eutRg0vDsaEbrZ9SkZwL1JbBq3teyKylIAGDWBglnwIY/X2X/iuuxc3g s1s+t6g00omew4xs4/R4EI5ho8JUeq3Ocw4E7yeRvIUMQIvFBDTMOyMFw62Bmp72D7pN RaYcux2Wo8moH2rUMl6sofFxazpZPxwpHVUaGk+wypsXXn65LzNWCJpJHURvs0WIVZBv wgQw== X-Gm-Message-State: AOAM531QXQv0AZJxxzin6RiQfHAaCh45eG9/n+Oelt1jKSu1DDte2NQd pzpSAmTUzkshins5iIiGL8Rl10IatWdeRMIMEMY= X-Google-Smtp-Source: ABdhPJy4wLVgzWK3jL+njIEwEB1kd8NWD1EE/tLBN/8rzTpmDJLZ4qxZ+POGGU/+wxzl0HdwSokpOcpbW/1cXG4rpbY= X-Received: by 2002:a05:651c:3cc:: with SMTP id f12mr125422ljp.244.1592267948769; Mon, 15 Jun 2020 17:39:08 -0700 (PDT) MIME-Version: 1.0 References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> <083D078A-10B2-4764-BEC9-AD9A783512CD@mit.edu> In-Reply-To: <083D078A-10B2-4764-BEC9-AD9A783512CD@mit.edu> From: Dick Hardt Date: Mon, 15 Jun 2020 17:38:42 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org, Mike Jones Content-Type: multipart/alternative; boundary="00000000000079453405a828c59b" Archived-At: Subject: Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs XAuth-08) 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, 16 Jun 2020 00:39:13 -0000 --00000000000079453405a828c59b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable comments inline ... On Wed, Jun 10, 2020 at 8:07 AM Justin Richer wrote: > > > On Jun 9, 2020, at 4:14 PM, Dick Hardt wrote: > > Forking this topic to a new thread > > +Mike as he has expressed concern about creating new identity claims > > On Tue, Jun 9, 2020 at 9:10 AM Justin Richer wrote: > >> >> >> On Jun 8, 2020, at 5:33 PM, Dick Hardt wrote: >> >> >> >> On Mon, Jun 8, 2020 at 1:02 PM Justin Richer wrote: >> >> > >> I don't follow how this would work. Perhaps you could provide an example >>> in JSON? >>> >>> >>> One method is defining a new value inside the XYZ =E2=80=9Cclaims=E2=80= =9D request >>> object that maps to a specific sub-schema: >>> >>> claims: { >>> =E2=80=9Csubject=E2=80=9D: true, >>> =E2=80=9Cemail=E2=80=9D: true, >>> =E2=80=9Coidc=E2=80=9D: { >>> "userinfo": >>> { >>> "given_name": {"essential": true}, >>> "nickname": null, >>> "email": {"essential": true}, >>> "email_verified": {"essential": true}, >>> "picture": null, >>> "http://example.info/claims/groups": null >>> }, >>> "id_token": >>> { >>> "auth_time": {"essential": true}, >>> "acr": {"values": ["urn:mace:incommon:iap:silver"] } >>> } >>> } >>> } >>> >>> >>> That should look pretty familiar. Alternatively, this could be done wit= h >>> a separate top-level request object field: >>> >>> >>> claims: { >>> =E2=80=9Csubject=E2=80=9D: true, >>> =E2=80=9Cemail=E2=80=9D: true >>> }, >>> =E2=80=9Coidc_claims_request=E2=80=9D: { >>> "userinfo": >>> { >>> "given_name": {"essential": true}, >>> "nickname": null, >>> "email": {"essential": true}, >>> "email_verified": {"essential": true}, >>> "picture": null, >>> "http://example.info/claims/groups": null >>> }, >>> "id_token": >>> { >>> "auth_time": {"essential": true}, >>> "acr": {"values": ["urn:mace:incommon:iap:silver"] } >>> } >>> } >>> >>> >>> In both cases the AS is going to need to knit them together into a >>> sensible request policy, especially since the OIDC claims query languag= e >>> has overlapping implications to one particular resource, the UserInfo >>> endpoint. My contention wasn=E2=80=99t with your proposed solution, my = contention >>> was you claiming that XYZ has a fixed schema and is therefore limited i= n >>> extensibility. >>> >> >> One of the objectives of this work is to have extension points. My point >> was that XAuth had a clear extension point for adding schemas. How to >> extend XYZ was not clear in your proposal. >> >> >> I am sorry that the extensibility of the protocol was not clear. It is >> stated in each section that additional items can be added, and I have >> stated repeatedly that it=E2=80=99s extensible and demonstrated how, her= e on this >> list. >> >> I think the XAuth proposal is better than the two examples you proposed. >> In your first example, the schema is a second class schema, and in your >> second example, claims are spread across to top level options. Both of >> these pollute other schemas. >> >> >> Not surprisingly, I disagree about the cleanliness of XAuth=E2=80=99s pr= oposed >> approach. The proposal here adds external schemas as extensions instead = of >> relying on them internally. >> >> If anything, I think that the OpenID Foundation would be the ones to >> define how to make an OIDC claims request using this protocol, not us, >> since they own and control that query syntax and everything it implies. = We >> can provide a means of extension. >> >> I also think there=E2=80=99s value in defining a set of core interoperab= le >> identity fields, which themselves could also be extended. >> >> All of these mechanisms should be controlled by some combination of >> registries and collision-resistant namespaces, which is the approach I= =E2=80=99ve >> taken for extensibility throughout XYZ. >> > > > JSON by its nature is extensible. Adding new members to an object is > straight forward. XYZ is not unique here. It sounds like your idea of > extensibility is telling people that they can add new members to JSON. Of > course they can. That is like saying you can add new query parameters to = a > front channel OAuth 2 request. > > > Yes, exactly. And that=E2=80=99s exactly how OAuth 2 has been extended. I= =E2=80=99m glad > you see that now. > I think you are missing my point. Adding query parameters to OAuth 2 was not a defined extension point. It was inherent in how query parameters work. OAuth 2 did define the type of grant as an extension point. > > My concern was that XYZ does not have a clear way to add new identity > claim schemas. You have two examples, add a schema as a member of the > claims object, which is mixing claims with schema extensions, or adding a > root member, which is then putting claims into more than one place. It is > not clear where to add a new schema, so we could easily end up with new > schemas in both places. That sounds confusing. > > > In XAuth, the members of the claims object are the schema. Adding a new > schema is done one, consistent way. > > > I provided a couple examples off the cuff of possible ways to extend > something, as your base claim was that XYZ could not be extended with new > or external query schemas. Of the two, I think that it makes more sense f= or > it to be a separate top-level object. Why? Because the OIDC =E2=80=9Cclai= ms=E2=80=9D > request syntax not only dictates claims within the OIDC schema, it also > specifies how the information comes back. The XYZ claims request talks > about information that comes back in the XYZ claims section of the > response. > I would put the OIDC request to acquire claims from a user_info endpoint into the authorization request so that there is a consistent way to get back an access token, as opposed to a new top level object that could return claims and/or an access token. > Since the OIDC request allows for targeting specifically to the ID token > and UserInfo Endpoint, I think it is much cleaner to be at the top level = as > its own thing. > My point is that XYZ does not *define* how to add new schemas. An extension can add anything it wants to the JSON, and as you have shown there is more than one way to do it, and I think long term when there are divergent mechanisms, the code is going to get ugly in detecting what claims are being asked for. > > wrt. "defining a set of core interoperable identity fields", the charter > says we should be NOT develop a new schema: > > The group is chartered to develop mechanisms for conveying identity > information within the protocol including identifiers (such as email > addresses, phone numbers, usernames, and subject identifiers) and > assertions (such as OpenID Connect ID Tokens, SAML Assertions, and > Verifiable Credentials). The group is not chartered to develop new > formats for identifiers or assertions, nor is the group chartered to > develop schemas for user information, profiles, or other identity > attributes, unless a viable existing format is not available. > > > wrt. OIDC claims, the charter explicitly calls out developing mechanisms > for conveying ... OIDC ID Tokens. > > =E1=90=A7 > > > Precisely: the charter says we will have a way to convey identifiers and > assertions. The XYZ =E2=80=9Cclaims=E2=80=9D section lists identifiers th= at can come back, > in plain text, and assertions, that can also come back along side them. > These claims are a schema. We will have an IANA entry for what claims are allowed inside of the claims object. This is defining a new schema. > It=E2=80=99s not a full query language and isn=E2=80=99t intended to be, = and I think that > it would actually be dangerous for this to be a full identity schema, but > it is itself extensible internally if someone wants to do that. Claiming > that a list of identifiers is =E2=80=9Cdeveloping a new schema=E2=80=9D i= s an argument > several bridges too far from reality. > You are not inventing new identifiers, but you will be defining which strings are being used to represent which concepts. FOr example you have "email" vs "email_address", or any other string combination that a human would likely interpret as an email like object. Then there is specifying what can be in the field. > I picked a couple examples out of thin air, with the idea that we=E2=80= =99d > bikeshed them eventually and tie them to a registry. We might want to > re-use a set of identifiers here, and for that I actually like Annabelle > Backman=E2=80=99s proposal to the SECEVENT group better than most that I= =E2=80=99ve seen in > the space: > > https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers > That is one schema. And it has advantages for the subject identifiers, but obviously does not cover the wide array of other identity attributes. Why would we not want to reuse existing schemas? And support all of them? =E1=90=A7 --00000000000079453405a828c59b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
comments inline ...=C2=A0

On Wed, Jun 10, = 2020 at 8:07 AM Justin Richer <jriche= r@mit.edu> wrote:


On Jun 9, 2020, at 4:14 PM, Dick Hardt <dick.hardt@gmail.com>= ; wrote:

Forking this topic= to a new thread

+Mike as he has e= xpressed concern about creating new identity claims

On Tue, J= un 9, 2020 at 9:10 AM Justin Richer <jricher@mit.edu> wrote:


On Jun 8, 2020, at 5:33 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
<= br>


On Mon, Jun 8, 2020 at 1:02 P= M Justin Richer <jr= icher@mit.edu> wrote:
<sni= p>=C2=A0
I don= 9;t follow how this would work. Perhaps you could provide an example in JSO= N?

One method is de= fining a new value inside the XYZ =E2=80=9Cclaims=E2=80=9D request object t= hat maps to a specific sub-schema:

claims: {=
=C2=A0 =C2=A0=E2=80=9Csubject=E2=80=9D: true,
=C2=A0 =C2=A0=E2=80=9Cemail=E2=80=9D: true,
<= div>=C2=A0 =C2=A0=E2=80=9Coidc=E2=80=9D: {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0"userinfo":
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quo= t;given_name": {"essential": true},
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"nickname": null,
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"email": {"essential&= quot;: true},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"= email_verified": {"essential": true},
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"picture": null,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"http://example.info/claims/groups&q= uot;: null
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },
<= div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0"id_token":
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0"auth_time": {"essential": true},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"acr": {"val= ues": ["urn:mace:incommon:iap:silver"] }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }=
}

Th= at should look pretty familiar. Alternatively, this could be done with a se= parate top-level request object field:


<= div>
<= div>
claims: {
=C2=A0 =C2=A0=E2=80=9Csubject=E2=80= =9D: true,
=C2=A0 =C2=A0=E2=80=9Cemail=E2=80=9D: true<= /div>
},
=E2=80=9Coidc_claims_request=E2=80=9D: {<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0"userinfo":
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&= quot;given_name": {"essential": true},
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0"nickname": null,
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0"email": {"essential": true},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"email_verified": {"= essential": true},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"p= icture": null,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"http://example.i= nfo/claims/groups": null
=C2=A0 =C2=A0 =C2=A0 =C2=A0 },<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0"id_token":
=C2=A0= =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"a= uth_time": {"essential": true},
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0"acr": {"values": ["urn:mace:inco= mmon:iap:silver"] }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
= }

In both cases the = AS is going to need to knit them together into a sensible request policy, e= specially since the OIDC claims query language has overlapping implications= to one particular resource, the UserInfo endpoint. My contention wasn=E2= =80=99t with your proposed solution, my contention was you claiming that XY= Z has a fixed schema and is therefore limited in extensibility.
=

One of the objectives of this work i= s to have extension points. My point was that XAuth had a clear extension p= oint for adding schemas. How to extend XYZ was not clear in=C2=A0your propo= sal.


I am sorry that the extensibility of the protocol was not clear. It is sta= ted in each section that additional items can be added, and I have stated r= epeatedly that it=E2=80=99s extensible and demonstrated how, here on this l= ist.=C2=A0
I think the XAuth proposal is better than the two = examples you proposed. In your first example, the schema is a second class = schema, and in your second example, claims are spread across to top level o= ptions. Both of these pollute other schemas.


Not surprisingly, I disagree about= the cleanliness of XAuth=E2=80=99s proposed approach. The proposal here ad= ds external schemas as extensions instead of relying on them internally.=C2= =A0

If anything, I think that the OpenID Foundatio= n would be the ones to define how to make an OIDC claims request using this= protocol, not us, since they own and control that query syntax and everyth= ing it implies. We can provide a means of extension.

I also think there=E2=80=99s value in defining a set of core interoperab= le identity fields, which themselves could also be extended.=C2=A0
All of these mechanisms should be controlled by some combi= nation of registries and collision-resistant namespaces, which is the appro= ach I=E2=80=99ve taken for extensibility throughout XYZ.
<= /blockquote>


JSON by its nature is extens= ible. Adding new members to an object is straight forward. XYZ is not uniqu= e here. It sounds like your idea of extensibility=C2=A0is telling people th= at they can add new members to JSON. Of course they can. That is like sayin= g you can add new query parameters to a front channel OAuth 2 request.


Yes, exa= ctly. And that=E2=80=99s exactly how OAuth 2 has been extended. I=E2=80=99m= glad you see that now.

I= think you are missing my point. Adding query parameters to OAuth 2 was not= a defined extension point. It was inherent in how query parameters work. O= Auth 2 did define the type of grant as an extension point.=C2=A0
= =C2=A0

My concern was that XYZ does not= have a clear way to add new identity claim schemas. You have two examples,= add a schema as a member of the claims object, which is mixing claims with= schema extensions, or adding a root member, which is then putting claims i= nto more than one place. It is not clear where to add a new schema, so we c= ould easily end up with new schemas in both places. That sounds confusing.= =C2=A0

In XAuth, the members of the claims ob= ject are the schema. Adding a new schema is done one, consistent way.
=

I provided a couple exam= ples off the cuff of possible ways to extend something, as your base claim = was that XYZ could not be extended with new or external query schemas. Of t= he two, I think that it makes more sense for it to be a separate top-level = object. Why? Because the OIDC =E2=80=9Cclaims=E2=80=9D request syntax not o= nly dictates claims within the OIDC schema, it also specifies how the infor= mation comes back. The XYZ claims request talks about information that come= s back in the XYZ claims section of the response.

I would put the OIDC request to acquire claims fr= om a user_info endpoint into the authorization request so that there is a c= onsistent way to get back an access token, as opposed to a new top level ob= ject that could return claims and/or an access token.
=C2=A0
Since the OIDC request allows for targeting spe= cifically to the ID token and UserInfo Endpoint, I think it is much cleaner= to be at the top level as its own thing.=C2=A0

My point is that XYZ does not define how to a= dd new schemas. An extension can add anything it wants to the JSON, and as = you have shown there is more than one way to do it, and I think long term w= hen there are divergent mechanisms, the code is going to get ugly in detect= ing what claims are being asked for.=C2=A0




wrt. "defining a set = of core interoperable identity fields", the charter says we should be = NOT develop a new schema:

The group is chartered to develop mechanisms = for conveying identity information within the protocol including ide= ntifiers (such as email addresses, phone numbers, usernames, and subject id= entifiers) and assertions (su= ch as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Cred= entials). The group is not = chartered to develop new formats for identifiers or assertions, nor is the = group chartered to develop schemas for user information, profiles, or other= identity attributes, unless a viable existing format is not available.

= wrt. OIDC claims, the charter explicitly calls out developing mechanisms for conveying ... OIDC ID Token= s.

3D""=E1=90=A7

Precisely: the charter says we will have = a way to convey identifiers and assertions. The XYZ =E2=80=9Cclaims=E2=80= =9D section lists identifiers that can come back, in plain text, and assert= ions, that can also come back along side them.

These claims are a schema. We will have an IANA entry for w= hat claims are allowed inside of the claims object. This is defining a new = schema.
=C2=A0
It=E2=80=99s not a ful= l query language and isn=E2=80=99t intended to be, and I think that it woul= d actually be dangerous for this to be a full identity schema, but it is it= self extensible internally if someone wants to do that. Claiming that a lis= t of identifiers is =E2=80=9Cdeveloping a new schema=E2=80=9D is an argumen= t several bridges too far from reality.

<= /div>
You are not inventing new identifiers, but you will be defining w= hich strings are being used to represent which concepts. FOr example you ha= ve "email" vs "email_address", or any other string comb= ination that a human would likely interpret as an email like object.=C2=A0 = Then there is specifying what can be in the field.
=C2=A0
I picked a couple examples out of thin air, with th= e idea that we=E2=80=99d bikeshed them eventually and tie them to a registr= y. We might want to re-use a set of identifiers here, and for that I actual= ly like Annabelle Backman=E2=80=99s proposal to the SECEVENT group better t= han most that I=E2=80=99ve seen in the space:


That is one sch= ema. And it has advantages for the subject identifiers, but obviously does = not cover the wide array of other identity attributes.

=
Why would we not want to reuse existing schemas? And support all of th= em?

=C2=A0

3D""=E1=90=A7
--00000000000079453405a828c59b-- From nobody Mon Jun 15 17:48:27 2020 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 105B53A0F2B for ; Mon, 15 Jun 2020 17:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 bdJysMc0P7WF for ; Mon, 15 Jun 2020 17:48:22 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D786A3A0F2D for ; Mon, 15 Jun 2020 17:48:21 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id y11so21467507ljm.9 for ; Mon, 15 Jun 2020 17:48:21 -0700 (PDT) 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=+0zHhp66C7cCIoww9sMX2KibHAVWjNg8B2gpQNmsU38=; b=nzJXh+kgZ609yWOk4G6Ah3kBswda60igRnFSppX2wD2/lyTkg1Jm36qfbPcJkmKpT7 khSuG7OuDzQd2X+XU4G4xQgJxCIXqKClV0JppknN64JY8yZODT2w17v6nxXcLUkRjwwp RngUbDC7LDcb/3JlGuZcrx79/BTXbp6yu0y4BJVknD0oF2wC6yTboriWOcYHw8X6n/pg ZtwbP2BdeiMEpTCrA8uJ7YtIXbTqn9fm/QfM205lKNW8LL9hwZy+7j7cI+MAkNpUy9+Z YAeE7ByZu9fmgLtl9p36AuZP9UsHM7Svvfz3U7xWeJ/UZ/ITPHsMOwhhfO8uWzivmFSm sAfA== 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=+0zHhp66C7cCIoww9sMX2KibHAVWjNg8B2gpQNmsU38=; b=RPdiLeOe6WN1kVvXCrvlIHFDDpQrzZAPrDZozFHEGhLH2Nro5SVMSty/wdlOpKv9gl Vd03gMnf1VLjmSOOxh125ZXkzCmVR1cVtPDxYeF/MZIEbfUGs/GHQ+LuX+tpMPySFFH5 19DRKeNqeclNL1nUwjLRIi5UceVoXHuFRlejoNjuswlcvJA98tsqPXQkSTIPFNLC77he Ee53M6eTwloFQ+0WYi/7gbCpPRU3+yqtEB7pFi4B5Exg4jqeW+b82RyY2hTEIdcnejXS n5zVZYWOFnLQreEzehckXDpHZEVSV3Z8Dyhl9NVaKLm9L0CrLb4CLvRQ8i+hPPPDQPeD imoQ== X-Gm-Message-State: AOAM533OL19Cc8SXe7w94KIY8otmdMhI7ijUj/cPjvw8eQNn57A4Ivzx UTAOLbXiAoDinixxr8jzGfrdcYIX8Dv+k4m/+R+fyWlX6CI= X-Google-Smtp-Source: ABdhPJz33d+kObfI9XO020BKo4lCJIQY0rGhWmx3ReHcRTFeHyAzyKer1ktac55qp4/VUgY2DtZHzBYs8BI+E3NwHWE= X-Received: by 2002:a2e:6a11:: with SMTP id f17mr125879ljc.109.1592268499831; Mon, 15 Jun 2020 17:48:19 -0700 (PDT) MIME-Version: 1.0 References: <44332CBC-83B1-411C-B518-EE2F3D030301@mit.edu> <01A1051E-30AB-419B-A0F1-C9AED6BFA357@mit.edu> <3D57381A-DA98-4DD7-8960-A6D94A643E43@mit.edu> <20200614044940.GE11992@kduck.mit.edu> In-Reply-To: From: Dick Hardt Date: Mon, 15 Jun 2020 17:47:53 -0700 Message-ID: To: Justin Richer Cc: Benjamin Kaduk , txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000051d39005a828e6af" Archived-At: Subject: Re: [Txauth] XYZ-08 vs XAuth-08 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, 16 Jun 2020 00:48:25 -0000 --00000000000051d39005a828e6af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable comments inline ... On Sun, Jun 14, 2020 at 10:21 AM Justin Richer wrote: > Hi, Ben -- > > > On Jun 14, 2020, at 12:49 AM, Benjamin Kaduk wrote: > > > > One more point, while I'm catching up on the thread... > > > > On Tue, Jun 09, 2020 at 12:10:40PM -0400, Justin Richer wrote: > >> > >> > >>> On Jun 8, 2020, at 5:33 PM, Dick Hardt wrote: > >>> > >>> That is not entirely correct. A pre-registered client can still pass > its key by value, and a dynamic client can still use a > (dynamically-acquired) handle. In all cases, the client is identifying > itself by its key. The difference is how the server looks up that key =E2= =80=94 > it=E2=80=99s either from the handle, or it=E2=80=99s from the key value i= tself. > >>> > >>> I don't understand this. > >>> > >>> How is the Client authenticating that it is a specific pre-registered > client? > >> > >> The client is identified by its key. There is no external client > identifier. I think you=E2=80=99re confused because you=E2=80=99re still = thinking in terms > of OAuth 2=E2=80=99s client ID based model and I am trying to move us pas= t that. It > took me time to realize that we really can let it go, so hopefully this i= s > helpful in explaining why. > >> > >> When a credential is cryptographically random enough to be unique, it > can be used as its own identifier, particularly when you don=E2=80=99t ne= ed to > identify the entity outside of the context that it can present and prove > its credential. To stretch a metaphor, passwords don=E2=80=99t always nee= d > usernames. This is, after all, the driving design pattern behind OAuth > access tokens. An access token doesn=E2=80=99t have a =E2=80=9Cusername= =E2=80=9D portion to it, > even though it would have been trivial to require the client to send its > client ID alongside the access token. Why does that work? Because our mod= el > of what the RS does with the access token is built around it answering th= e > questions: is this token valid and does it allow what=E2=80=99s being req= uested? If > the RS needs to know which client was issued the token, it can discover > that information without being told separately from the token -- perhaps > it=E2=80=99s in the token itself or it=E2=80=99s in an introspection resp= onse. And in a lot > of cases, the RS doesn=E2=80=99t care about the client software, it just = wants to > know if the token=E2=80=99s any good. Even in constrained tokens such as = MTLS, PoP, > and DPoP, we aren=E2=80=99t really authenticating the client at the RS so= much as > making sure the right key is presented alongside the right token. > >> > >> XYZ takes that same approach with the client talking to the AS and use= s > the credential (key) to identify the client as well as authenticate and > protect the request. We can=E2=80=99t just say =E2=80=9COAuth 2 had clien= t IDs and people > are used to it so it must be good and we have to keep using it=E2=80=9D. = We need to > ask WHY OAuth 2 needs client IDs and if that still makes sense. I argue > that it doesn=E2=80=99t make sense anymore and we need to step back and l= ook at a > better model. OAuth 2 needs a client ID because it gets passed in the fro= nt > channel and the client=E2=80=99s credentials can=E2=80=99t be used there.= The access token > doesn=E2=80=99t need an equivalent because it=E2=80=99s passed in the bac= k channel and can > be used directly. Now that the client no longer needs to be identified, b= ut > not authenticated, through untrusted third parties (such as the browser), > we don=E2=80=99t need to have a separate identifier as part of the protoc= ol. With > an intent-based protocol, that starts in the back channel, you don=E2=80= =99t need a > client identifier anymore. Once the AS finds that key, the AS can then > figure out what policies, rights, and restrictions are attached to that > key. In many implementations, there=E2=80=99s going to be some kind of = =E2=80=9Cregistered > client=E2=80=9D object in a database somewhere that drives those policies= . That=E2=80=99s > the classical OAuth model, and it works in many cases. But in other cases= , > the key is going to just be a value used to protect the request chain (an= d > possibly the token itself), and the policy is going to be built up by oth= er > things like a device posture or signature on the calling software or > verified user information. It=E2=80=99s not just about client authenticat= ion, even > though it can be used for it. DPoP, PKCE, and DynReg have shown us the > value in dynamic systems, in different ways. > >> > >> On top of that, PAR is showing us that a lot of the constraints that w= e > have in OAuth 2 don=E2=80=99t really apply anymore. For instance, Redirec= t URI > restrictions can be relaxed because now you CAN identify and authenticate > the software sending it, which isn=E2=80=99t true with a front-channel-fi= rst > approach. All of the things that are required in OAuth 2 start to become > redundant, and it leads to things like requiring that =E2=80=9Cclient_id= =E2=80=9D still > always be passed in the front channel even though the information could b= e > looked up from an internal request_uri reference using PAR and JAR togeth= er. > >> > >> That=E2=80=99s why a key handle isn=E2=80=99t exactly the same as a cl= ient ID and I did > not call it a client ID in the XYZ protocol. It=E2=80=99s a shortcut to r= efer to > the key material for certain optimized cases, but ultimately it=E2=80=99s= pointing > to a key. This has an interesting and beneficial side effect =E2=80=94 if= you HAVE > a client ID as part of your internal data model, it can FUNCTION as a key > handle because it=E2=80=99s a unique value the AS can use to look up key > information. It=E2=80=99s not =E2=80=9Cauthenticating the client=E2=80=9D= , it=E2=80=99s pointing to a key > which in turn identifies and authenticates the software making the call. > The fact that it=E2=80=99s a =E2=80=9Cclient ID=E2=80=9D is an artifact o= f the implementation, > which in this case has an OAuth 2 legacy to work with. > >> > >> If we=E2=80=99re going to move past the constraints of OAuth 2 we need= to stop > thinking so strictly in its terms and models. There are better ways to > approach this now and client IDs are not required by this protocol model. > > > > The idea of a client (or other entity) being identified precisely by it= s > > public key is very reminiscent of HIP (RFC 7401, 7402) that has a simil= ar > > stance. (There, it's billed as a security feature, since you are > literally > > guaranteed by the protocol to be talking to the entity you think you > are.) > > One of the difficulties with using HIP, though, is that just the pubkey > is > > not always a terribly useful identifier, and we tend to want to tie int= o > > other naming systems (e.g., the DNS in the case of HIP) so that we know > > that the party we're talking to at the HIP layer is also the > > person/organization we want to be talking to. In the case of HIP, the > need > > to bind a different type of name to the public key brings back a lot of > the > > issues that using the key as the identifier was supposed to solve (and = in > > my opinion is part of why HIP is not more broadly deployed). I don't s= ee > > this need for a binding of external name/identity to an XYZ public key > as a > > fatal flaw, though -- the way in which introduction are done combined > with > > the AS's database seems to allow things to work reasonably. I just wan= t > to > > make sure that we're thinking about how the public key will be bound to > > external identities, and make sure that our story for doing so is sound= . > > > > Yes, I feel the same way. The idea behind XYZ=E2=80=99s ability to introd= uce the > key either by value leads to a model where the key is always what points = to > the policy of what=E2=80=99s allowed, but the way that the AS discovers w= hich key > it=E2=80=99s supposed to be proving against is separate. So it goes handl= e -> key > -> client. In OAuth 2, the model is you identify the client and then figu= re > out what key is attached to that client. The relationship is inverted as > handle -> client -> key, and that=E2=80=99s where the problems start to c= ome in for > other communities. > I'm finding the following confusing: handle -> key -> client handle -> client -> key We have some identifier, and it is used by the AS to get an object / collection of attributes about the client handle -> { name URI image key .... } What is "client" above"? Is the client not a collection of attributes, and one of those is the key? > It=E2=80=99s really important for a lot of use cases that we let clients = have an > identifier separate from the key value itself, which is why XYZ doesn=E2= =80=99t > define the key handle as the fingerprint of the key, or the key ID (which > could be internal to the JWK), or anything else. All it means is =E2=80= =9Cwhen the > AS sees this value, it knows what key or keys it is referring to=E2=80=9D= . And from > there, the AS can figure out the rest of its policy. As you say, this > relationship can get set up with an AS database, or the AS could know how > to look up the key in a DNS store or distributed ledger =E2=80=94 it does= n=E2=80=99t > matter, as long as the AS can find the key. This allows us to also have u= se > cases where we don=E2=80=99t have a separate identifier that the AS knows= about and > we can just send the key as-is, like for ephemeral clients in SPAs, or > mobile applications that would need to be registered in OAuth 2 in order = to > get a client ID. And you don=E2=80=99t even need to look that far from OA= uth to > find use cases for key-based identity, as that=E2=80=99s at the core of t= he > self-issued OP functions in OIDC, which is in the core spec. There, we ha= ve > the spec saying to use the redirect URI as the client ID =E2=80=94 even t= hough the > client already is sending the Redirect URI, OAuth 2 (and the associated > assumptions and model of the protocol underneath) need this explicit clie= nt > ID field for all use cases. > > Something that I think is interesting is that we have an opportunity to > potentially define ways to process these kinds of things cross domain, mu= ch > the way JWTs and introspection allow for cross-domain access tokens to be > processed. But I think there=E2=80=99s still a lot of discussion and deba= te to > figure out all the avenues that people care about here. XYZ=E2=80=99s mod= el is > probably not exactly right for every case, but I=E2=80=99ve already seen = the > ability to do key by value or by reference be useful in a lot of places > that OAuth 2 doesn=E2=80=99t really work well. > > And that=E2=80=99s really where GNAP is going to shine =E2=80=94 in the g= aps that OAuth 2 > has left. > Are you able to provide examples so the rest of us can fully appreciate what the gaps are? =E1=90=A7 --00000000000051d39005a828e6af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
comments inline ...=C2=A0

On Sun, Jun 14, = 2020 at 10:21 AM Justin Richer <jrich= er@mit.edu> wrote:
Hi, Ben --

> On Jun 14, 2020, at 12:49 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> One more point, while I'm catching up on the thread...
>
> On Tue, Jun 09, 2020 at 12:10:40PM -0400, Justin Richer wrote:
>>
>>
>>> On Jun 8, 2020, at 5:33 PM, Dick Hardt <dick.hardt@gmail.com> wrote:<= br> >>>
>>> That is not entirely correct. A pre-registered client can stil= l pass its key by value, and a dynamic client can still use a (dynamically-= acquired) handle. In all cases, the client is identifying itself by its key= . The difference is how the server looks up that key =E2=80=94 it=E2=80=99s= either from the handle, or it=E2=80=99s from the key value itself.
>>>
>>> I don't understand this.
>>>
>>> How is the Client authenticating that it is a specific pre-reg= istered client?
>>
>> The client is identified by its key. There is no external client i= dentifier. I think you=E2=80=99re confused because you=E2=80=99re still thi= nking in terms of OAuth 2=E2=80=99s client ID based model and I am trying t= o move us past that. It took me time to realize that we really can let it g= o, so hopefully this is helpful in explaining why.
>>
>> When a credential is cryptographically random enough to be unique,= it can be used as its own identifier, particularly when you don=E2=80=99t = need to identify the entity outside of the context that it can present and = prove its credential. To stretch a metaphor, passwords don=E2=80=99t always= need usernames. This is, after all, the driving design pattern behind OAut= h access tokens. An access token doesn=E2=80=99t have a =E2=80=9Cusername= =E2=80=9D portion to it, even though it would have been trivial to require = the client to send its client ID alongside the access token. Why does that = work? Because our model of what the RS does with the access token is built = around it answering the questions: is this token valid and does it allow wh= at=E2=80=99s being requested? If the RS needs to know which client was issu= ed the token, it can discover that information without being told separatel= y from the token -- perhaps it=E2=80=99s in the token itself or it=E2=80=99= s in an introspection response. And in a lot of cases, the RS doesn=E2=80= =99t care about the client software, it just wants to know if the token=E2= =80=99s any good. Even in constrained tokens such as MTLS, PoP, and DPoP, w= e aren=E2=80=99t really authenticating the client at the RS so much as maki= ng sure the right key is presented alongside the right token.
>>
>> XYZ takes that same approach with the client talking to the AS and= uses the credential (key) to identify the client as well as authenticate a= nd protect the request. We can=E2=80=99t just say =E2=80=9COAuth 2 had clie= nt IDs and people are used to it so it must be good and we have to keep usi= ng it=E2=80=9D. We need to ask WHY OAuth 2 needs client IDs and if that sti= ll makes sense. I argue that it doesn=E2=80=99t make sense anymore and we n= eed to step back and look at a better model. OAuth 2 needs a client ID beca= use it gets passed in the front channel and the client=E2=80=99s credential= s can=E2=80=99t be used there. The access token doesn=E2=80=99t need an equ= ivalent because it=E2=80=99s passed in the back channel and can be used dir= ectly. Now that the client no longer needs to be identified, but not authen= ticated, through untrusted third parties (such as the browser), we don=E2= =80=99t need to have a separate identifier as part of the protocol. With an= intent-based protocol, that starts in the back channel, you don=E2=80=99t = need a client identifier anymore. Once the AS finds that key, the AS can th= en figure out what policies, rights, and restrictions are attached to that = key. In many implementations, there=E2=80=99s going to be some kind of =E2= =80=9Cregistered client=E2=80=9D object in a database somewhere that drives= those policies. That=E2=80=99s the classical OAuth model, and it works in = many cases. But in other cases, the key is going to just be a value used to= protect the request chain (and possibly the token itself), and the policy = is going to be built up by other things like a device posture or signature = on the calling software or verified user information. It=E2=80=99s not just= about client authentication, even though it can be used for it. DPoP, PKCE= , and DynReg have shown us the value in dynamic systems, in different ways.=
>>
>> On top of that, PAR is showing us that a lot of the constraints th= at we have in OAuth 2 don=E2=80=99t really apply anymore. For instance, Red= irect URI restrictions can be relaxed because now you CAN identify and auth= enticate the software sending it, which isn=E2=80=99t true with a front-cha= nnel-first approach. All of the things that are required in OAuth 2 start t= o become redundant, and it leads to things like requiring that =E2=80=9Ccli= ent_id=E2=80=9D still always be passed in the front channel even though the= information could be looked up from an internal request_uri reference usin= g PAR and JAR together.
>>
>> That=E2=80=99s why a key handle isn=E2=80=99t exactly the same as = a client ID and I did not call it a client ID in the XYZ protocol. It=E2=80= =99s a shortcut to refer to the key material for certain optimized cases, b= ut ultimately it=E2=80=99s pointing to a key. This has an interesting and b= eneficial side effect =E2=80=94 if you HAVE a client ID as part of your int= ernal data model, it can FUNCTION as a key handle because it=E2=80=99s a un= ique value the AS can use to look up key information. It=E2=80=99s not =E2= =80=9Cauthenticating the client=E2=80=9D, it=E2=80=99s pointing to a key wh= ich in turn identifies and authenticates the software making the call. The = fact that it=E2=80=99s a =E2=80=9Cclient ID=E2=80=9D is an artifact of the = implementation, which in this case has an OAuth 2 legacy to work with.
>>
>> If we=E2=80=99re going to move past the constraints of OAuth 2 we = need to stop thinking so strictly in its terms and models. There are better= ways to approach this now and client IDs are not required by this protocol= model.
>
> The idea of a client (or other entity) being identified precisely by i= ts
> public key is very reminiscent of HIP (RFC 7401, 7402) that has a simi= lar
> stance.=C2=A0 (There, it's billed as a security feature, since you= are literally
> guaranteed by the protocol to be talking to the entity you think you a= re.)
> One of the difficulties with using HIP, though, is that just the pubke= y is
> not always a terribly useful identifier, and we tend to want to tie in= to
> other naming systems (e.g., the DNS in the case of HIP) so that we kno= w
> that the party we're talking to at the HIP layer is also the
> person/organization we want to be talking to.=C2=A0 In the case of HIP= , the need
> to bind a different type of name to the public key brings back a lot o= f the
> issues that using the key as the identifier was supposed to solve (and= in
> my opinion is part of why HIP is not more broadly deployed).=C2=A0 I d= on't see
> this need for a binding of external name/identity to an XYZ public key= as a
> fatal flaw, though -- the way in which introduction are done combined = with
> the AS's database seems to allow things to work reasonably.=C2=A0 = I just want to
> make sure that we're thinking about how the public key will be bou= nd to
> external identities, and make sure that our story for doing so is soun= d.
>

Yes, I feel the same way. The idea behind XYZ=E2=80=99s ability to introduc= e the key either by value leads to a model where the key is always what poi= nts to the policy of what=E2=80=99s allowed, but the way that the AS discov= ers which key it=E2=80=99s supposed to be proving against is separate. So i= t goes handle -> key -> client. In OAuth 2, the model is you identify= the client and then figure out what key is attached to that client. The re= lationship is inverted as handle -> client -> key, and that=E2=80=99s= where the problems start to come in for other communities.

I'm finding the following confusing:
handle -> key -> client
handle -> client -> key
<= /blockquote>

We have some ide= ntifier, and it is used by the AS to get an object / collection of attribut= es about the client

handle -> {
=C2= =A0 =C2=A0 name
=C2=A0 =C2=A0 URI
=C2=A0 =C2=A0 image
=C2=A0 =C2=A0 key
=C2=A0 =C2=A0 ....
}

What is "client" above"? Is the client not= a collection of attributes, and one of those is the key?
=C2=A0 = =C2=A0 =C2=A0



It=E2=80=99s really important for a lot of use cases that we let clients ha= ve an identifier separate from the key value itself, which is why XYZ doesn= =E2=80=99t define the key handle as the fingerprint of the key, or the key = ID (which could be internal to the JWK), or anything else. All it means is = =E2=80=9Cwhen the AS sees this value, it knows what key or keys it is refer= ring to=E2=80=9D. And from there, the AS can figure out the rest of its pol= icy. As you say, this relationship can get set up with an AS database, or t= he AS could know how to look up the key in a DNS store or distributed ledge= r =E2=80=94 it doesn=E2=80=99t matter, as long as the AS can find the key. = This allows us to also have use cases where we don=E2=80=99t have a separat= e identifier that the AS knows about and we can just send the key as-is, li= ke for ephemeral clients in SPAs, or mobile applications that would need to= be registered in OAuth 2 in order to get a client ID. And you don=E2=80=99= t even need to look that far from OAuth to find use cases for key-based ide= ntity, as that=E2=80=99s at the core of the self-issued OP functions in OID= C, which is in the core spec. There, we have the spec saying to use the red= irect URI as the client ID =E2=80=94 even though the client already is send= ing the Redirect URI, OAuth 2 (and the associated assumptions and model of = the protocol underneath) need this explicit client ID field for all use cas= es.

Something that I think is interesting is that we have an opportunity to pot= entially define ways to process these kinds of things cross domain, much th= e way JWTs and introspection allow for cross-domain access tokens to be pro= cessed. But I think there=E2=80=99s still a lot of discussion and debate to= figure out all the avenues that people care about here. XYZ=E2=80=99s mode= l is probably not exactly right for every case, but I=E2=80=99ve already se= en the ability to do key by value or by reference be useful in a lot of pla= ces that OAuth 2 doesn=E2=80=99t really work well.

And that=E2=80=99s really where GNAP is going to shine =E2=80=94 in the gap= s that OAuth 2 has left.

=C2=A0Are you = able to provide examples so the rest of us can fully appreciate what the ga= ps=C2=A0are?=C2=A0
3D""=E1=90=A7
--00000000000051d39005a828e6af-- From nobody Mon Jun 15 18:25:11 2020 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 825933A0F54 for ; Mon, 15 Jun 2020 18:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 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, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuHNm80dWxRI for ; Mon, 15 Jun 2020 18:25:07 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650113.outbound.protection.outlook.com [40.107.65.113]) (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 10F693A0F4D for ; Mon, 15 Jun 2020 18:25:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=noh7RBq+i/P3m+7Gm09eki7510cJnHUv3hTVR6NUbYINuV2uKE9xdvdPm44Ma3Ott4CRgMRByWyICau7hD+xlJSQqpn6zhFRNgAfUwVRr4O4lBxE2TcGHmDajkLrRNNYSv8SJj4bc+7oO/W3dBqR1Q3bgnQu2KvDKsbBnbZIEIqv60KL5xzRQxg6Tk8VyBdEkurofSTDN8DyXZ47+CJiibug7iuj5KUxOxZTNuFiNk8hTNeK6RhaXC1S9PxWAMafQo/6JiRnfSU+54uCZboFY3SAxB3bnENfm7FjdajW6xSol7TJLn777G/gtco20OeRnKmh970TRRF3CNiVFWLhhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TlJoe3EC/z/1d9UljqHQFR2AHGAhqPg/U7DQQkZvE8k=; b=W+fLjQTzObC8LzRPmPNJ6E0UNvUYOJso80k2UX9NqzkP0OH23yKegR8DHIN2wLaJC/Pj5TbjTZ1p3Mq5llUYB3KRyXJO4V1Bgx8VcPjpJGvqfLYCdsbz9wN9g3UByvf6n1ZmG8nuRi04uCONMkSPIa5DeBpeODFBXcyde7p1lsAByBaJ5fy9nP1q1pAuMnQzo2WIc6jb2V5wIin0ONzyUSzjDy7OxKeIpkvQjhla/oHmFwIn3M0uERFaF+85V4iOFN1p3wqnvJq47PhQSzX7a71N/c8JkE+Cj+neSWtyZPCegA5Bgbl1VUyTDaYcW2HMfEGY/pQxrkE4ilEYASMXKQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TlJoe3EC/z/1d9UljqHQFR2AHGAhqPg/U7DQQkZvE8k=; b=b1sgyznWHTc+VmzUAXu0p7pVupoXevPgdW0MOnIssDu36CyrQ2liGrQkFuzHpGsb5t7cUdN8mJ1sF+iK2HiyRLOVXgnbtubij6DWSKNG9or+SgZamZ+Rqswzma44pH1M1MLoZ6TrUd87xPxIxaC95/Xq/o2fmW30W6QXyI6kBow= Received: from MN2PR00MB0688.namprd00.prod.outlook.com (2603:10b6:208:199::23) by MN2PR00MB0736.namprd00.prod.outlook.com (2603:10b6:208:1dc::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3144.0; Tue, 16 Jun 2020 01:25:05 +0000 Received: from MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::b4e8:a29d:bbae:4d02]) by MN2PR00MB0688.namprd00.prod.outlook.com ([fe80::b4e8:a29d:bbae:4d02%9]) with mapi id 15.20.3145.000; Tue, 16 Jun 2020 01:25:04 +0000 From: Mike Jones To: Dick Hardt , Justin Richer CC: "txauth@ietf.org" Thread-Topic: [Txauth] adding identity claim schemas (was: XYZ-08 vs XAuth-08) Thread-Index: AdZDfPNL2HNtAJdVSAquiIHZjxMf4A== Date: Tue, 16 Jun 2020 01:25:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=4e8e41da-e0f3-47f3-a5c1-aa4896cdd59f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-06-16T01:22:42Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.87.252] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 47b2ad83-1957-4e61-e526-08d811941937 x-ms-traffictypediagnostic: MN2PR00MB0736: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-forefront-prvs: 04362AC73B x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: K0zAFOvw5beW0X1lDVlT78ClALoA4n8RhS2PBfiGLNddO4CoTmV9uPlEGz28aqhiM4eVhE12TZVpCNkGAS6zItALyXTZaLDvWJq2ufuBRJgwFq3VMWNp4CVNDzb5mYWYBASsuAVZ8WjBtoDTl1bUT2+Jka560W5ZxTVR7/3wX52QtgbeXIQJf9G16PEOSTXwUkw0eDfmXIkuirG4E2s+o6+WLJIqisb9mbZ1uHzBNBDj6e+Gr7EqHfYHhN7yYlVLVug5LwG6abJ0DGwUGcuNv9leXkiqRS/i2dghsyTpgkENhY6WD0XP61b/3jy1f+duajZLTgHCy5DxmJaEaDGZspXrcltZQhU/KpgZs4ad+k3ZffBJTZ7Z/mtYXEMeDOwupkPe5q8Opz1I/6eLaFb1lTyNqEYHx27CI/bH+1DEZzaO4Zf7UbAQok9qMSpz0a/BS5G4/ttRWvToB/xQBtqZ/ewDViscf7qs4pgh6NzB5I93walXv5MRBz1tt4C7b8nd x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR00MB0688.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(376002)(366004)(136003)(39860400002)(209900001)(53546011)(6506007)(186003)(26005)(966005)(83380400001)(316002)(82950400001)(71200400001)(86362001)(83080400001)(19273905006)(82960400001)(64756008)(110136005)(9686003)(166002)(478600001)(8990500004)(2906002)(8676002)(4326008)(5660300002)(66476007)(33656002)(66946007)(76116006)(8936002)(66556008)(66446008)(55016002)(52536014)(10290500003)(7696005)(99710200001)(563064011)(6606295002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: ULeIDdqJ5aPO7cFRkSaPUQ1NwvVjMNyv7lsl8oy3X5VecP9ztpRWJN0FGYmenVy5R5hxLsBE3VL/0FlvCnxiegYV2uW1oTe6ABVVcZ8lSaDftij7dR9kpZaQ5rt81TNlZvd0bHUnv7DErnMC1JHohwyoYcWufoTYGUVHmzG9+Dhl5iAs6g6Rw67LZ23QY63wbZmWJ9L9QDV3CyyuhPCsTDpV8qFaxKwlR2ptydQD4xEv846d7LSf5SsSsiCjRZcvi9k514BMGN+chqmGIyFxUWM7BQoURvU0//E9hiL6VhLMvoECe1oPuTSzeNTJACr7f4HBg0jCS1uv12hwrJOZ2qjSjtl0uoXIyAmDw4uQaABJ9IZEMJf9vHnhLCctYJLIaWisGPMRLUDgeSqJGH4Leh1oGHgnvcvkiaNGED80G4uKws1v/EAPEJbmQ+e4lKasSQC9PvYLVSwshNK0YBTbqK0NLfU5bBtyvjf3kw4Mk9A= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR00MB0688FBD38C5B358245B562F7F59D0MN2PR00MB0688namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR00MB0688.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 47b2ad83-1957-4e61-e526-08d811941937 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jun 2020 01:25:04.7884 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TJQFNIBtnX4Wx/5Fla+LfmChkeIl86kFu/0kh6B1kf1k4hI9yi7ebOoc7+Kk8zOY3Wq5NFPKkXYPxvdtF7wrjw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR00MB0736 Archived-At: Subject: Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs XAuth-08) 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, 16 Jun 2020 01:25:10 -0000 --_000_MN2PR00MB0688FBD38C5B358245B562F7F59D0MN2PR00MB0688namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjb21wbGV0ZWx5IGFncmVlIHdpdGggRGljayB0aGF0LCBhcyB3cml0dGVuLCBYWVogaXMgZGVm aW5pbmcgYSBuZXcgYWQtaG9jIGlkZW50aXR5IHNjaGVtYSwgd2hpY2ggaXMgdW5uZWNlc3Nhcnkg YW5kIGNvdW50ZXItcHJvZHVjdGl2ZSAoYW5kIHByb2JhYmx5IHZpb2xhdGVzIG91ciBjaGFydGVy KS4NCg0KSSBhZ3JlZSB0aGF0IGV4cGxpY2l0bHkgcmV1c2luZyBleGlzdGluZyBjbGFpbXMgc2No ZW1hcywgcmF0aGVyIHRoYW4gaW52ZW50aW5nIG5ldyBvbmVzLCBpcyBvbmUgb2YgdGhlIGNsZWFy IGFuZCBjb21wZWxsaW5nIGFkdmFudGFnZXMgb2YgWEF1dGggb3ZlciBYWVouICBJ4oCZZCBwcmV2 aW91c2x5IHN1Z2dlc3RlZCB0aGF0IHRoZSBDbGFpbXMgc2VjdGlvbiBvZiBYWVo8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hlci10cmFuc2FjdGlvbmFsLWF1dGh6LTA4I3Nl Y3Rpb24tMi43PiBiZSByZXZpc2VkIHRvIG5vdCBkZWZpbmUgbmV3IOKAnGVtYWls4oCdIGFuZCDi gJxzdWJqZWN04oCdIGNsYWltcyB3aXRoIGFuIHVua25vd24gc2NoZW1hIGJ1dCB0aGF0IGhhc27i gJl0IGJlZW4gZG9uZS4gIE90aGVyIGluc3RhbmNlcyBvZiB0aGlzIHByb2JsZW0gb2NjdXIgaW4g dGhlIFhZWiBUcmFuc2FjdGlvbiBSZXF1ZXN0PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1yaWNoZXItdHJhbnNhY3Rpb25hbC1hdXRoei0wOCNzZWN0aW9uLTI+IGFuZCBUcmFuc2Fj dGlvbiBSZXNwb25zZTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmljaGVyLXRy YW5zYWN0aW9uYWwtYXV0aHotMDgjc2VjdGlvbi04PiBzZWN0aW9ucy4NCg0KR2V0dGluZyB0aGlz IHJpZ2h0IG1hdHRlcnMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IERpY2sgSGFyZHQgPGRpY2suaGFyZHRA Z21haWwuY29tPg0KU2VudDogTW9uZGF5LCBKdW5lIDE1LCAyMDIwIDU6MzkgUE0NClRvOiBKdXN0 aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+DQpDYzogdHhhdXRoQGlldGYub3JnOyBNaWtlIEpv bmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBSZTogW1R4YXV0aF0g YWRkaW5nIGlkZW50aXR5IGNsYWltIHNjaGVtYXMgKHdhczogWFlaLTA4IHZzIFhBdXRoLTA4KQ0K DQpjb21tZW50cyBpbmxpbmUgLi4uDQoNCk9uIFdlZCwgSnVuIDEwLCAyMDIwIGF0IDg6MDcgQU0g SnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3 cm90ZToNCg0KDQoNCk9uIEp1biA5LCAyMDIwLCBhdCA0OjE0IFBNLCBEaWNrIEhhcmR0IDxkaWNr LmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCg0K Rm9ya2luZyB0aGlzIHRvcGljIHRvIGEgbmV3IHRocmVhZA0KDQorTWlrZSBhcyBoZSBoYXMgZXhw cmVzc2VkIGNvbmNlcm4gYWJvdXQgY3JlYXRpbmcgbmV3IGlkZW50aXR5IGNsYWltcw0KDQpPbiBU dWUsIEp1biA5LCAyMDIwIGF0IDk6MTAgQU0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1 PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PiB3cm90ZToNCg0KDQoNCk9uIEp1biA4LCAyMDIwLCBh dCA1OjMzIFBNLCBEaWNrIEhhcmR0IDxkaWNrLmhhcmR0QGdtYWlsLmNvbTxtYWlsdG86ZGljay5o YXJkdEBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQoNCk9uIE1vbiwgSnVuIDgsIDIwMjAgYXQgMTow MiBQTSBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVk dT4+IHdyb3RlOg0KDQo8c25pcD4NCkkgZG9uJ3QgZm9sbG93IGhvdyB0aGlzIHdvdWxkIHdvcmsu IFBlcmhhcHMgeW91IGNvdWxkIHByb3ZpZGUgYW4gZXhhbXBsZSBpbiBKU09OPw0KDQpPbmUgbWV0 aG9kIGlzIGRlZmluaW5nIGEgbmV3IHZhbHVlIGluc2lkZSB0aGUgWFlaIOKAnGNsYWltc+KAnSBy ZXF1ZXN0IG9iamVjdCB0aGF0IG1hcHMgdG8gYSBzcGVjaWZpYyBzdWItc2NoZW1hOg0KDQpjbGFp bXM6IHsNCiAgIOKAnHN1YmplY3TigJ06IHRydWUsDQogICDigJxlbWFpbOKAnTogdHJ1ZSwNCiAg IOKAnG9pZGPigJ06IHsNCiAgICAgICAidXNlcmluZm8iOg0KICAgICAgICB7DQogICAgICAgICAi Z2l2ZW5fbmFtZSI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICAgICAibmlja25hbWUiOiBu dWxsLA0KICAgICAgICAgImVtYWlsIjogeyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgICAgICJl bWFpbF92ZXJpZmllZCI6IHsiZXNzZW50aWFsIjogdHJ1ZX0sDQogICAgICAgICAicGljdHVyZSI6 IG51bGwsDQogICAgICAgICAiaHR0cDovL2V4YW1wbGUuaW5mby9jbGFpbXMvZ3JvdXBzIjogbnVs bA0KICAgICAgICB9LA0KICAgICAgICJpZF90b2tlbiI6DQogICAgICAgIHsNCiAgICAgICAgICJh dXRoX3RpbWUiOiB7ImVzc2VudGlhbCI6IHRydWV9LA0KICAgICAgICAgImFjciI6IHsidmFsdWVz IjogWyJ1cm46bWFjZTppbmNvbW1vbjppYXA6c2lsdmVyIl0gfQ0KICAgICAgICB9DQogICAgICB9 DQp9DQoNClRoYXQgc2hvdWxkIGxvb2sgcHJldHR5IGZhbWlsaWFyLiBBbHRlcm5hdGl2ZWx5LCB0 aGlzIGNvdWxkIGJlIGRvbmUgd2l0aCBhIHNlcGFyYXRlIHRvcC1sZXZlbCByZXF1ZXN0IG9iamVj dCBmaWVsZDoNCg0KDQpjbGFpbXM6IHsNCiAgIOKAnHN1YmplY3TigJ06IHRydWUsDQogICDigJxl bWFpbOKAnTogdHJ1ZQ0KfSwNCuKAnG9pZGNfY2xhaW1zX3JlcXVlc3TigJ06IHsNCiAgICAgICAi dXNlcmluZm8iOg0KICAgICAgICB7DQogICAgICAgICAiZ2l2ZW5fbmFtZSI6IHsiZXNzZW50aWFs IjogdHJ1ZX0sDQogICAgICAgICAibmlja25hbWUiOiBudWxsLA0KICAgICAgICAgImVtYWlsIjog eyJlc3NlbnRpYWwiOiB0cnVlfSwNCiAgICAgICAgICJlbWFpbF92ZXJpZmllZCI6IHsiZXNzZW50 aWFsIjogdHJ1ZX0sDQogICAgICAgICAicGljdHVyZSI6IG51bGwsDQogICAgICAgICAiaHR0cDov L2V4YW1wbGUuaW5mby9jbGFpbXMvZ3JvdXBzIjogbnVsbA0KICAgICAgICB9LA0KICAgICAgICJp ZF90b2tlbiI6DQogICAgICAgIHsNCiAgICAgICAgICJhdXRoX3RpbWUiOiB7ImVzc2VudGlhbCI6 IHRydWV9LA0KICAgICAgICAgImFjciI6IHsidmFsdWVzIjogWyJ1cm46bWFjZTppbmNvbW1vbjpp YXA6c2lsdmVyIl0gfQ0KICAgICAgICB9DQp9DQoNCkluIGJvdGggY2FzZXMgdGhlIEFTIGlzIGdv aW5nIHRvIG5lZWQgdG8ga25pdCB0aGVtIHRvZ2V0aGVyIGludG8gYSBzZW5zaWJsZSByZXF1ZXN0 IHBvbGljeSwgZXNwZWNpYWxseSBzaW5jZSB0aGUgT0lEQyBjbGFpbXMgcXVlcnkgbGFuZ3VhZ2Ug aGFzIG92ZXJsYXBwaW5nIGltcGxpY2F0aW9ucyB0byBvbmUgcGFydGljdWxhciByZXNvdXJjZSwg dGhlIFVzZXJJbmZvIGVuZHBvaW50LiBNeSBjb250ZW50aW9uIHdhc27igJl0IHdpdGggeW91ciBw cm9wb3NlZCBzb2x1dGlvbiwgbXkgY29udGVudGlvbiB3YXMgeW91IGNsYWltaW5nIHRoYXQgWFla IGhhcyBhIGZpeGVkIHNjaGVtYSBhbmQgaXMgdGhlcmVmb3JlIGxpbWl0ZWQgaW4gZXh0ZW5zaWJp bGl0eS4NCg0KT25lIG9mIHRoZSBvYmplY3RpdmVzIG9mIHRoaXMgd29yayBpcyB0byBoYXZlIGV4 dGVuc2lvbiBwb2ludHMuIE15IHBvaW50IHdhcyB0aGF0IFhBdXRoIGhhZCBhIGNsZWFyIGV4dGVu c2lvbiBwb2ludCBmb3IgYWRkaW5nIHNjaGVtYXMuIEhvdyB0byBleHRlbmQgWFlaIHdhcyBub3Qg Y2xlYXIgaW4geW91ciBwcm9wb3NhbC4NCg0KDQpJIGFtIHNvcnJ5IHRoYXQgdGhlIGV4dGVuc2li aWxpdHkgb2YgdGhlIHByb3RvY29sIHdhcyBub3QgY2xlYXIuIEl0IGlzIHN0YXRlZCBpbiBlYWNo IHNlY3Rpb24gdGhhdCBhZGRpdGlvbmFsIGl0ZW1zIGNhbiBiZSBhZGRlZCwgYW5kIEkgaGF2ZSBz dGF0ZWQgcmVwZWF0ZWRseSB0aGF0IGl04oCZcyBleHRlbnNpYmxlIGFuZCBkZW1vbnN0cmF0ZWQg aG93LCBoZXJlIG9uIHRoaXMgbGlzdC4NCg0KDQpJIHRoaW5rIHRoZSBYQXV0aCBwcm9wb3NhbCBp cyBiZXR0ZXIgdGhhbiB0aGUgdHdvIGV4YW1wbGVzIHlvdSBwcm9wb3NlZC4gSW4geW91ciBmaXJz dCBleGFtcGxlLCB0aGUgc2NoZW1hIGlzIGEgc2Vjb25kIGNsYXNzIHNjaGVtYSwgYW5kIGluIHlv dXIgc2Vjb25kIGV4YW1wbGUsIGNsYWltcyBhcmUgc3ByZWFkIGFjcm9zcyB0byB0b3AgbGV2ZWwg b3B0aW9ucy4gQm90aCBvZiB0aGVzZSBwb2xsdXRlIG90aGVyIHNjaGVtYXMuDQoNCg0KTm90IHN1 cnByaXNpbmdseSwgSSBkaXNhZ3JlZSBhYm91dCB0aGUgY2xlYW5saW5lc3Mgb2YgWEF1dGjigJlz IHByb3Bvc2VkIGFwcHJvYWNoLiBUaGUgcHJvcG9zYWwgaGVyZSBhZGRzIGV4dGVybmFsIHNjaGVt YXMgYXMgZXh0ZW5zaW9ucyBpbnN0ZWFkIG9mIHJlbHlpbmcgb24gdGhlbSBpbnRlcm5hbGx5Lg0K DQpJZiBhbnl0aGluZywgSSB0aGluayB0aGF0IHRoZSBPcGVuSUQgRm91bmRhdGlvbiB3b3VsZCBi ZSB0aGUgb25lcyB0byBkZWZpbmUgaG93IHRvIG1ha2UgYW4gT0lEQyBjbGFpbXMgcmVxdWVzdCB1 c2luZyB0aGlzIHByb3RvY29sLCBub3QgdXMsIHNpbmNlIHRoZXkgb3duIGFuZCBjb250cm9sIHRo YXQgcXVlcnkgc3ludGF4IGFuZCBldmVyeXRoaW5nIGl0IGltcGxpZXMuIFdlIGNhbiBwcm92aWRl IGEgbWVhbnMgb2YgZXh0ZW5zaW9uLg0KDQpJIGFsc28gdGhpbmsgdGhlcmXigJlzIHZhbHVlIGlu IGRlZmluaW5nIGEgc2V0IG9mIGNvcmUgaW50ZXJvcGVyYWJsZSBpZGVudGl0eSBmaWVsZHMsIHdo aWNoIHRoZW1zZWx2ZXMgY291bGQgYWxzbyBiZSBleHRlbmRlZC4NCg0KQWxsIG9mIHRoZXNlIG1l Y2hhbmlzbXMgc2hvdWxkIGJlIGNvbnRyb2xsZWQgYnkgc29tZSBjb21iaW5hdGlvbiBvZiByZWdp c3RyaWVzIGFuZCBjb2xsaXNpb24tcmVzaXN0YW50IG5hbWVzcGFjZXMsIHdoaWNoIGlzIHRoZSBh cHByb2FjaCBJ4oCZdmUgdGFrZW4gZm9yIGV4dGVuc2liaWxpdHkgdGhyb3VnaG91dCBYWVouDQoN Cg0KSlNPTiBieSBpdHMgbmF0dXJlIGlzIGV4dGVuc2libGUuIEFkZGluZyBuZXcgbWVtYmVycyB0 byBhbiBvYmplY3QgaXMgc3RyYWlnaHQgZm9yd2FyZC4gWFlaIGlzIG5vdCB1bmlxdWUgaGVyZS4g SXQgc291bmRzIGxpa2UgeW91ciBpZGVhIG9mIGV4dGVuc2liaWxpdHkgaXMgdGVsbGluZyBwZW9w bGUgdGhhdCB0aGV5IGNhbiBhZGQgbmV3IG1lbWJlcnMgdG8gSlNPTi4gT2YgY291cnNlIHRoZXkg Y2FuLiBUaGF0IGlzIGxpa2Ugc2F5aW5nIHlvdSBjYW4gYWRkIG5ldyBxdWVyeSBwYXJhbWV0ZXJz IHRvIGEgZnJvbnQgY2hhbm5lbCBPQXV0aCAyIHJlcXVlc3QuDQoNCg0KWWVzLCBleGFjdGx5LiBB bmQgdGhhdOKAmXMgZXhhY3RseSBob3cgT0F1dGggMiBoYXMgYmVlbiBleHRlbmRlZC4gSeKAmW0g Z2xhZCB5b3Ugc2VlIHRoYXQgbm93Lg0KDQpJIHRoaW5rIHlvdSBhcmUgbWlzc2luZyBteSBwb2lu dC4gQWRkaW5nIHF1ZXJ5IHBhcmFtZXRlcnMgdG8gT0F1dGggMiB3YXMgbm90IGEgZGVmaW5lZCBl eHRlbnNpb24gcG9pbnQuIEl0IHdhcyBpbmhlcmVudCBpbiBob3cgcXVlcnkgcGFyYW1ldGVycyB3 b3JrLiBPQXV0aCAyIGRpZCBkZWZpbmUgdGhlIHR5cGUgb2YgZ3JhbnQgYXMgYW4gZXh0ZW5zaW9u IHBvaW50Lg0KDQoNCg0KTXkgY29uY2VybiB3YXMgdGhhdCBYWVogZG9lcyBub3QgaGF2ZSBhIGNs ZWFyIHdheSB0byBhZGQgbmV3IGlkZW50aXR5IGNsYWltIHNjaGVtYXMuIFlvdSBoYXZlIHR3byBl eGFtcGxlcywgYWRkIGEgc2NoZW1hIGFzIGEgbWVtYmVyIG9mIHRoZSBjbGFpbXMgb2JqZWN0LCB3 aGljaCBpcyBtaXhpbmcgY2xhaW1zIHdpdGggc2NoZW1hIGV4dGVuc2lvbnMsIG9yIGFkZGluZyBh IHJvb3QgbWVtYmVyLCB3aGljaCBpcyB0aGVuIHB1dHRpbmcgY2xhaW1zIGludG8gbW9yZSB0aGFu IG9uZSBwbGFjZS4gSXQgaXMgbm90IGNsZWFyIHdoZXJlIHRvIGFkZCBhIG5ldyBzY2hlbWEsIHNv IHdlIGNvdWxkIGVhc2lseSBlbmQgdXAgd2l0aCBuZXcgc2NoZW1hcyBpbiBib3RoIHBsYWNlcy4g VGhhdCBzb3VuZHMgY29uZnVzaW5nLg0KDQpJbiBYQXV0aCwgdGhlIG1lbWJlcnMgb2YgdGhlIGNs YWltcyBvYmplY3QgYXJlIHRoZSBzY2hlbWEuIEFkZGluZyBhIG5ldyBzY2hlbWEgaXMgZG9uZSBv bmUsIGNvbnNpc3RlbnQgd2F5Lg0KDQpJIHByb3ZpZGVkIGEgY291cGxlIGV4YW1wbGVzIG9mZiB0 aGUgY3VmZiBvZiBwb3NzaWJsZSB3YXlzIHRvIGV4dGVuZCBzb21ldGhpbmcsIGFzIHlvdXIgYmFz ZSBjbGFpbSB3YXMgdGhhdCBYWVogY291bGQgbm90IGJlIGV4dGVuZGVkIHdpdGggbmV3IG9yIGV4 dGVybmFsIHF1ZXJ5IHNjaGVtYXMuIE9mIHRoZSB0d28sIEkgdGhpbmsgdGhhdCBpdCBtYWtlcyBt b3JlIHNlbnNlIGZvciBpdCB0byBiZSBhIHNlcGFyYXRlIHRvcC1sZXZlbCBvYmplY3QuIFdoeT8g QmVjYXVzZSB0aGUgT0lEQyDigJxjbGFpbXPigJ0gcmVxdWVzdCBzeW50YXggbm90IG9ubHkgZGlj dGF0ZXMgY2xhaW1zIHdpdGhpbiB0aGUgT0lEQyBzY2hlbWEsIGl0IGFsc28gc3BlY2lmaWVzIGhv dyB0aGUgaW5mb3JtYXRpb24gY29tZXMgYmFjay4gVGhlIFhZWiBjbGFpbXMgcmVxdWVzdCB0YWxr cyBhYm91dCBpbmZvcm1hdGlvbiB0aGF0IGNvbWVzIGJhY2sgaW4gdGhlIFhZWiBjbGFpbXMgc2Vj dGlvbiBvZiB0aGUgcmVzcG9uc2UuDQoNCkkgd291bGQgcHV0IHRoZSBPSURDIHJlcXVlc3QgdG8g YWNxdWlyZSBjbGFpbXMgZnJvbSBhIHVzZXJfaW5mbyBlbmRwb2ludCBpbnRvIHRoZSBhdXRob3Jp emF0aW9uIHJlcXVlc3Qgc28gdGhhdCB0aGVyZSBpcyBhIGNvbnNpc3RlbnQgd2F5IHRvIGdldCBi YWNrIGFuIGFjY2VzcyB0b2tlbiwgYXMgb3Bwb3NlZCB0byBhIG5ldyB0b3AgbGV2ZWwgb2JqZWN0 IHRoYXQgY291bGQgcmV0dXJuIGNsYWltcyBhbmQvb3IgYW4gYWNjZXNzIHRva2VuLg0KDQpTaW5j ZSB0aGUgT0lEQyByZXF1ZXN0IGFsbG93cyBmb3IgdGFyZ2V0aW5nIHNwZWNpZmljYWxseSB0byB0 aGUgSUQgdG9rZW4gYW5kIFVzZXJJbmZvIEVuZHBvaW50LCBJIHRoaW5rIGl0IGlzIG11Y2ggY2xl YW5lciB0byBiZSBhdCB0aGUgdG9wIGxldmVsIGFzIGl0cyBvd24gdGhpbmcuDQoNCk15IHBvaW50 IGlzIHRoYXQgWFlaIGRvZXMgbm90IGRlZmluZSBob3cgdG8gYWRkIG5ldyBzY2hlbWFzLiBBbiBl eHRlbnNpb24gY2FuIGFkZCBhbnl0aGluZyBpdCB3YW50cyB0byB0aGUgSlNPTiwgYW5kIGFzIHlv dSBoYXZlIHNob3duIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgd2F5IHRvIGRvIGl0LCBhbmQgSSB0 aGluayBsb25nIHRlcm0gd2hlbiB0aGVyZSBhcmUgZGl2ZXJnZW50IG1lY2hhbmlzbXMsIHRoZSBj b2RlIGlzIGdvaW5nIHRvIGdldCB1Z2x5IGluIGRldGVjdGluZyB3aGF0IGNsYWltcyBhcmUgYmVp bmcgYXNrZWQgZm9yLg0KDQoNCg0KDQoNCndydC4gImRlZmluaW5nIGEgc2V0IG9mIGNvcmUgaW50 ZXJvcGVyYWJsZSBpZGVudGl0eSBmaWVsZHMiLCB0aGUgY2hhcnRlciBzYXlzIHdlIHNob3VsZCBi ZSBOT1QgZGV2ZWxvcCBhIG5ldyBzY2hlbWE6DQoNClRoZSBncm91cCBpcyBjaGFydGVyZWQgdG8g ZGV2ZWxvcCBtZWNoYW5pc21zIGZvciBjb252ZXlpbmcgaWRlbnRpdHkgaW5mb3JtYXRpb24gd2l0 aGluIHRoZSBwcm90b2NvbCBpbmNsdWRpbmcgaWRlbnRpZmllcnMgKHN1Y2ggYXMgZW1haWwgYWRk cmVzc2VzLCBwaG9uZSBudW1iZXJzLCB1c2VybmFtZXMsIGFuZCBzdWJqZWN0IGlkZW50aWZpZXJz KSBhbmQgYXNzZXJ0aW9ucyAoc3VjaCBhcyBPcGVuSUQgQ29ubmVjdCBJRCBUb2tlbnMsIFNBTUwg QXNzZXJ0aW9ucywgYW5kIFZlcmlmaWFibGUgQ3JlZGVudGlhbHMpLiBUaGUgZ3JvdXAgaXMgbm90 IGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG5ldyBmb3JtYXRzIGZvciBpZGVudGlmaWVycyBvciBhc3Nl cnRpb25zLCBub3IgaXMgdGhlIGdyb3VwIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIHNjaGVtYXMgZm9y IHVzZXIgaW5mb3JtYXRpb24sIHByb2ZpbGVzLCBvciBvdGhlciBpZGVudGl0eSBhdHRyaWJ1dGVz LCB1bmxlc3MgYSB2aWFibGUgZXhpc3RpbmcgZm9ybWF0IGlzIG5vdCBhdmFpbGFibGUuDQoNCndy dC4gT0lEQyBjbGFpbXMsIHRoZSBjaGFydGVyIGV4cGxpY2l0bHkgY2FsbHMgb3V0IGRldmVsb3Bp bmcgbWVjaGFuaXNtcyBmb3IgY29udmV5aW5nIC4uLiBPSURDIElEIFRva2Vucy4NCg0KW2h0dHBz Oi8vbWFpbGZvb2dhZS5hcHBzcG90LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBi QzVqYjIwJTNEJnR5cGU9emVyb2NvbnRlbnQmZ3VpZD02MGI4MDMyZC1lMDYxLTQ2NGUtYWZiYi0x YTgyYWJkMDJmMjFd4ZCnDQoNClByZWNpc2VseTogdGhlIGNoYXJ0ZXIgc2F5cyB3ZSB3aWxsIGhh dmUgYSB3YXkgdG8gY29udmV5IGlkZW50aWZpZXJzIGFuZCBhc3NlcnRpb25zLiBUaGUgWFlaIOKA nGNsYWltc+KAnSBzZWN0aW9uIGxpc3RzIGlkZW50aWZpZXJzIHRoYXQgY2FuIGNvbWUgYmFjaywg aW4gcGxhaW4gdGV4dCwgYW5kIGFzc2VydGlvbnMsIHRoYXQgY2FuIGFsc28gY29tZSBiYWNrIGFs b25nIHNpZGUgdGhlbS4NCg0KVGhlc2UgY2xhaW1zIGFyZSBhIHNjaGVtYS4gV2Ugd2lsbCBoYXZl IGFuIElBTkEgZW50cnkgZm9yIHdoYXQgY2xhaW1zIGFyZSBhbGxvd2VkIGluc2lkZSBvZiB0aGUg Y2xhaW1zIG9iamVjdC4gVGhpcyBpcyBkZWZpbmluZyBhIG5ldyBzY2hlbWEuDQoNCkl04oCZcyBu b3QgYSBmdWxsIHF1ZXJ5IGxhbmd1YWdlIGFuZCBpc27igJl0IGludGVuZGVkIHRvIGJlLCBhbmQg SSB0aGluayB0aGF0IGl0IHdvdWxkIGFjdHVhbGx5IGJlIGRhbmdlcm91cyBmb3IgdGhpcyB0byBi ZSBhIGZ1bGwgaWRlbnRpdHkgc2NoZW1hLCBidXQgaXQgaXMgaXRzZWxmIGV4dGVuc2libGUgaW50 ZXJuYWxseSBpZiBzb21lb25lIHdhbnRzIHRvIGRvIHRoYXQuIENsYWltaW5nIHRoYXQgYSBsaXN0 IG9mIGlkZW50aWZpZXJzIGlzIOKAnGRldmVsb3BpbmcgYSBuZXcgc2NoZW1h4oCdIGlzIGFuIGFy Z3VtZW50IHNldmVyYWwgYnJpZGdlcyB0b28gZmFyIGZyb20gcmVhbGl0eS4NCg0KWW91IGFyZSBu b3QgaW52ZW50aW5nIG5ldyBpZGVudGlmaWVycywgYnV0IHlvdSB3aWxsIGJlIGRlZmluaW5nIHdo aWNoIHN0cmluZ3MgYXJlIGJlaW5nIHVzZWQgdG8gcmVwcmVzZW50IHdoaWNoIGNvbmNlcHRzLiBG T3IgZXhhbXBsZSB5b3UgaGF2ZSAiZW1haWwiIHZzICJlbWFpbF9hZGRyZXNzIiwgb3IgYW55IG90 aGVyIHN0cmluZyBjb21iaW5hdGlvbiB0aGF0IGEgaHVtYW4gd291bGQgbGlrZWx5IGludGVycHJl dCBhcyBhbiBlbWFpbCBsaWtlIG9iamVjdC4gIFRoZW4gdGhlcmUgaXMgc3BlY2lmeWluZyB3aGF0 IGNhbiBiZSBpbiB0aGUgZmllbGQuDQoNCkkgcGlja2VkIGEgY291cGxlIGV4YW1wbGVzIG91dCBv ZiB0aGluIGFpciwgd2l0aCB0aGUgaWRlYSB0aGF0IHdl4oCZZCBiaWtlc2hlZCB0aGVtIGV2ZW50 dWFsbHkgYW5kIHRpZSB0aGVtIHRvIGEgcmVnaXN0cnkuIFdlIG1pZ2h0IHdhbnQgdG8gcmUtdXNl IGEgc2V0IG9mIGlkZW50aWZpZXJzIGhlcmUsIGFuZCBmb3IgdGhhdCBJIGFjdHVhbGx5IGxpa2Ug QW5uYWJlbGxlIEJhY2ttYW7igJlzIHByb3Bvc2FsIHRvIHRoZSBTRUNFVkVOVCBncm91cCBiZXR0 ZXIgdGhhbiBtb3N0IHRoYXQgSeKAmXZlIHNlZW4gaW4gdGhlIHNwYWNlOg0KDQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZWNldmVudC1zdWJqZWN0LWlkZW50aWZpZXJz DQoNClRoYXQgaXMgb25lIHNjaGVtYS4gQW5kIGl0IGhhcyBhZHZhbnRhZ2VzIGZvciB0aGUgc3Vi amVjdCBpZGVudGlmaWVycywgYnV0IG9idmlvdXNseSBkb2VzIG5vdCBjb3ZlciB0aGUgd2lkZSBh cnJheSBvZiBvdGhlciBpZGVudGl0eSBhdHRyaWJ1dGVzLg0KDQpXaHkgd291bGQgd2Ugbm90IHdh bnQgdG8gcmV1c2UgZXhpc3Rpbmcgc2NoZW1hcz8gQW5kIHN1cHBvcnQgYWxsIG9mIHRoZW0/DQoN Cg0KDQpbaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lY SmtkRUJuYldGcGJDNWpiMjAlM0QmdHlwZT16ZXJvY29udGVudCZndWlkPWNlM2UxOGRjLTU3NDAt NGNkZC1hM2IyLTY5YWE5MmU3NzU1ZF3hkKcNCg== --_000_MN2PR00MB0688FBD38C5B358245B562F7F59D0MN2PR00MB0688namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ SSBjb21wbGV0ZWx5IGFncmVlIHdpdGggRGljayB0aGF0LCBhcyB3cml0dGVuLCBYWVogaXMgZGVm aW5pbmcgYSBuZXcgYWQtaG9jIGlkZW50aXR5IHNjaGVtYSwgd2hpY2ggaXMgdW5uZWNlc3Nhcnkg YW5kIGNvdW50ZXItcHJvZHVjdGl2ZSAoYW5kIHByb2JhYmx5IHZpb2xhdGVzIG91ciBjaGFydGVy KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgYWdyZWUgdGhhdCBleHBs aWNpdGx5IHJldXNpbmcgZXhpc3RpbmcgY2xhaW1zIHNjaGVtYXMsIHJhdGhlciB0aGFuIGludmVu dGluZyBuZXcgb25lcywgaXMgb25lIG9mIHRoZSBjbGVhciBhbmQgY29tcGVsbGluZyBhZHZhbnRh Z2VzIG9mIFhBdXRoIG92ZXIgWFlaLiZuYnNwOyBJ4oCZZCBwcmV2aW91c2x5IHN1Z2dlc3RlZCB0 aGF0IHRoZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hl ci10cmFuc2FjdGlvbmFsLWF1dGh6LTA4I3NlY3Rpb24tMi43Ij4NCkNsYWltcyBzZWN0aW9uIG9m IFhZWjwvYT4gYmUgcmV2aXNlZCB0byBub3QgZGVmaW5lIG5ldyDigJxlbWFpbOKAnSBhbmQg4oCc c3ViamVjdOKAnSBjbGFpbXMgd2l0aCBhbiB1bmtub3duIHNjaGVtYSBidXQgdGhhdCBoYXNu4oCZ dCBiZWVuIGRvbmUuJm5ic3A7IE90aGVyIGluc3RhbmNlcyBvZiB0aGlzIHByb2JsZW0gb2NjdXIg aW4gdGhlIFhZWg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJp Y2hlci10cmFuc2FjdGlvbmFsLWF1dGh6LTA4I3NlY3Rpb24tMiI+DQpUcmFuc2FjdGlvbiBSZXF1 ZXN0PC9hPiBhbmQgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJp Y2hlci10cmFuc2FjdGlvbmFsLWF1dGh6LTA4I3NlY3Rpb24tOCI+DQpUcmFuc2FjdGlvbiBSZXNw b25zZTwvYT4gc2VjdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5H ZXR0aW5nIHRoaXMgcmlnaHQgbWF0dGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IERpY2sgSGFyZHQgJmx0O2RpY2suaGFyZHRAZ21haWwu Y29tJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBKdW5lIDE1LCAyMDIwIDU6MzkgUE08 YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDs8YnI+ DQo8Yj5DYzo8L2I+IHR4YXV0aEBpZXRmLm9yZzsgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1R4YXV0aF0gYWRk aW5nIGlkZW50aXR5IGNsYWltIHNjaGVtYXMgKHdhczogWFlaLTA4IHZzIFhBdXRoLTA4KTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29tbWVudHMgaW5saW5l IC4uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gV2VkLCBKdW4gMTAsIDIwMjAgYXQgODowNyBBTSBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVm PSJtYWlsdG86anJpY2hlckBtaXQuZWR1Ij5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIEp1biA5LCAyMDIwLCBhdCA0OjE0IFBNLCBEaWNrIEhhcmR0ICZsdDs8YSBocmVmPSJt YWlsdG86ZGljay5oYXJkdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5kaWNrLmhhcmR0QGdt YWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkZvcmtpbmcgdGhpcyB0b3BpYyB0byBhIG5ldyB0aHJlYWQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MztN aWtlIGFzIGhlIGhhcyBleHByZXNzZWQgY29uY2VybiBhYm91dCBjcmVhdGluZyBuZXcgaWRlbnRp dHkgY2xhaW1zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUdWUsIEp1biA5LCAyMDIwIGF0IDk6MTAgQU0gSnVzdGluIFJpY2hl ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpy aWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSnVuIDgsIDIwMjAsIGF0IDU6MzMg UE0sIERpY2sgSGFyZHQgJmx0OzxhIGhyZWY9Im1haWx0bzpkaWNrLmhhcmR0QGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmRpY2suaGFyZHRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEp1biA4 LCAyMDIwIGF0IDE6MDIgUE0gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNo ZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmx0O3NuaXAmZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBkb24ndCBmb2xsb3cgaG93IHRoaXMgd291bGQgd29yay4gUGVyaGFwcyB5 b3UgY291bGQgcHJvdmlkZSBhbiBleGFtcGxlIGluIEpTT04/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uZSBtZXRob2QgaXMgZGVmaW5pbmcgYSBuZXcgdmFsdWUgaW5zaWRl IHRoZSBYWVog4oCcY2xhaW1z4oCdIHJlcXVlc3Qgb2JqZWN0IHRoYXQgbWFwcyB0byBhIHNwZWNp ZmljIHN1Yi1zY2hlbWE6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jbGFpbXM6IHs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDvigJxzdWJqZWN04oCdOiB0cnVlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO+KAnGVtYWls 4oCdOiB0cnVlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO+KAnG9pZGPigJ06IHs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O3VzZXJpbmZvJnF1b3Q7OjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtnaXZlbl9uYW1lJnF1b3Q7OiB7JnF1b3Q7ZXNzZW50 aWFsJnF1b3Q7OiB0cnVlfSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmcXVvdDtuaWNrbmFtZSZxdW90OzogbnVsbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtlbWFpbCZxdW90OzogeyZxdW90O2Vzc2VudGlhbCZx dW90OzogdHJ1ZX0sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 JnF1b3Q7ZW1haWxfdmVyaWZpZWQmcXVvdDs6IHsmcXVvdDtlc3NlbnRpYWwmcXVvdDs6IHRydWV9 LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O3BpY3R1 cmUmcXVvdDs6IG51bGwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuaW5mby9jbGFpbXMvZ3JvdXBzIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL2V4YW1wbGUuaW5mby9jbGFpbXMvZ3JvdXBzPC9hPiZxdW90Ozog bnVsbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH0sPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtpZF90b2tlbiZxdW90Ozo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7YXV0aF90aW1lJnF1b3Q7OiB7JnF1b3Q7ZXNzZW50aWFs JnF1b3Q7OiB0cnVlfSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmcXVvdDthY3ImcXVvdDs6IHsmcXVvdDt2YWx1ZXMmcXVvdDs6IFsmcXVvdDt1cm46bWFjZTpp bmNvbW1vbjppYXA6c2lsdmVyJnF1b3Q7XSB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHNob3VsZCBsb29rIHByZXR0eSBmYW1pbGlh ci4gQWx0ZXJuYXRpdmVseSwgdGhpcyBjb3VsZCBiZSBkb25lIHdpdGggYSBzZXBhcmF0ZSB0b3At bGV2ZWwgcmVxdWVzdCBvYmplY3QgZmllbGQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2xhaW1zOiB7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A74oCcc3ViamVjdOKAnTogdHJ1ZSw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDvigJxlbWFpbOKAnTogdHJ1ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+fSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnG9pZGNfY2xhaW1zX3JlcXVlc3TigJ06 IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7dXNlcmluZm8mcXVvdDs6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90 O2dpdmVuX25hbWUmcXVvdDs6IHsmcXVvdDtlc3NlbnRpYWwmcXVvdDs6IHRydWV9LDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O25pY2tuYW1lJnF1b3Q7OiBudWxsLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90O2VtYWlsJnF1b3Q7OiB7JnF1b3Q7ZXNzZW50aWFs JnF1b3Q7OiB0cnVlfSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDtlbWFpbF92 ZXJpZmllZCZxdW90OzogeyZxdW90O2Vzc2VudGlhbCZxdW90OzogdHJ1ZX0sPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7cGljdHVyZSZxdW90OzogbnVsbCw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmcXVvdDs8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5pbmZvL2NsYWlt cy9ncm91cHMiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZXhhbXBsZS5pbmZvL2NsYWltcy9ncm91 cHM8L2E+JnF1b3Q7OiBudWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfSw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZxdW90O2lkX3Rva2VuJnF1b3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDthdXRoX3RpbWUmcXVvdDs6IHsmcXVv dDtlc3NlbnRpYWwmcXVvdDs6IHRydWV9LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZx dW90O2FjciZxdW90OzogeyZxdW90O3ZhbHVlcyZxdW90OzogWyZxdW90O3VybjptYWNlOmluY29t bW9uOmlhcDpzaWx2ZXImcXVvdDtdIH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj59PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SW4gYm90aCBjYXNlcyB0aGUgQVMgaXMgZ29pbmcgdG8gbmVlZCB0byBrbml0IHRo ZW0gdG9nZXRoZXIgaW50byBhIHNlbnNpYmxlIHJlcXVlc3QgcG9saWN5LCBlc3BlY2lhbGx5IHNp bmNlIHRoZSBPSURDIGNsYWltcyBxdWVyeSBsYW5ndWFnZSBoYXMgb3ZlcmxhcHBpbmcgaW1wbGlj YXRpb25zIHRvIG9uZSBwYXJ0aWN1bGFyIHJlc291cmNlLCB0aGUgVXNlckluZm8gZW5kcG9pbnQu IE15IGNvbnRlbnRpb24gd2FzbuKAmXQNCiB3aXRoIHlvdXIgcHJvcG9zZWQgc29sdXRpb24sIG15 IGNvbnRlbnRpb24gd2FzIHlvdSBjbGFpbWluZyB0aGF0IFhZWiBoYXMgYSBmaXhlZCBzY2hlbWEg YW5kIGlzIHRoZXJlZm9yZSBsaW1pdGVkIGluIGV4dGVuc2liaWxpdHkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbmUgb2YgdGhlIG9iamVjdGl2ZXMgb2YgdGhpcyB3b3JrIGlzIHRvIGhh dmUgZXh0ZW5zaW9uIHBvaW50cy4gTXkgcG9pbnQgd2FzIHRoYXQgWEF1dGggaGFkIGEgY2xlYXIg ZXh0ZW5zaW9uIHBvaW50IGZvciBhZGRpbmcgc2NoZW1hcy4gSG93IHRvIGV4dGVuZCBYWVogd2Fz IG5vdCBjbGVhciBpbiZuYnNwO3lvdXIgcHJvcG9zYWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBhbSBzb3JyeSB0aGF0IHRoZSBleHRlbnNpYmlsaXR5IG9mIHRoZSBw cm90b2NvbCB3YXMgbm90IGNsZWFyLiBJdCBpcyBzdGF0ZWQgaW4gZWFjaCBzZWN0aW9uIHRoYXQg YWRkaXRpb25hbCBpdGVtcyBjYW4gYmUgYWRkZWQsIGFuZCBJIGhhdmUgc3RhdGVkIHJlcGVhdGVk bHkgdGhhdCBpdOKAmXMgZXh0ZW5zaWJsZSBhbmQgZGVtb25zdHJhdGVkIGhvdywgaGVyZSBvbiB0 aGlzIGxpc3QuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgWEF1dGggcHJvcG9zYWwgaXMg YmV0dGVyIHRoYW4gdGhlIHR3byBleGFtcGxlcyB5b3UgcHJvcG9zZWQuIEluIHlvdXIgZmlyc3Qg ZXhhbXBsZSwgdGhlIHNjaGVtYSBpcyBhIHNlY29uZCBjbGFzcyBzY2hlbWEsIGFuZCBpbiB5b3Vy IHNlY29uZCBleGFtcGxlLCBjbGFpbXMgYXJlIHNwcmVhZCBhY3Jvc3MgdG8gdG9wIGxldmVsIG9w dGlvbnMuIEJvdGggb2YgdGhlc2UgcG9sbHV0ZSBvdGhlcg0KIHNjaGVtYXMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IHN1cnByaXNpbmdseSwgSSBkaXNhZ3JlZSBh Ym91dCB0aGUgY2xlYW5saW5lc3Mgb2YgWEF1dGjigJlzIHByb3Bvc2VkIGFwcHJvYWNoLiBUaGUg cHJvcG9zYWwgaGVyZSBhZGRzIGV4dGVybmFsIHNjaGVtYXMgYXMgZXh0ZW5zaW9ucyBpbnN0ZWFk IG9mIHJlbHlpbmcgb24gdGhlbSBpbnRlcm5hbGx5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBhbnl0aGluZywgSSB0aGluayB0 aGF0IHRoZSBPcGVuSUQgRm91bmRhdGlvbiB3b3VsZCBiZSB0aGUgb25lcyB0byBkZWZpbmUgaG93 IHRvIG1ha2UgYW4gT0lEQyBjbGFpbXMgcmVxdWVzdCB1c2luZyB0aGlzIHByb3RvY29sLCBub3Qg dXMsIHNpbmNlIHRoZXkgb3duIGFuZCBjb250cm9sIHRoYXQgcXVlcnkgc3ludGF4IGFuZCBldmVy eXRoaW5nIGl0IGltcGxpZXMuIFdlIGNhbiBwcm92aWRlIGEgbWVhbnMgb2YNCiBleHRlbnNpb24u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg YWxzbyB0aGluayB0aGVyZeKAmXMgdmFsdWUgaW4gZGVmaW5pbmcgYSBzZXQgb2YgY29yZSBpbnRl cm9wZXJhYmxlIGlkZW50aXR5IGZpZWxkcywgd2hpY2ggdGhlbXNlbHZlcyBjb3VsZCBhbHNvIGJl IGV4dGVuZGVkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbGwgb2YgdGhlc2UgbWVjaGFuaXNtcyBzaG91bGQgYmUgY29udHJvbGxl ZCBieSBzb21lIGNvbWJpbmF0aW9uIG9mIHJlZ2lzdHJpZXMgYW5kIGNvbGxpc2lvbi1yZXNpc3Rh bnQgbmFtZXNwYWNlcywgd2hpY2ggaXMgdGhlIGFwcHJvYWNoIEnigJl2ZSB0YWtlbiBmb3IgZXh0 ZW5zaWJpbGl0eSB0aHJvdWdob3V0IFhZWi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SlNPTiBieSBpdHMgbmF0dXJlIGlzIGV4dGVuc2libGUuIEFkZGluZyBuZXcgbWVtYmVycyB0byBh biBvYmplY3QgaXMgc3RyYWlnaHQgZm9yd2FyZC4gWFlaIGlzIG5vdCB1bmlxdWUgaGVyZS4gSXQg c291bmRzIGxpa2UgeW91ciBpZGVhIG9mIGV4dGVuc2liaWxpdHkmbmJzcDtpcyB0ZWxsaW5nIHBl b3BsZSB0aGF0IHRoZXkgY2FuIGFkZCBuZXcgbWVtYmVycyB0byBKU09OLiBPZiBjb3Vyc2UgdGhl eSBjYW4uIFRoYXQgaXMNCiBsaWtlIHNheWluZyB5b3UgY2FuIGFkZCBuZXcgcXVlcnkgcGFyYW1l dGVycyB0byBhIGZyb250IGNoYW5uZWwgT0F1dGggMiByZXF1ZXN0LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgZXhhY3RseS4gQW5kIHRoYXTigJlzIGV4YWN0bHkg aG93IE9BdXRoIDIgaGFzIGJlZW4gZXh0ZW5kZWQuIEnigJltIGdsYWQgeW91IHNlZSB0aGF0IG5v dy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgeW91IGFyZSBtaXNzaW5nIG15 IHBvaW50LiBBZGRpbmcgcXVlcnkgcGFyYW1ldGVycyB0byBPQXV0aCAyIHdhcyBub3QgYSBkZWZp bmVkIGV4dGVuc2lvbiBwb2ludC4gSXQgd2FzIGluaGVyZW50IGluIGhvdyBxdWVyeSBwYXJhbWV0 ZXJzIHdvcmsuIE9BdXRoIDIgZGlkIGRlZmluZSB0aGUgdHlwZSBvZiBncmFudCBhcyBhbiBleHRl bnNpb24gcG9pbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7 bWFyZ2luOjAuLjhleCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+TXkgY29uY2VybiB3YXMgdGhhdCBYWVogZG9lcyBub3QgaGF2ZSBh IGNsZWFyIHdheSB0byBhZGQgbmV3IGlkZW50aXR5IGNsYWltIHNjaGVtYXMuIFlvdSBoYXZlIHR3 byBleGFtcGxlcywgYWRkIGEgc2NoZW1hIGFzIGEgbWVtYmVyIG9mIHRoZSBjbGFpbXMgb2JqZWN0 LCB3aGljaCBpcyBtaXhpbmcgY2xhaW1zIHdpdGggc2NoZW1hIGV4dGVuc2lvbnMsIG9yIGFkZGlu ZyBhIHJvb3QgbWVtYmVyLCB3aGljaCBpcw0KIHRoZW4gcHV0dGluZyBjbGFpbXMgaW50byBtb3Jl IHRoYW4gb25lIHBsYWNlLiBJdCBpcyBub3QgY2xlYXIgd2hlcmUgdG8gYWRkIGEgbmV3IHNjaGVt YSwgc28gd2UgY291bGQgZWFzaWx5IGVuZCB1cCB3aXRoIG5ldyBzY2hlbWFzIGluIGJvdGggcGxh Y2VzLiBUaGF0IHNvdW5kcyBjb25mdXNpbmcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIFhBdXRoLCB0aGUgbWVtYmVy cyBvZiB0aGUgY2xhaW1zIG9iamVjdCBhcmUgdGhlIHNjaGVtYS4gQWRkaW5nIGEgbmV3IHNjaGVt YSBpcyBkb25lIG9uZSwgY29uc2lzdGVudCB3YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgcHJvdmlkZWQgYSBjb3VwbGUgZXhhbXBsZXMgb2ZmIHRoZSBjdWZmIG9mIHBv c3NpYmxlIHdheXMgdG8gZXh0ZW5kIHNvbWV0aGluZywgYXMgeW91ciBiYXNlIGNsYWltIHdhcyB0 aGF0IFhZWiBjb3VsZCBub3QgYmUgZXh0ZW5kZWQgd2l0aCBuZXcgb3IgZXh0ZXJuYWwgcXVlcnkg c2NoZW1hcy4gT2YgdGhlIHR3bywgSSB0aGluayB0aGF0IGl0IG1ha2VzIG1vcmUgc2Vuc2UgZm9y IGl0IHRvIGJlIGEgc2VwYXJhdGUNCiB0b3AtbGV2ZWwgb2JqZWN0LiBXaHk/IEJlY2F1c2UgdGhl IE9JREMg4oCcY2xhaW1z4oCdIHJlcXVlc3Qgc3ludGF4IG5vdCBvbmx5IGRpY3RhdGVzIGNsYWlt cyB3aXRoaW4gdGhlIE9JREMgc2NoZW1hLCBpdCBhbHNvIHNwZWNpZmllcyBob3cgdGhlIGluZm9y bWF0aW9uIGNvbWVzIGJhY2suIFRoZSBYWVogY2xhaW1zIHJlcXVlc3QgdGFsa3MgYWJvdXQgaW5m b3JtYXRpb24gdGhhdCBjb21lcyBiYWNrIGluIHRoZSBYWVogY2xhaW1zIHNlY3Rpb24gb2YgdGhl DQogcmVzcG9uc2UuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBwdXQgdGhl IE9JREMgcmVxdWVzdCB0byBhY3F1aXJlIGNsYWltcyBmcm9tIGEgdXNlcl9pbmZvIGVuZHBvaW50 IGludG8gdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCBzbyB0aGF0IHRoZXJlIGlzIGEgY29uc2lz dGVudCB3YXkgdG8gZ2V0IGJhY2sgYW4gYWNjZXNzIHRva2VuLCBhcyBvcHBvc2VkIHRvIGEgbmV3 IHRvcCBsZXZlbCBvYmplY3QgdGhhdCBjb3VsZCByZXR1cm4gY2xhaW1zIGFuZC9vcg0KIGFuIGFj Y2VzcyB0b2tlbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2UgdGhlIE9JREMgcmVxdWVz dCBhbGxvd3MgZm9yIHRhcmdldGluZyBzcGVjaWZpY2FsbHkgdG8gdGhlIElEIHRva2VuIGFuZCBV c2VySW5mbyBFbmRwb2ludCwgSSB0aGluayBpdCBpcyBtdWNoIGNsZWFuZXIgdG8gYmUgYXQgdGhl IHRvcCBsZXZlbCBhcyBpdHMgb3duIHRoaW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+TXkgcG9pbnQgaXMgdGhhdCBYWVogZG9lcyBub3QgPGI+ZGVmaW5lPC9iPiBob3cgdG8g YWRkIG5ldyBzY2hlbWFzLiBBbiBleHRlbnNpb24gY2FuIGFkZCBhbnl0aGluZyBpdCB3YW50cyB0 byB0aGUgSlNPTiwgYW5kIGFzIHlvdSBoYXZlIHNob3duIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUg d2F5IHRvIGRvIGl0LCBhbmQgSSB0aGluayBsb25nIHRlcm0gd2hlbiB0aGVyZSBhcmUgZGl2ZXJn ZW50IG1lY2hhbmlzbXMsDQogdGhlIGNvZGUgaXMgZ29pbmcgdG8gZ2V0IHVnbHkgaW4gZGV0ZWN0 aW5nIHdoYXQgY2xhaW1zIGFyZSBiZWluZyBhc2tlZCBmb3IuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d3J0LiAmcXVvdDtkZWZpbmluZyBhIHNldCBv ZiBjb3JlIGludGVyb3BlcmFibGUgaWRlbnRpdHkgZmllbGRzJnF1b3Q7LCB0aGUgY2hhcnRlciBz YXlzIHdlIHNob3VsZCBiZQ0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO2JhY2tncm91bmQ6eWVs bG93Ij5OT1QgZGV2ZWxvcCBhIG5ldyBzY2hlbWE8L3NwYW4+OjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrO2JhY2tncm91bmQ6bGltZSI+VGhlIGdyb3VwIGlzIGNoYXJ0ZXJl ZCB0byBkZXZlbG9wIG1lY2hhbmlzbXMgZm9yIGNvbnZleWluZyBpZGVudGl0eSBpbmZvcm1hdGlv biB3aXRoaW4gdGhlIHByb3RvY29sDQo8L3NwYW4+aW5jbHVkaW5nIGlkZW50aWZpZXJzIChzdWNo IGFzIGVtYWlsIGFkZHJlc3NlcywgcGhvbmUgbnVtYmVycywgdXNlcm5hbWVzLCBhbmQgc3ViamVj dCBpZGVudGlmaWVycykgYW5kIGFzc2VydGlvbnMgKDxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazti YWNrZ3JvdW5kOmxpbWUiPnN1Y2ggYXMgT3BlbklEIENvbm5lY3QgSUQgVG9rZW5zPC9zcGFuPiwg U0FNTCBBc3NlcnRpb25zLCBhbmQgVmVyaWZpYWJsZSBDcmVkZW50aWFscykuDQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2s7YmFja2dyb3VuZDp5ZWxsb3ciPlRoZSBncm91cCBpcyBub3QgY2hhcnRl cmVkIHRvIGRldmVsb3AgbmV3IGZvcm1hdHMgZm9yIGlkZW50aWZpZXJzIG9yIGFzc2VydGlvbnMs IG5vciBpcyB0aGUgZ3JvdXAgY2hhcnRlcmVkIHRvIGRldmVsb3Agc2NoZW1hcyBmb3IgdXNlciBp bmZvcm1hdGlvbiwgcHJvZmlsZXMsIG9yIG90aGVyIGlkZW50aXR5IGF0dHJpYnV0ZXMsIHVubGVz cyBhIHZpYWJsZSBleGlzdGluZw0KIGZvcm1hdCBpcyBub3QgYXZhaWxhYmxlLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d3J0LiBPSURDIGNsYWltcywgdGhlIGNoYXJ0ZXIgZXhw bGljaXRseSBjYWxscyBvdXQgPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO2JhY2tncm91bmQ6bGlt ZSI+DQpkZXZlbG9waW5nIG1lY2hhbmlzbXMgZm9yIGNvbnZleWluZyAuLi4gT0lEQyBJRCBUb2tl bnM8L3NwYW4+LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGltZyBib3JkZXI9IjAiIGlkPSJfeDAwMDBfaTEwMjYi IHNyYz0iaHR0cHM6Ly9tYWlsZm9vZ2FlLmFwcHNwb3QuY29tL3Q/c2VuZGVyPWFaR2xqYXk1b1lY SmtkRUJuYldGcGJDNWpiMjAlM0QmYW1wO3R5cGU9emVyb2NvbnRlbnQmYW1wO2d1aWQ9NjBiODAz MmQtZTA2MS00NjRlLWFmYmItMWE4MmFiZDAyZjIxIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0dhZHVnaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndoaXRl Ij7hkKc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QcmVjaXNlbHk6IHRoZSBjaGFydGVyIHNheXMgd2Ug d2lsbCBoYXZlIGEgd2F5IHRvIGNvbnZleSBpZGVudGlmaWVycyBhbmQgYXNzZXJ0aW9ucy4gVGhl IFhZWiDigJxjbGFpbXPigJ0gc2VjdGlvbiBsaXN0cyBpZGVudGlmaWVycyB0aGF0IGNhbiBjb21l IGJhY2ssIGluIHBsYWluIHRleHQsIGFuZCBhc3NlcnRpb25zLCB0aGF0IGNhbiBhbHNvIGNvbWUg YmFjayBhbG9uZyBzaWRlIHRoZW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlc2UgY2xhaW1zIGFy ZSBhIHNjaGVtYS4gV2Ugd2lsbCBoYXZlIGFuIElBTkEgZW50cnkgZm9yIHdoYXQgY2xhaW1zIGFy ZSBhbGxvd2VkIGluc2lkZSBvZiB0aGUgY2xhaW1zIG9iamVjdC4gVGhpcyBpcyBkZWZpbmluZyBh IG5ldyBzY2hlbWEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXTigJlzIG5vdCBhIGZ1bGwgcXVlcnkgbGFu Z3VhZ2UgYW5kIGlzbuKAmXQgaW50ZW5kZWQgdG8gYmUsIGFuZCBJIHRoaW5rIHRoYXQgaXQgd291 bGQgYWN0dWFsbHkgYmUgZGFuZ2Vyb3VzIGZvciB0aGlzIHRvIGJlIGEgZnVsbCBpZGVudGl0eSBz Y2hlbWEsIGJ1dCBpdCBpcyBpdHNlbGYgZXh0ZW5zaWJsZSBpbnRlcm5hbGx5IGlmIHNvbWVvbmUg d2FudHMgdG8gZG8gdGhhdC4gQ2xhaW1pbmcgdGhhdCBhIGxpc3Qgb2YNCiBpZGVudGlmaWVycyBp cyDigJxkZXZlbG9waW5nIGEgbmV3IHNjaGVtYeKAnSBpcyBhbiBhcmd1bWVudCBzZXZlcmFsIGJy aWRnZXMgdG9vIGZhciBmcm9tIHJlYWxpdHkuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgYXJl IG5vdCBpbnZlbnRpbmcgbmV3IGlkZW50aWZpZXJzLCBidXQgeW91IHdpbGwgYmUgZGVmaW5pbmcg d2hpY2ggc3RyaW5ncyBhcmUgYmVpbmcgdXNlZCB0byByZXByZXNlbnQgd2hpY2ggY29uY2VwdHMu IEZPciBleGFtcGxlIHlvdSBoYXZlICZxdW90O2VtYWlsJnF1b3Q7IHZzICZxdW90O2VtYWlsX2Fk ZHJlc3MmcXVvdDssIG9yIGFueSBvdGhlciBzdHJpbmcgY29tYmluYXRpb24gdGhhdCBhIGh1bWFu IHdvdWxkIGxpa2VseSBpbnRlcnByZXQNCiBhcyBhbiBlbWFpbCBsaWtlIG9iamVjdC4mbmJzcDsg VGhlbiB0aGVyZSBpcyBzcGVjaWZ5aW5nIHdoYXQgY2FuIGJlIGluIHRoZSBmaWVsZC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIHBpY2tlZCBhIGNvdXBsZSBleGFtcGxlcyBvdXQgb2YgdGhpbiBhaXIsIHdp dGggdGhlIGlkZWEgdGhhdCB3ZeKAmWQgYmlrZXNoZWQgdGhlbSBldmVudHVhbGx5IGFuZCB0aWUg dGhlbSB0byBhIHJlZ2lzdHJ5LiBXZSBtaWdodCB3YW50IHRvIHJlLXVzZSBhIHNldCBvZiBpZGVu dGlmaWVycyBoZXJlLCBhbmQgZm9yIHRoYXQgSSBhY3R1YWxseSBsaWtlIEFubmFiZWxsZSBCYWNr bWFu4oCZcyBwcm9wb3NhbCB0byB0aGUNCiBTRUNFVkVOVCBncm91cCBiZXR0ZXIgdGhhbiBtb3N0 IHRoYXQgSeKAmXZlIHNlZW4gaW4gdGhlIHNwYWNlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1zZWNldmVudC1zdWJqZWN0LWlkZW50aWZpZXJzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2VjZXZlbnQt c3ViamVjdC1pZGVudGlmaWVyczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGlzIG9uZSBz Y2hlbWEuIEFuZCBpdCBoYXMgYWR2YW50YWdlcyBmb3IgdGhlIHN1YmplY3QgaWRlbnRpZmllcnMs IGJ1dCBvYnZpb3VzbHkgZG9lcyBub3QgY292ZXIgdGhlIHdpZGUgYXJyYXkgb2Ygb3RoZXIgaWRl bnRpdHkgYXR0cmlidXRlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+V2h5IHdvdWxkIHdlIG5vdCB3YW50IHRvIHJldXNlIGV4aXN0aW5nIHNj aGVtYXM/IEFuZCBzdXBwb3J0IGFsbCBvZiB0aGVtPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpbWcgYm9y ZGVyPSIwIiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9Imh0dHBzOi8vbWFpbGZvb2dhZS5hcHBzcG90 LmNvbS90P3NlbmRlcj1hWkdsamF5NW9ZWEprZEVCbmJXRnBiQzVqYjIwJTNEJmFtcDt0eXBlPXpl cm9jb250ZW50JmFtcDtndWlkPWNlM2UxOGRjLTU3NDAtNGNkZC1hM2IyLTY5YWE5MmU3NzU1ZCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtHYWR1Z2kmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aGl0ZSI+4ZCnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MN2PR00MB0688FBD38C5B358245B562F7F59D0MN2PR00MB0688namp_-- From nobody Tue Jun 16 06:59:58 2020 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 60E733A0D73 for ; Tue, 16 Jun 2020 06:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.38 X-Spam-Level: **** X-Spam-Status: No, score=4.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FILL_THIS_FORM=0.001, FILL_THIS_FORM_LONG=2, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, PDS_OTHER_BAD_TLD=2, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.999, URIBL_BLOCKED=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 KrYzhTY09gTd for ; Tue, 16 Jun 2020 06:59:55 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC86A3A0D72 for ; Tue, 16 Jun 2020 06:59:51 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d39 with ME id rpzp2200B4FMSmm03pzpzm; Tue, 16 Jun 2020 15:59:49 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Tue, 16 Jun 2020 15:59:49 +0200 X-ME-IP: 86.238.65.197 From: Denis To: txauth@ietf.org Message-ID: <44e749df-72a2-fa8f-5153-964b95b95f24@free.fr> Date: Tue, 16 Jun 2020 15:59:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------BDF8F96DB3E51A3E83FE7DEF" Content-Language: en-GB Archived-At: Subject: [Txauth] About the 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, 16 Jun 2020 13:59:57 -0000 This is a multi-part message in MIME format. --------------BDF8F96DB3E51A3E83FE7DEF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello, I joined this BoF during the last week-end and this is my first post. The current proposed charter is two pages long, whereas the OAuth 2.0 charter was half a page long. We should attempt to make it shorter ... and clearer. Hereafter a full rewording of the charter, while the justification for this rewording is placed after it. *New proposed charter* This group is chartered to develop a fine-grained protocol in a client, authorization server and resource server model, where a client can request to one or more authorization servers one or more attributes that it needs in order to perform an operation on a resource server, at the time it needs it. Since the privacy of the user is a concern  privacy by default and privacy by design are considered. The attributes issued by an authorization server are provided in the form of an attributes token that is cryptographically signed. The protocol supports attributes tokens usable as narrowly as for a single operation. The group is chartered to develop mechanisms for conveying target information and identity information within the protocol including identity attributes such as pseudonyms, email addresses, user names, home addresses, business addresses, phone numbers, date of birth, age. When a viable existing format is not available for these identity attributes, the group is chartered to define such format. Through interaction mechanisms supported by the protocol, the resource server allows a user to make a decision whether it is willing or not to disclose some attributes to perform one or more operations. Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible. This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. As a difference with OAuth 2.0, there is no bilateral trust relationship between authorization servers and resource servers: for a given category of attributes, a resource server trusts one or more authorization servers. Resource servers only make available to their clients which access token formats are acceptable. As another difference with OAuth 2.0, the content of an attributes token is meant to be accessible to the client. The group will define interoperable protocols between different parties, including: * client and authorization server; and * client and resource server. Milestones to include: * Architecture of the model, * Attributes token definition, including mechanism bindings * Core protocol between the different parties *Justification for the rewording* I have re-used the original text whenever it was adequate and concise. I also read "Identity in XYZ" from: https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz* *The good: "Rather than returning an ID token with potentially stale or large amounts of user information in the authorization response, let's return only the minimum necessary for the application to function, and let it request additional information that it needs when it needs it". _Comment_: This is a "privacy by default" principle which is indeed important. The good: "The value MAY vary for the same user when logging in to different applications in order to preserve the user's privacy, preventing different applications from cross-correlating users between apps". _Comment_: This is a privacy principle which is also indeed important. The bad: "The transaction response can include just the unique user identifier along with the access token. (...) This property is analogous to the "sub" property in an ID token. This value MUST uniquely identify this user within the system, and MUST be consistent when the same user logs in to the same application". _Comment_: This is in contradiction with the previous privacy principle. I also read https://oauth.xyz/. The bad: "In XYZ, a client that needs to talk to an API first begins an authorization transaction with the authorization server". _Comment_: For GNAP, this workflow scenario is likely to be incorrect. A client that needs to talk to an API first begins a dialog with ... the resource server. Depending upon the kind of operation the client wants to perform, the resource server informs the client about the categories of the attributes that are needed and about the authorization servers hat are able to issue such privileges. I also browsed through previous emails: The bad: "The client is identified by its key". _Comment _: With such a paradigm, key rollover would be either impossible or rather complicated. A client is identified by ... an identifier. There are diffrent kinds of identifiers whether they are :      (1) temporarily unique,      (2) unique to the resource server,      (3) unique to the authorization server, or      (4) globally unique. *About the new proposed text itself* There is a need to introduce the components of the model and the trust relationships (which are different from those of Auth 2.0 which, by the way, are not mentioned in the charter). OAuth 2.0 did not (and still does not) consider privacy as being important. In this BoF/WG, we should consider privacy as being important. I got rid of the word "delegation": the client does not delegate anything to an authorization server. If it would, this would mean that the authorization server would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy. I used the wording "attributes token" in order to make a wording difference with "access token". It is similar (but different) and its content is meant to be accessible by the client. An authorization server / resource server protocol has not been explicitly mentioned (but has not been explicitly excluded) because such a protocol, when it is related to a client, may come into contradiction with the user's privacy. Denis ** --------------BDF8F96DB3E51A3E83FE7DEF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello,

I joined this BoF during the last week-end and this is my first post.

The current proposed charter is two pages long, whereas the OAuth 2.0 charter was half a page long.
We should attempt to make it shorter ... and clearer. Hereafter a full rewording of the charter, while
the justification for this rewording is placed after it.

New proposed charter

This group is chartered to develop a fine-grained protocol in a client, authorization server and resource server model,
where a client can request to one or more authorization servers one or more attributes that it needs in order to perform
an operation on a resource server, at the time it needs it.

Since the privacy of the user is a concern  privacy by default and privacy by design are considered.

The attributes issued by an authorization server are provided in the form of an attributes token that is cryptographically signed.

The protocol supports attributes tokens usable as narrowly as for a single operation.

The group is chartered to develop mechanisms for conveying target information and identity information within the protocol
including identity attributes such as pseudonyms, email addresses, user names, home addresses, business addresses, phone numbers,
date of birth, age. When a viable existing format is not available for these identity attributes, the group is chartered to define such format.

Through interaction mechanisms supported by the protocol, the resource server allows a user to make a decision whether it is willing or not
to disclose some attributes to perform one or more operations.

Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect,
the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.

This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily
compatible with OAuth 2.0.

As a difference with OAuth 2.0, there is no bilateral trust relationship between authorization servers and resource servers:
for a given category of attributes, a resource server trusts one or more authorization servers.

Resource servers only make available to their clients which access token formats are acceptable.

As another difference with OAuth 2.0, the content of an attributes token is meant to be accessible to the client.

The group will define interoperable protocols between different parties, including:

  • client and authorization server; and
  • client and resource server.

Milestones to include:

  • Architecture of the model,
  • Attributes token definition, including mechanism bindings
  • Core protocol between the different parties


Justification for the rewording

I have re-used the original text whenever it was adequate and concise.

I also read "Identity in XYZ" from: https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz

The good:

"Rather than returning an ID token with potentially stale or large amounts of user information in the authorization response,
let's return only the minimum necessary for the application to function, and let it request additional information that it needs when it needs it".

Comment: This is a "privacy by default" principle which is indeed important.

The good:

"The value MAY vary for the same user when logging in to different applications in order to preserve the user's privacy,
preventing different applications from cross-correlating users between apps".

Comment: This is a privacy principle which is also indeed important.

The bad:

"The transaction response can include just the unique user identifier along with the access token. (...)
This property is analogous to the "sub" property in an ID token. This value MUST uniquely identify this user within the system,
and MUST be consistent when the same user logs in to the same application".

Comment: This is in contradiction with the previous privacy principle.

I also read https://oauth.xyz/.

The bad:

"In XYZ, a client that needs to talk to an API first begins an authorization transaction with the authorization server".

Comment: For GNAP, this workflow scenario is likely to be incorrect. A client that needs to talk to an API first begins a dialog
with ... the resource server. Depending upon the kind of operation the client wants to perform, the resource server informs the client
about the categories of the attributes that are needed and about the authorization servers hat are able to issue such privileges.

I also browsed through previous emails:

The bad:

"The client is identified by its key".

Comment : With such a paradigm, key rollover would be either impossible or rather complicated. A client is identified by ... an identifier.
There are diffrent kinds of identifiers whether they are :

     (1) temporarily unique,
     (2) unique to the resource server,
     (3) unique to the authorization server, or
     (4) globally unique.

About the new proposed text itself

There is a need to introduce the components of the model and the trust relationships (which are different from those of Auth 2.0
which, by the way, are not mentioned in the charter).

OAuth 2.0 did not (and still does not) consider privacy as being important. In this BoF/WG, we should consider privacy as being important.

I got rid of the word "delegation": the client does not delegate anything to an authorization server. If it would, this would mean that the authorization server
would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy.

I used the wording "attributes token" in order to make a wording difference with "access token". It is similar (but different) and its content is meant
to be accessible by the client.

An authorization server / resource server protocol has not been explicitly mentioned (but has not been explicitly excluded) because such a protocol,
when it is related to a client, may come into contradiction with the user's privacy.

Denis


--------------BDF8F96DB3E51A3E83FE7DEF-- From nobody Tue Jun 16 07:30:45 2020 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 16D3B3A15B9 for ; Tue, 16 Jun 2020 07:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, PDS_OTHER_BAD_TLD=2, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sk7iPbP7d6lw for ; Tue, 16 Jun 2020 07:30:42 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 A67373A0D97 for ; Tue, 16 Jun 2020 07:30:41 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id f185so3309123wmf.3 for ; Tue, 16 Jun 2020 07:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=tMDpzTEqTsUe5HskjRSwzxXTFBpzUUUxA0X62ft8eWw=; b=fqr7eFNyffhTyZUIABoI7crtegtzvxjMrP0N356dl1VWzTIcIZkFaAALM1XRDZX2/n cMxGg9WF38c6K5CIGThQ83Z/hRs/wNGauu14N7jBZ8np5XvOK6gfHQ69S95HlOBJSPf5 iaB0AJddhJ7QDd15/fdmdjk8zVQODTtt97OE6AMDbe1bmDVl0HLWbne3JHtQihXQmklB Y12G0iUbZiyn+rGfpsNSGwkgpAoGZLnzBlVtEGPl7pXFJ3YO74G0tzqmU32bpoBYlQCH N+I7rt8H3X4dzjTEPv0VgHLhuTdArZDmgowSPvT1UlMjnFk+uFG6JdPJ3O8+qL/V8VJz uOCQ== 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:message-id :thread-topic:references:in-reply-to:mime-version; bh=tMDpzTEqTsUe5HskjRSwzxXTFBpzUUUxA0X62ft8eWw=; b=VUHMtZC1XAZm5b6P02q/k+W8L0VdVJ+bLvtdro5ZJzXZWo1qD8q2+TNkeU1kbBy4U9 s2/cj9SuiJyvoZhxnDA2Wm5LG89gI5h+M8qErtA3Xt1dl7jRW1w3XfjmjuYX3RbEkqqF gw4ou5RurwPgpsgZEV+uaURmhuEquORCs6JEKbHcz+ja3TKBHdgTNZBTtn/eboOANNvM mgqfk+h4ygEm5FPmS7Hkqufcr+k4a7k7AcMDUlUhPGSOeoisYOF/VS5o/00HuOlbq0fg a5ZvqzXCARJ4j1PIv/I0AKvXedjIcZtp8YgXVasEImRTh7gWawMK2q2oopgIL+mDmtNQ h3fQ== X-Gm-Message-State: AOAM531qOIFzCBVghxBsMIcjy2Ca0OBDpntBYjMDEs8xBN5Ha+wrYNcz coIg6k1baKzU5+a9ANdfLaQ= X-Google-Smtp-Source: ABdhPJyCp2C/qKiN5tdhXDnaj471d/bs28VU4kDNmGnd4RGZld9B2csaw0Wp1uPYXDYrIFs3wkQWvg== X-Received: by 2002:a1c:1d49:: with SMTP id d70mr3566871wmd.49.1592317839882; Tue, 16 Jun 2020 07:30:39 -0700 (PDT) Received: from [10.0.0.140] (bzq-79-176-11-75.red.bezeqint.net. [79.176.11.75]) by smtp.gmail.com with ESMTPSA id t14sm30873008wrb.94.2020.06.16.07.30.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2020 07:30:39 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.37.20051002 Date: Tue, 16 Jun 2020 17:30:37 +0300 From: Yaron Sheffer To: Denis , Message-ID: Thread-Topic: [Txauth] About the proposed charter References: <44e749df-72a2-fa8f-5153-964b95b95f24@free.fr> In-Reply-To: <44e749df-72a2-fa8f-5153-964b95b95f24@free.fr> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3675173438_2051617574" Archived-At: Subject: Re: [Txauth] About the 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, 16 Jun 2020 14:30:44 -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_3675173438_2051617574 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Denis, =20 Welcome to the mailing list and thank you for your proposal. =20 The charter proposal you read is what the IESG will be reviewing at their t= elechat next week. =20 Following their review and hopefully approval, there will be an =E2=80=9Cexternal= review=E2=80=9D period, at which time you=E2=80=99ll be able to offer your suggestions = for improving the charter text. =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 Denis Date: Tuesday, June 16, 2020 at 17:00 To: Subject: [Txauth] About the proposed charter =20 Hello, I joined this BoF during the last week-end and this is my first post. The current proposed charter is two pages long, whereas the OAuth 2.0 chart= er was half a page long.=20 We should attempt to make it shorter ... and clearer. Hereafter a full rewo= rding of the charter, while=20 the justification for this rewording is placed after it.=20 New proposed charter This group is chartered to develop a fine-grained protocol in a client, aut= horization server and resource server model,=20 where a client can request to one or more authorization servers one or more= attributes that it needs in order to perform=20 an operation on a resource server, at the time it needs it. Since the privacy of the user is a concern privacy by default and privacy = by design are considered. The attributes issued by an authorization server are provided in the form o= f an attributes token that is cryptographically signed. The protocol supports attributes tokens usable as narrowly as for a single = operation. The group is chartered to develop mechanisms for conveying target informati= on and identity information within the protocol=20 including identity attributes such as pseudonyms, email addresses, user nam= es, home addresses, business addresses, phone numbers,=20 date of birth, age. When a viable existing format is not available for thes= e identity attributes, the group is chartered to define such format. Through interaction mechanisms supported by the protocol, the resource serv= er allows a user to make a decision whether it is willing or not=20 to disclose some attributes to perform one or more operations. Although the artifacts for this work are not intended or expected to be bac= kwards-compatible with OAuth 2.0 or OpenID Connect,=20 the group will attempt to simplify migrating from OAuth 2.0 and OpenID Conn= ect to the new protocol where possible. This group is not chartered to develop extensions to OAuth 2.0, and as such= will focus on new technological solutions not necessarily=20 compatible with OAuth 2.0. As a difference with OAuth 2.0, there is no bilateral trust relationship be= tween authorization servers and resource servers:=20 for a given category of attributes, a resource server trusts one or more au= thorization servers.=20 Resource servers only make available to their clients which access token fo= rmats are acceptable. As another difference with OAuth 2.0, the content of an attributes token is= meant to be accessible to the client. The group will define interoperable protocols between different parties, in= cluding: client and authorization server; and client and resource server. Milestones to include: Architecture of the model, Attributes token definition, including mechanism bindings Core protocol between the different parties Justification for the rewording I have re-used the original text whenever it was adequate and concise.=20 I also read "Identity in XYZ" from: https://aaronparecki.com/2019/07/18/17/= adding-identity-to-xyz The good: "Rather than returning an ID token with potentially stale or large amounts = of user information in the authorization response,=20 let's return only the minimum necessary for the application to function, an= d let it request additional information that it needs when it needs it". Comment: This is a "privacy by default" principle which is indeed important= . The good: "The value MAY vary for the same user when logging in to different applicat= ions in order to preserve the user's privacy,=20 preventing different applications from cross-correlating users between apps= ". Comment: This is a privacy principle which is also indeed important. The bad: "The transaction response can include just the unique user identifier along= with the access token. (...) This property is analogous to the "sub" property in an ID token. This value= MUST uniquely identify this user within the system, and MUST be consistent when the same user logs in to the same application". Comment: This is in contradiction with the previous privacy principle. I also read https://oauth.xyz/. The bad: "In XYZ, a client that needs to talk to an API first begins an authorizatio= n transaction with the authorization server". Comment: For GNAP, this workflow scenario is likely to be incorrect. A clie= nt that needs to talk to an API first begins a dialog=20 with ... the resource server. Depending upon the kind of operation the clie= nt wants to perform, the resource server informs the client=20 about the categories of the attributes that are needed and about the author= ization servers hat are able to issue such privileges. I also browsed through previous emails: The bad: "The client is identified by its key". Comment : With such a paradigm, key rollover would be either impossible or = rather complicated. A client is identified by ... an identifier.=20 There are diffrent kinds of identifiers whether they are : (1) temporarily unique,=20 (2) unique to the resource server,=20 (3) unique to the authorization server, or=20 (4) globally unique. About the new proposed text itself There is a need to introduce the components of the model and the trust rela= tionships (which are different from those of Auth 2.0=20 which, by the way, are not mentioned in the charter). OAuth 2.0 did not (and still does not) consider privacy as being important.= In this BoF/WG, we should consider privacy as being important. I got rid of the word "delegation": the client does not delegate anything t= o an authorization server. If it would, this would mean that the authorizati= on server=20 would be able to act as the client and could know everything that the clien= t will do, which comes into contradiction with the user's privacy. I used the wording "attributes token" in order to make a wording difference= with "access token". It is similar (but different) and its content is meant= =20 to be accessible by the client. An authorization server / resource server protocol has not been explicitly = mentioned (but has not been explicitly excluded) because such a protocol,=20 when it is related to a client, may come into contradiction with the user's= privacy. Denis -- Txauth mailing list Txauth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3675173438_2051617574 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Denis,

&n= bsp;

Welcome to the mailing list and thank you f= or your proposal.

 

The charter proposal you read is what the IESG will be review= ing at their telechat next week.

 = ;

Following their review and hopefully approval,= there will be an =E2=80=9Cexternal review=E2=80=9D period, at which time you=E2=80=99ll be ab= le to offer your suggestions for improving the charter text.

<= p class=3DMsoNormal> 

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

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Denis &= lt;denis.ietf@free.fr>
Date: Tuesday, June 16, 2020 at 17:00To: <txauth@ietf.org>
Subject: [Txauth] About the pr= oposed charter

 = ;

Hello,

I joi= ned this BoF during the last week-end and this is my first post.=

The current proposed charter is two pages long, where= as the OAuth 2.0 charter was half a page long.
We should attempt to make= it shorter ... and clearer. Hereafter a full rewording of the charter, whil= e
the justification for this rewording is placed after it.

New proposed charter

This group is chartered to develop = a fine-grained protocol in a client, authorization server and resource serve= r model,
where a client can request to one or more auth= orization servers one or more attributes that it needs in order to perform <= br>an operation on a resource server, at the time it needs it.

Since the privacy of the user is a concern  privacy by defau= lt and privacy by design are considered.

The attribu= tes issued by an authorization server are provided in the form of an attribu= tes token that is cryptographically signed.

The protocol supports attributes tokens usable as narrowly as for a single= operation.

The group is chartered to develop mechan= isms for conveying target information and identity information within the pr= otocol
including identity attributes such as pseudonyms, email addresses= , user names, home addresses, business addresses, phone numbers,
date of= birth, age. When a viable existing format is not available for these identi= ty attributes, the group is chartered to define such format.

Through interaction mechanisms supported by the protocol, the resou= rce server allows a user to make a decision whether it is willing or not to disclose some attributes to perform one or more operations.
Although the artifacts for this work are not intended or expecte= d to be backwards-compatible with OAuth 2.0 or OpenID Connect,
the group= will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the= new protocol where possible.

This group is not char= tered to develop extensions to OAuth 2.0, and as such will focus on new tech= nological solutions not necessarily
compatible with OAuth 2.0.
As a difference with OAuth 2.0, there is no bilateral trust r= elationship between authorization servers and resource servers:
for a gi= ven category of attributes, a resource server trusts one or more authorizati= on servers.

Resource servers only make available to their clients wh= ich access token formats are acceptable.

As another = difference with OAuth 2.0, the content of an attributes token is meant to be= accessible to the client.

The group will define int= eroperable protocols between different parties, including:=

  • client and authorizat= ion server; and
  • c= lient and resource server.

Milestone= s to include:

  • = Architecture of the model,
  • Attributes token definition, including mechanism binding= s
  • Core protocol b= etween the different parties


= Justification for the rewording

I have= re-used the original text whenever it was adequate and concise.

I a= lso read "Identity in XYZ" from: https://aaro= nparecki.com/2019/07/18/17/adding-identity-to-xyz

T= he good:

"Rather than returning an ID token with potentially sta= le or large amounts of user information in the authorization response,
l= et's return only the minimum necessary for the application to function, and = let it request additional information that it needs when it needs it".<= br>
Comment: This is a "privacy by default" principle wh= ich is indeed important.

The good:

"The value MAY vary fo= r the same user when logging in to different applications in order to preser= ve the user's privacy,
preventing different applications from cross-corr= elating users between apps".

Comment: This is a privacy p= rinciple which is also indeed important.

The bad:

"The tr= ansaction response can include just the unique user identifier along with th= e access token. (...)
This property is analogous to the "sub" p= roperty in an ID token. This value MUST uniquely identify this user within t= he system,
and MUST be consistent when the same user logs in to the same = application".

Comment: This is in contradiction with the = previous privacy principle.

I also read https://oauth.xyz/.

The bad:
<= br>"In XYZ, a client that needs to talk to an API first begins an autho= rization transaction with the authorization server".

Comment<= /u>: For GNAP, this workflow scenario is likely to be incorrect. A client th= at needs to talk to an API first begins a dialog
with ... the resource s= erver. Depending upon the kind of operation the client wants to perform, the= resource server informs the client
about the categories of the attribut= es that are needed and about the authorization servers hat are able to issue= such privileges.

I also browsed through previous emails:

The = bad:

"The client is identified by its key".

Comme= nt : With such a paradigm, key rollover would be either impossible or ra= ther complicated. A client is identified by ... an identifier.
There are= diffrent kinds of identifiers whether they are :

   &= nbsp; (1) temporarily unique,
     (2) unique to the= resource server,
     (3) unique to the authorizati= on server, or
     (4) globally unique.

Ab= out the new proposed text itself

There= is a need to introduce the components of the model and the trust relationsh= ips (which are different from those of Auth 2.0
which, by the way, are n= ot mentioned in the charter).

OAuth 2.0 did not (and still does not) = consider privacy as being important. In this BoF/WG, we should consider priv= acy as being important.

I got rid of the word "delegation":= the client does not delegate anything to an authorization server. If it wou= ld, this would mean that the authorization server
would be able to act a= s the client and could know everything that the client will do, which comes = into contradiction with the user's privacy.

I used the wording "= attributes token" in order to make a wording difference with "acce= ss token". It is similar (but different) and its content is meant
t= o be accessible by the client.

An authorization server / resource ser= ver protocol has not been explicitly mentioned (but has not been explicitly = excluded) because such a protocol,
when it is related to a client, may c= ome into contradiction with the user's privacy.

Denis



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

--B_3675173438_2051617574-- From nobody Tue Jun 16 07:42:58 2020 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 2FD7F3A1697 for ; Tue, 16 Jun 2020 07:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 jFX5tBCVHJNQ for ; Tue, 16 Jun 2020 07:42:55 -0700 (PDT) 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 A6F333A169A for ; Tue, 16 Jun 2020 07:42:54 -0700 (PDT) Received: from [192.168.1.14] (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 05GEgkLd014829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Jun 2020 10:42:47 -0400 From: Justin Richer Message-Id: <1B439ED3-E7DF-49B2-A064-4CB5CC3147A0@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_91441375-A1E3-4908-ADC9-C98B61847041" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 16 Jun 2020 10:42:46 -0400 In-Reply-To: Cc: Mike Jones , "vittorio.bertocci@auth0.com" , Peter Saint-Andre , Fabien Imbault , Jared Jennings , Amanjeev Sethi , "txauth@ietf.org" To: Dick Hardt References: <5443710B-05DB-4C4D-AC4B-0D8D173E131B@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] GNAP it is 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, 16 Jun 2020 14:42:57 -0000 --Apple-Mail=_91441375-A1E3-4908-ADC9-C98B61847041 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t believe we should add a proposed pronunciation to the = charter. It seems silly to focus on this so much. =E2=80=94 Justin > On Jun 15, 2020, at 6:14 PM, Dick Hardt wrote: >=20 > I agree we should be prepared for both. Can we agree that we can be = consistent? Personally I don't care which we choose -- I only care that = we choose one. >=20 > I was working to address the concern that you (Justin) had brought up: >=20 >> This is ok, but it has a couple downsides. The pronunciation of a = hard =E2=80=9Cg=E2=80=9D or not is going to potentially be confusing, as = is the fact that it looks like it=E2=80=99s part of the GNU project = because of that. >>=20 >>=20 >=20 > On Mon, Jun 15, 2020 at 1:56 PM Justin Richer > wrote: > I agree with Mike, in that we should get used to answering to both. >=20 > In my head, it reads with a hard =E2=80=9CG=E2=80=9D, at least = partially because of the Smurfs video=E2=80=99s legacy. >=20 > =E2=80=94 Justin >=20 >> On Jun 15, 2020, at 3:38 PM, Mike Jones = > wrote: >>=20 >> I don=E2=80=99t care a lot one way or the other. My main point is = that no matter what guidance we give, many people are likely to = pronounce the =E2=80=9CG=E2=80=9D. If we try to insist on it being = silent, we should get used to the fact that we=E2=80=99ll probably be = hearing both pronunciations. >> =20 >> -- Mike >> =20 >> P.S. Thanks for the Smurfs link, Vittorio! >> =20 >> From: vittorio.bertocci@auth0.com = >=20 >> Sent: Monday, June 15, 2020 12:25 PM >> To: 'Dick Hardt' >; 'Peter Saint-Andre' > >> Cc: Mike Jones >; 'Jared Jennings' = >; 'Amanjeev = Sethi' >; 'Fabien Imbault' = >; = txauth@ietf.org >> Subject: RE: [Txauth] GNAP it is >> =20 >> Perhaps not to be taken too seriously, but here=E2=80=99s prior art = on GNAP pronunciation. >> As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on = the Smurfs comic and was reprised in a cartoon episode as well. >> You=E2=80=99ll find few examples around 3:30 >> = https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbclid=3D= IwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ = >> =20 >> From: Txauth > On Behalf Of Dick Hardt >> Sent: Monday, June 15, 2020 12:18 PM >> To: Peter Saint-Andre > >> Cc: Mike Jones >; Jared Jennings = >; Amanjeev = Sethi >; Fabien Imbault = >; = txauth@ietf.org >> Subject: Re: [Txauth] GNAP it is >> =20 >> Checking in again on pronunciation. >> =20 >> Mike: do you still have concerns with a silent 'G'? >> =20 >> Anyone else have concerns? >> =20 >> I'd like to nip pronunciation confusion in the bud by having the = recommended pronunciation in the charter. >> =20 >> =20 >> =E1=90=A7 >> =20 >> On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre > wrote: >> Looks like we were caught gnapping. ;-) >>=20 >> OK, that's the last of my snarky comments, let's get to work! >>=20 >> Peter >>=20 >> On 6/7/20 2:09 PM, Dick Hardt wrote: >> > It is if you are familiar with any of the GNU projects. >> >=20 >> > https://www.gnu.org/gnu/pronunciation.en.html = >> >=20 >> > A quick search on the internet has the "normal" pronunciation of = "gnu" >> > to have a silent 'g'. >> >=20 >> > https://www.howtopronounce.com/gnu = >> > https://dictionary.cambridge.org/us/pronunciation/english/gnu = >> >=20 >> >=20 >> > =E1=90=A7 >> >=20 >> > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones = >> > >> wrote: >> >=20 >> > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation = of GNU. I >> > think that=E2=80=99s the most natural way to read it.____ >> >=20 >> > __ __ >> >=20 >> > -- = Mike____ >> >=20 >> > __ __ >> >=20 >> > *From:* Txauth >> > >> *On Behalf Of *Dick Hardt >> > *Sent:* Sunday, June 7, 2020 12:45 PM >> > *To:* Amanjeev Sethi = >> >> > *Cc:* Fabien Imbault >> > >>; Jared Jennings >> > = >>; >> > txauth@ietf.org = > >> > *Subject:* Re: [Txauth] GNAP it is____ >> >=20 >> > __ __ >> >=20 >> > Anyone have objection to the recommended pronunciation being = the >> > English word "nap", as in "gnaw"?____ >> >=20 >> > __ __ >> >=20 >> > If not, then we could add a pronunciation recommendation to the >> > Charter.____ >> >=20 >> > __ __ >> >=20 >> > =E1=90=A7____ >> >=20 >> > __ __ >> >=20 >> > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi >> > >> wrote:____ >> >=20 >> > Vote for 'G' silent, as in 'lagnappe' ;)____ >> >=20 >> > __ __ >> >=20 >> > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____ >> >=20 >> > I vote for G silent. For the reason it's most common to >> > pronounce, especially for those not familiar with open >> > source usages.____ >> >=20 >> > __ __ >> >=20 >> > On Sat, Jun 6, 2020, 08:45 Dick Hardt = >> > >> wrote:____ >> >=20 >> > The obvious pronunciation choices are:____ >> >=20 >> > __ __ >> >=20 >> > nap (silent g as in gnaw)____ >> >=20 >> > __ __ >> >=20 >> > guh-nap (as in the GNU OS >> > - https://www.gnu.org/gnu/pronunciation.en..html = >> > >)____ >> >=20 >> > __ __ >> >=20 >> > gee-nap (as in G-man - government man >> > - https://en.wikipedia.org/wiki/G-man)____ = >> >=20 >> > __ __ >> >=20 >> > __ __ >> >=20 >> > __ __ >> >=20 >> > =E1=90=A7____ >> >=20 >> > __ __ >> >=20 >> > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault >> > >> > >> wrote:____ >> >=20 >> > So, let's adopt a GNAP! We can even come with a >> > little mascot (a bit like go gopher) as = imagined >> > by http://elisegravel.com/blog/adopte-un-gnap/ = , >> > loved by little Canadians :-) ____ >> >=20 >> > __ __ >> >=20 >> > Just to be sure, how do you recommand we = pronounce >> > it? ____ >> >=20 >> > __ __ >> >=20 >> > Looking forward to the next steps too.. ____ >> >=20 >> > __ __ >> >=20 >> > Thxs____ >> >=20 >> > Fabien____ >> >=20 >> > --____ >> >=20 >> > Txauth mailing list____ >> >=20 >> > Txauth@ietf.org = >____ >> >=20 >> > = https://www.ietf.org/mailman/listinfo/txauth____ = >> >=20 >> > --____ >> >=20 >> > Txauth mailing list____ >> >=20 >> > Txauth@ietf.org = >____ >> >=20 >> > https://www.ietf.org/mailman/listinfo/txauth____ = >> >=20 >> > -- ____ >> >=20 >> > Txauth mailing list____ >> >=20 >> > Txauth@ietf.org = >____ >> >=20 >> > 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 = --Apple-Mail=_91441375-A1E3-4908-ADC9-C98B61847041 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = don=E2=80=99t believe we should add a proposed pronunciation to the = charter. It seems silly to focus on this so much.

 =E2=80=94 Justin

On Jun 15, 2020, at 6:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I = agree we should be prepared for both. Can we agree that we can be = consistent? Personally I don't care which we choose -- I only care that = we choose one.

I was working to address the concern that = you (Justin) had brought up:

This is ok, but it has = a couple downsides. The pronunciation of a hard =E2=80=9Cg=E2=80=9D or = not is going to potentially be confusing, as is the fact that it looks = like it=E2=80=99s part of the GNU project because of that.



On Mon, Jun = 15, 2020 at 1:56 PM Justin Richer <jricher@mit.edu> wrote:
I agree with Mike, in that we should get used to = answering to both.

In = my head, it reads with a hard =E2=80=9CG=E2=80=9D, at least partially = because of the Smurfs video=E2=80=99s legacy.

 =E2=80=94 Justin

On Jun 15, 2020, at 3:38 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

I don=E2=80=99t care a lot one = way or the other.  My main point is that no matter what guidance we = give, many people are likely to pronounce the =E2=80=9CG=E2=80=9D.  = If we try to insist on it being silent, we should get used to the fact = that we=E2=80=99ll probably be hearing both pronunciations.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
P.S.  Thanks for the Smurfs = link, Vittorio!
 
From: vittorio.bertocci@auth0.com <vittorio.bertocci@auth0.com> 
Sent: Monday, June 15, 2020 12:25 PM
To: 'Dick Hardt' <dick.hardt@gmail.com>; 'Peter Saint-Andre' <stpeter@mozilla.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; 'Jared Jennings' <jaredljennings@gmail.com>; 'Amanjeev Sethi' <aj@amanjeev.com>; 'Fabien Imbault' <fabien.imbault@gmail.com>; txauth@ietf.org
Subject: RE: [Txauth] GNAP = it is
 
Perhaps not to be taken too seriously, but here=E2=80=99s = prior art on GNAP pronunciation.
As = Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the = Smurfs comic and was reprised in a cartoon episode as well.
You=E2=80=99ll find few examples around 3:30
 https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyou= tu.be&fbclid=3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WB= JgPbpQ
 
From: Txauth <txauth-bounces@ietf.org> On Behalf Of Dick Hardt
Sent: Monday, = June 15, 2020 12:18 PM
To: Peter Saint-Andre <stpeter@mozilla.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; Jared Jennings <jaredljennings@gmail.com>; Amanjeev Sethi <aj@amanjeev.com>; Fabien Imbault <fabien.imbault@gmail.com>; txauth@ietf.org
Subject: Re: [Txauth] GNAP = it is
 
Checking in again on pronunciation.
 
Mike: = do you still have concerns with a silent 'G'?
 
Anyone = else have concerns?
 
I'd = like to nip pronunciation confusion in the bud by having the recommended = pronunciation in the charter.
 
 
=E1=90=A7
 
On = Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre <stpeter@mozilla.com> wrote:
Looks like we were caught gnapping. ;-)

OK, that's the last of my snarky comments, let's get to = work!

Peter

On = 6/7/20 2:09 PM, Dick Hardt wrote:
> It is if you are = familiar with any of the GNU projects.
> 
> https://www.gnu.org/gnu/pronunciation.en.html
> 
> A quick = search on the internet has the "normal" pronunciation of "gnu"
> to have a silent 'g'.
> 
> https://www.howtopronounce.com/gnu
> https://dictionary.cambridge.org/us/pronunciation/english/gnu
> 
> 
> =E1=90=A7
> 
> On Sun, Jun 7, 2020 at 12:51 = PM Mike Jones <Michael.Jones@microsoft.com
> = <mailto:Michael.Jones@microsoft.com>> wrote:
> 
>  =    I had assumed Guh-Nap =E2=80=93 parallel to the = pronunciation of GNU.  I
>    =  think that=E2=80=99s the most natural way to read it.____
> 
>  =    __ __
> 
>    =             &n= bsp;           &nbs= p;            =             &n= bsp;      -- Mike____
> 
>    =  __ __
> 
>     *From:* Txauth <txauth-bounces@ietf.org
>    =  <mailto:txauth-bounces@ietf.org>> *On Behalf Of *Dick = Hardt
>     *Sent:* Sunday, June 7, 2020 = 12:45 PM
>     *To:* Amanjeev Sethi = <aj@amanjeev.com <mailto:aj@amanjeev.com>>
>    =  *Cc:* Fabien Imbault <fabien.imbault@gmail.com
>    =  <mailto:fabien.imbault@gmail.com>>; Jared Jennings
>     <jaredljennings@gmail.com <mailto:jaredljennings@gmail.com>>;
>  =    txauth@ietf.org <mailto:txauth@ietf.org>
>    =  *Subject:* Re: [Txauth] GNAP it is____
> 
>    =  __ __
> 
>     Anyone have objection to the = recommended pronunciation being the
>    =  English word "nap", as in "gnaw"?____
> 
>    =  __ __
> 
>     If not, then we could add a = pronunciation recommendation to the
>    =  Charter.____
> 
>     __ __
> 
>     =E1=90=A7____> 
>  =    __ __
> 
>     On Sat, = Jun 6, 2020 at 8:03 AM Amanjeev Sethi <aj@amanjeev.com
>    =  <mailto:aj@amanjeev.com>> wrote:____
> 
>        =  Vote for 'G' silent, as in 'lagnappe' ;)____
> 
>        =  __ __
> 
>         On Sat, Jun 6, 2020, at = 10:52 AM, Jared Jennings wrote:____
> 
>        =      I vote for G silent. For the reason it's most common = to
>            =  pronounce, especially for those not familiar with open
>             source = usages.____
> 
>            =  __ __
> 
>             On Sat, = Jun 6, 2020, 08:45 Dick Hardt <dick.hardt@gmail.com
>    =          <mailto:dick.hardt@gmail.com>> wrote:____
> 
>  =                The obvious = pronunciation choices are:____
> 
>        =          __ __
> 
>        =          nap (silent g as in gnaw)____
> 
>  =                __ __
> 
>  =                guh-nap (as in = the GNU OS
>            =      - https://www.gnu.org/gnu/pronunciation.en..html
>                =  <https://www.gnu.org/gnu/pronunciation.en.html>)____
> 
>  =                __ __
> 
>  =                gee-nap (as in = G-man - government man
>        =          - https://en.wikipedia.org/wiki/G-man)____
> 
>  =                __ __
> 
>  =                __ __
> 
>  =                __ __
> 
>  =                =E1=90=A7____> 
>  =                __ __
> 
>  =                On Sat, Jun 6, = 2020 at 1:34 AM Fabien Imbault
>      =            <fabien.imbault@gmail.com
>    =              <mailto:fabien.imbault@gmail.com>> wrote:____
> 
>  =                    So, = let's adopt a GNAP! We can even come with a
>  =                   =  little mascot (a bit like go gopher) as imagined
>                =      by http://elisegravel.com/blog/adopte-un-gnap/,
>                =      loved by little Canadians :-) ____
> 
>  =                   =  __ __
> 
>                =      Just to be sure, how do you recommand we = pronounce
>            =          it? ____
> 
>        =              __ __
> 
>  =                   =  Looking forward to the next steps too.. ____
> 
>  =                   =  __ __
> 
>                =      Thxs____
> 
>        =              Fabien____
> 
>  =                   =  --____
> 
>                =      Txauth mailing list____
> 
>        =              Txauth@ietf.org <mailto:Txauth@ietf.org>____
> 
>        =              https://www.ietf.org/mailman/listinfo/txauth____
> 
>  =                --____
> 
>  =                Txauth mailing = list____
> 
>                =  Txauth@ietf.org <mailto:Txauth@ietf.org>____
> 
>        =          https://www.ietf.org/mailman/listinfo/txauth____
> 
>  =            -- ____
> 
>  =            Txauth mailing list____
> 
>  =            Txauth@ietf.org <mailto: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=_91441375-A1E3-4908-ADC9-C98B61847041-- From nobody Tue Jun 16 09:39:03 2020 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 2DE063A07D7 for ; Tue, 16 Jun 2020 09:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 DxvFGzTPoMEu for ; Tue, 16 Jun 2020 09:38:53 -0700 (PDT) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 3E27C3A00C1 for ; Tue, 16 Jun 2020 09:38:50 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id m26so1086131lfo.13 for ; Tue, 16 Jun 2020 09:38:50 -0700 (PDT) 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=HIDH6o3H7zeMfUgLIrqZPma0A3gotIr2w3keZGbikNo=; b=QZkZTszcWdScLZMzTvgvyHa+MSfLdFdsuBlssP0VO9zmkYFe3/ecBQT7PXxMbY+jIC Mdcg12INSki+liiyF5kBed0xrsDWU44/mmKTraMWmZV6upC+xWBXc+GEpqdubSkG3VNL pyZvNfayFNyJGIgCAzmwu5ga66WQlwDa+4WvgNbjFZwwjpTAl/Kya7B8l/z7k/0pjCNi iQ/fcda/wMYvjSVFWwZg8k/5+RR+fwhVA0o7NLkl5J8BbJhDOslMYY2EU3RAjnr7SUBJ sudMW/RhjrFLxelZqkh3uxAzEVgbJqwIT5SaboNVeLXWqzb+JZeIbwp7vSJxQGDVlDdi +U6w== 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=HIDH6o3H7zeMfUgLIrqZPma0A3gotIr2w3keZGbikNo=; b=URsikgxCNvq43HPLFQORdW6tPbDMCzoWtka6JuKbeBwkooDSaLJcVDNtYLLqBaDs1L 3EW7awWgNG20iupDaGH6a5bIJbpJ2x09Uyal3tzrFisIzX123K5Ffekl9tMHGdxjXbJI Y1vEW3IZrQRBq4XtyXHbX3QvS/g+77mrHnhsYXGH+cn/fPRYJCD+qMFaf0tG7R+YhhWe wul9kvP+AYbGJxT2JMuCBdYyA7NgDgGiYllZbBZAfTLS8c03QuWaeotOBdQ73iMWGfck XhckipNZdxICVq6enC8R8Du+xyauSgg3aSLdHUqhd4NMm+DZQREPPoXbLft8yggbThkg 9m3w== X-Gm-Message-State: AOAM530eBPfhKlmBQH3nDB5LGlePsgpjlJi25r6pI9JJ03RQBHH6Fe7O R3tvncj0hc7DlkqznB2ZM4D0L5Qus9r4grAQ0LM= X-Google-Smtp-Source: ABdhPJyTFSdICj4d1JDM4d7qmi8YfpysnOR8cTPoOHWp9uyjfDsm2ldV+Fccbr7n7aDKWp8Q7RdzGh1jb/rlXBJbzjY= X-Received: by 2002:a05:6512:10d3:: with SMTP id k19mr2165611lfg.78.1592325528236; Tue, 16 Jun 2020 09:38:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 16 Jun 2020 09:38:22 -0700 Message-ID: To: Mike Jones Cc: Justin Richer , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007a376305a8362d15" Archived-At: Subject: Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs XAuth-08) 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, 16 Jun 2020 16:39:02 -0000 --0000000000007a376305a8362d15 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It was pointed out to me that the OAuth query parameters are registered, and therefore an extension point. I was sloppy in my language, so let me clarify: The query parameters are a general purpose extension point for adding new features that don't belong somewhere else, but it was not called out as an extension point in the Extensibility section of 6749 https://tools.ietf.org/html/rfc6749#section-8 An extension defining a new grant type would use the defined extension point for grants rather than the general purpose extension point of adding a new query parameter. The specification defines this extension point https://tools.ietf.org/html/rfc6749#section-8.3 Similarly in GNAP, I think we should support multiple schemas, and we should define how new schemas are added. My proposal is that the claims object members are schema objects, and the contents of the schema objects are defined by the schema. =E1=90=A7 On Mon, Jun 15, 2020 at 6:25 PM Mike Jones wrote: > I completely agree with Dick that, as written, XYZ is defining a new > ad-hoc identity schema, which is unnecessary and counter-productive (and > probably violates our charter). > > > > I agree that explicitly reusing existing claims schemas, rather than > inventing new ones, is one of the clear and compelling advantages of XAut= h > over XYZ. I=E2=80=99d previously suggested that the Claims section of XY= Z > > be revised to not define new =E2=80=9Cemail=E2=80=9D and =E2=80=9Csubject= =E2=80=9D claims with an unknown > schema but that hasn=E2=80=99t been done. Other instances of this proble= m occur in > the XYZ Transaction Request > > and Transaction Response > > sections. > > > > Getting this right matters. > > > > -- Mike > > > > *From:* Dick Hardt > *Sent:* Monday, June 15, 2020 5:39 PM > *To:* Justin Richer > *Cc:* txauth@ietf.org; Mike Jones > *Subject:* Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs > XAuth-08) > > > > comments inline ... > > > > On Wed, Jun 10, 2020 at 8:07 AM Justin Richer wrote: > > > > > > On Jun 9, 2020, at 4:14 PM, Dick Hardt wrote: > > > > Forking this topic to a new thread > > > > +Mike as he has expressed concern about creating new identity claims > > > > On Tue, Jun 9, 2020 at 9:10 AM Justin Richer wrote: > > > > > > On Jun 8, 2020, at 5:33 PM, Dick Hardt wrote: > > > > > > > > On Mon, Jun 8, 2020 at 1:02 PM Justin Richer wrote: > > > > > > I don't follow how this would work. Perhaps you could provide an example > in JSON? > > > > One method is defining a new value inside the XYZ =E2=80=9Cclaims=E2=80= =9D request object > that maps to a specific sub-schema: > > > > claims: { > > =E2=80=9Csubject=E2=80=9D: true, > > =E2=80=9Cemail=E2=80=9D: true, > > =E2=80=9Coidc=E2=80=9D: { > > "userinfo": > > { > > "given_name": {"essential": true}, > > "nickname": null, > > "email": {"essential": true}, > > "email_verified": {"essential": true}, > > "picture": null, > > "http://example.info/claims/groups": null > > }, > > "id_token": > > { > > "auth_time": {"essential": true}, > > "acr": {"values": ["urn:mace:incommon:iap:silver"] } > > } > > } > > } > > > > That should look pretty familiar. Alternatively, this could be done with = a > separate top-level request object field: > > > > > > claims: { > > =E2=80=9Csubject=E2=80=9D: true, > > =E2=80=9Cemail=E2=80=9D: true > > }, > > =E2=80=9Coidc_claims_request=E2=80=9D: { > > "userinfo": > > { > > "given_name": {"essential": true}, > > "nickname": null, > > "email": {"essential": true}, > > "email_verified": {"essential": true}, > > "picture": null, > > "http://example.info/claims/groups": null > > }, > > "id_token": > > { > > "auth_time": {"essential": true}, > > "acr": {"values": ["urn:mace:incommon:iap:silver"] } > > } > > } > > > > In both cases the AS is going to need to knit them together into a > sensible request policy, especially since the OIDC claims query language > has overlapping implications to one particular resource, the UserInfo > endpoint. My contention wasn=E2=80=99t with your proposed solution, my co= ntention > was you claiming that XYZ has a fixed schema and is therefore limited in > extensibility. > > > > One of the objectives of this work is to have extension points. My point > was that XAuth had a clear extension point for adding schemas. How to > extend XYZ was not clear in your proposal. > > > > > > I am sorry that the extensibility of the protocol was not clear. It is > stated in each section that additional items can be added, and I have > stated repeatedly that it=E2=80=99s extensible and demonstrated how, here= on this > list. > > > > I think the XAuth proposal is better than the two examples you proposed. > In your first example, the schema is a second class schema, and in your > second example, claims are spread across to top level options. Both of > these pollute other schemas. > > > > > > Not surprisingly, I disagree about the cleanliness of XAuth=E2=80=99s pro= posed > approach. The proposal here adds external schemas as extensions instead o= f > relying on them internally. > > > > If anything, I think that the OpenID Foundation would be the ones to > define how to make an OIDC claims request using this protocol, not us, > since they own and control that query syntax and everything it implies. W= e > can provide a means of extension. > > > > I also think there=E2=80=99s value in defining a set of core interoperabl= e > identity fields, which themselves could also be extended. > > > > All of these mechanisms should be controlled by some combination of > registries and collision-resistant namespaces, which is the approach I=E2= =80=99ve > taken for extensibility throughout XYZ. > > > > > > JSON by its nature is extensible. Adding new members to an object is > straight forward. XYZ is not unique here. It sounds like your idea of > extensibility is telling people that they can add new members to JSON. Of > course they can. That is like saying you can add new query parameters to = a > front channel OAuth 2 request. > > > > > > Yes, exactly. And that=E2=80=99s exactly how OAuth 2 has been extended. I= =E2=80=99m glad > you see that now. > > > > I think you are missing my point. Adding query parameters to OAuth 2 was > not a defined extension point. It was inherent in how query parameters > work. OAuth 2 did define the type of grant as an extension point. > > > > > > My concern was that XYZ does not have a clear way to add new identity > claim schemas. You have two examples, add a schema as a member of the > claims object, which is mixing claims with schema extensions, or adding a > root member, which is then putting claims into more than one place. It is > not clear where to add a new schema, so we could easily end up with new > schemas in both places. That sounds confusing. > > > > In XAuth, the members of the claims object are the schema. Adding a new > schema is done one, consistent way. > > > > I provided a couple examples off the cuff of possible ways to extend > something, as your base claim was that XYZ could not be extended with new > or external query schemas. Of the two, I think that it makes more sense f= or > it to be a separate top-level object. Why? Because the OIDC =E2=80=9Cclai= ms=E2=80=9D > request syntax not only dictates claims within the OIDC schema, it also > specifies how the information comes back. The XYZ claims request talks > about information that comes back in the XYZ claims section of the > response. > > > > I would put the OIDC request to acquire claims from a user_info endpoint > into the authorization request so that there is a consistent way to get > back an access token, as opposed to a new top level object that could > return claims and/or an access token. > > > > Since the OIDC request allows for targeting specifically to the ID token > and UserInfo Endpoint, I think it is much cleaner to be at the top level = as > its own thing. > > > > My point is that XYZ does not *define* how to add new schemas. An > extension can add anything it wants to the JSON, and as you have shown > there is more than one way to do it, and I think long term when there are > divergent mechanisms, the code is going to get ugly in detecting what > claims are being asked for. > > > > > > > > > > wrt. "defining a set of core interoperable identity fields", the charter > says we should be NOT develop a new schema: > > > > The group is chartered to develop mechanisms for conveying identity > information within the protocol including identifiers (such as email > addresses, phone numbers, usernames, and subject identifiers) and > assertions (such as OpenID Connect ID Tokens, SAML Assertions, and > Verifiable Credentials). The group is not chartered to develop new > formats for identifiers or assertions, nor is the group chartered to > develop schemas for user information, profiles, or other identity > attributes, unless a viable existing format is not available. > > > > wrt. OIDC claims, the charter explicitly calls out developing mechanisms > for conveying ... OIDC ID Tokens. > > > > =E1=90=A7 > > > > Precisely: the charter says we will have a way to convey identifiers and > assertions. The XYZ =E2=80=9Cclaims=E2=80=9D section lists identifiers th= at can come back, > in plain text, and assertions, that can also come back along side them. > > > > These claims are a schema. We will have an IANA entry for what claims are > allowed inside of the claims object. This is defining a new schema. > > > > It=E2=80=99s not a full query language and isn=E2=80=99t intended to be, = and I think that > it would actually be dangerous for this to be a full identity schema, but > it is itself extensible internally if someone wants to do that. Claiming > that a list of identifiers is =E2=80=9Cdeveloping a new schema=E2=80=9D i= s an argument > several bridges too far from reality. > > > > You are not inventing new identifiers, but you will be defining which > strings are being used to represent which concepts. FOr example you have > "email" vs "email_address", or any other string combination that a human > would likely interpret as an email like object. Then there is specifying > what can be in the field. > > > > I picked a couple examples out of thin air, with the idea that we=E2=80= =99d > bikeshed them eventually and tie them to a registry. We might want to > re-use a set of identifiers here, and for that I actually like Annabelle > Backman=E2=80=99s proposal to the SECEVENT group better than most that I= =E2=80=99ve seen in > the space: > > > > https://tools.ietf.org/html/draft-ietf-secevent-subject-identifiers > > > > That is one schema. And it has advantages for the subject identifiers, bu= t > obviously does not cover the wide array of other identity attributes. > > > > Why would we not want to reuse existing schemas? And support all of them? > > > > > > > > =E1=90=A7 > --0000000000007a376305a8362d15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It was pointed out to me that the OAuth query parameters a= re registered, and therefore an extension point.

I was s= loppy in my language, so let me clarify:

The query= parameters are a general purpose extension point for adding new features t= hat don't belong somewhere else, but it was not called out as an extens= ion=C2=A0point in the Extensibility section of 6749=C2=A0https://tools.ietf.org/html/rfc6749= #section-8=C2=A0

An extension defining a new g= rant type would use the defined extension point for grants rather than the = general purpose extension point of adding a new query parameter. The specif= ication defines this extension point https://tools.ietf.org/html/rfc6749#section-8.3

Similarly in GNAP, I think we should support multip= le schemas, and we should define how new schemas are added. My proposal is = that the claims object members are schema objects, and the contents of the = schema objects are defined by the schema.





3D""=E1=90=A7

On Mon, Jun 15, 2020 at 6:25 PM Mike Jones <Michael.Jones@microsoft.com> 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 completely agre= e with Dick that, as written, XYZ is defining a new ad-hoc identity schema,= which is unnecessary and counter-productive (and probably violates our cha= rter).

=C2=A0<= /u>

I agree that expl= icitly reusing existing claims schemas, rather than inventing new ones, is = one of the clear and compelling advantages of XAuth over XYZ.=C2=A0 I=E2=80= =99d previously suggested that the Claims section of XYZ be revised to not define new =E2=80=9Cemail=E2=80= =9D and =E2=80=9Csubject=E2=80=9D claims with an unknown schema but that ha= sn=E2=80=99t been done.=C2=A0 Other instances of this problem occur in the = XYZ Transaction Request and Transaction Response sections.

=C2=A0<= /u>

Getting this righ= t matters.

=C2=A0<= /u>

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

=C2=A0<= /u>

From: Dick Hardt <dick.hardt@gmail.com>
Sent: Monday, June 15, 2020 5:39 PM
To: Justin Richer <jricher@mit.edu>
Cc: txauth@ietf= .org; Mike Jones <Michael.Jones@microsoft.com>
Subject: Re: [Txauth] adding identity claim schemas (was: XYZ-08 vs = XAuth-08)

=C2=A0

comments inline ...=C2=A0

=C2=A0

On Wed, Jun 10, 2020 at 8:07 AM Justin Richer <jricher@mit.edu> = wrote:

=C2=A0



On Jun 9, 2020, at 4:14 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

Forking this topic to a new thread

=C2=A0

+Mike as he has expressed concern about creating new= identity claims

=C2=A0

On Tue, Jun 9, 2020 at 9:10 AM Justin Richer <jricher@mit.edu> w= rote:

=C2=A0



On Jun 8, 2020, at 5:33 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

=C2=A0

=C2=A0

=C2=A0

On Mon, Jun 8, 2020 at 1:02 PM Justin Richer <jricher@mit.edu> w= rote:

=C2=A0

<snip>=C2=A0

I don't follow how this would work. Perhaps you = could provide an example in JSON?

=C2=A0

One method is defining a new value inside the XYZ = =E2=80=9Cclaims=E2=80=9D request object that maps to a specific sub-schema:=

=C2=A0

claims: {

=C2=A0 =C2=A0=E2=80=9Csubject=E2=80=9D: true,=

=C2=A0 =C2=A0=E2=80=9Cemail=E2=80=9D: true,

=C2=A0 =C2=A0=E2=80=9Coidc=E2=80=9D: {=

=C2=A0 =C2=A0 =C2=A0 =C2=A0"userinfo":<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"given_name&q= uot;: {"essential": true},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"nickname&quo= t;: null,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"email":= {"essential": true},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"email_verifi= ed": {"essential": true},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"picture"= ;: null,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"http://example.info/cla= ims/groups": null

=C2=A0 =C2=A0 =C2=A0 =C2=A0 },

=C2=A0 =C2=A0 =C2=A0 =C2=A0"id_token":<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"auth_time&qu= ot;: {"essential": true},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"acr": {= "values": ["urn:mace:incommon:iap:silver"] }<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 }

}

=C2=A0

That should look pretty familiar. Alternatively, thi= s could be done with a separate top-level request object field:

=C2=A0

=C2=A0

claims: {

=C2=A0 =C2=A0=E2=80=9Csubject=E2=80=9D: true,=

=C2=A0 =C2=A0=E2=80=9Cemail=E2=80=9D: true=

},

=E2=80=9Coidc_claims_request=E2=80=9D: {

=C2=A0 =C2=A0 =C2=A0 =C2=A0"userinfo":<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"given_name&q= uot;: {"essential": true},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"nickname&quo= t;: null,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"email":= {"essential": true},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"email_verifi= ed": {"essential": true},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"picture"= ;: null,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"http://example.info/cla= ims/groups": null

=C2=A0 =C2=A0 =C2=A0 =C2=A0 },

=C2=A0 =C2=A0 =C2=A0 =C2=A0"id_token":<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"auth_time&qu= ot;: {"essential": true},

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"acr": {= "values": ["urn:mace:incommon:iap:silver"] }<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

}

=C2=A0

In both cases the AS is going to need to knit them t= ogether into a sensible request policy, especially since the OIDC claims qu= ery language has overlapping implications to one particular resource, the U= serInfo endpoint. My contention wasn=E2=80=99t with your proposed solution, my contention was you claiming that XYZ has a= fixed schema and is therefore limited in extensibility.

=C2=A0

One of the objectives of this work is to have extens= ion points. My point was that XAuth had a clear extension point for adding = schemas. How to extend XYZ was not clear in=C2=A0your proposal.

=C2=A0

=C2=A0

I am sorry that the extensibility of the protocol wa= s not clear. It is stated in each section that additional items can be adde= d, and I have stated repeatedly that it=E2=80=99s extensible and demonstrat= ed how, here on this list.=C2=A0



I think the XAuth proposal is better than the two ex= amples you proposed. In your first example, the schema is a second class sc= hema, and in your second example, claims are spread across to top level opt= ions. Both of these pollute other schemas.

=C2=A0

=C2=A0

Not surprisingly, I disagree about the cleanliness o= f XAuth=E2=80=99s proposed approach. The proposal here adds external schema= s as extensions instead of relying on them internally.=C2=A0<= /p>

=C2=A0

If anything, I think that the OpenID Foundation woul= d be the ones to define how to make an OIDC claims request using this proto= col, not us, since they own and control that query syntax and everything it= implies. We can provide a means of extension.

=C2=A0

I also think there=E2=80=99s value in defining a set= of core interoperable identity fields, which themselves could also be exte= nded.=C2=A0

=C2=A0

All of these mechanisms should be controlled by some= combination of registries and collision-resistant namespaces, which is the= approach I=E2=80=99ve taken for extensibility throughout XYZ.

=C2=A0

=C2=A0

JSON by its nature is extensible. Adding new members= to an object is straight forward. XYZ is not unique here. It sounds like y= our idea of extensibility=C2=A0is telling people that they can add new memb= ers to JSON. Of course they can. That is like saying you can add new query parameters to a front channel OAuth 2 re= quest.

=C2=A0

=C2=A0

Yes, exactly. And that=E2=80=99s exactly how OAuth 2= has been extended. I=E2=80=99m glad you see that now.

=C2=A0

I think you are missing my point. Adding query param= eters to OAuth 2 was not a defined extension point. It was inherent in how = query parameters work. OAuth 2 did define the type of grant as an extension= point.=C2=A0

=C2=A0



My concern was that XYZ does not have a clear way to= add new identity claim schemas. You have two examples, add a schema as a m= ember of the claims object, which is mixing claims with schema extensions, = or adding a root member, which is then putting claims into more than one place. It is not clear where to add= a new schema, so we could easily end up with new schemas in both places. T= hat sounds confusing.=C2=A0

=C2=A0

In XAuth, the members of the claims object are the s= chema. Adding a new schema is done one, consistent way.

=C2=A0

I provided a couple examples off the cuff of possibl= e ways to extend something, as your base claim was that XYZ could not be ex= tended with new or external query schemas. Of the two, I think that it make= s more sense for it to be a separate top-level object. Why? Because the OIDC =E2=80=9Cclaims=E2=80=9D request s= yntax not only dictates claims within the OIDC schema, it also specifies ho= w the information comes back. The XYZ claims request talks about informatio= n that comes back in the XYZ claims section of the response.

=C2=A0

I would put the OIDC request to acquire claims from = a user_info endpoint into the authorization request so that there is a cons= istent way to get back an access token, as opposed to a new top level objec= t that could return claims and/or an access token.

=C2=A0

Since the OIDC request allows for targeting specific= ally to the ID token and UserInfo Endpoint, I think it is much cleaner to b= e at the top level as its own thing.=C2=A0

=C2=A0

My point is that XYZ does not define how to a= dd new schemas. An extension can add anything it wants to the JSON, and as = you have shown there is more than one way to do it, and I think long term w= hen there are divergent mechanisms, the code is going to get ugly in detecting what claims are being asked for= .=C2=A0

=C2=A0

=C2=A0



=C2=A0

wrt. "defining a set of core interoperable iden= tity fields", the charter says we should be NOT develop a new schema:

=C2=A0

The grou= p is chartered to develop mechanisms for conveying identity information wit= hin the protocol including identifiers (such as email addresses, phone numbers, usern= ames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, a= nd Verifiable Credentials). The group is not chartered to= develop new formats for identifiers or assertions, nor is the group charte= red to develop schemas for user information, profiles, or other identity at= tributes, unless a viable existing format is not available.

=C2=A0

wrt. OIDC claims, the charter explicitly calls out <= span style=3D"color:black;background:lime"> developing mechanisms for conveying ... OIDC ID Tokens.

=C2=A0

=E1=90=A7

=C2=A0

Precisely: the charter says we will have a way to co= nvey identifiers and assertions. The XYZ =E2=80=9Cclaims=E2=80=9D section l= ists identifiers that can come back, in plain text, and assertions, that ca= n also come back along side them.

=C2=A0

These claims are a schema. We will have an IANA entr= y for what claims are allowed inside of the claims object. This is defining= a new schema.

=C2=A0

It=E2=80=99s not a full query language and isn=E2=80= =99t intended to be, and I think that it would actually be dangerous for th= is to be a full identity schema, but it is itself extensible internally if = someone wants to do that. Claiming that a list of identifiers is =E2=80=9Cdeveloping a new schema=E2=80=9D is an argument se= veral bridges too far from reality.

=C2=A0

You are not inventing new identifiers, but you will = be defining which strings are being used to represent which concepts. FOr e= xample you have "email" vs "email_address", or any othe= r string combination that a human would likely interpret as an email like object.=C2=A0 Then there is specifying what can be in the= field.

=C2=A0

I picked a couple examples out of thin air, with the= idea that we=E2=80=99d bikeshed them eventually and tie them to a registry= . We might want to re-use a set of identifiers here, and for that I actuall= y like Annabelle Backman=E2=80=99s proposal to the SECEVENT group better than most that I=E2=80=99ve seen in the space:

=C2=A0

=C2=A0

That is one schema. And it has advantages for the su= bject identifiers, but obviously does not cover the wide array of other ide= ntity attributes.

=C2=A0

Why would we not want to reuse existing schemas? And= support all of them?

=C2=A0

=C2=A0

=C2=A0

=E1=90=A7

--0000000000007a376305a8362d15-- From nobody Tue Jun 16 10:04:51 2020 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 7DC453A0484 for ; Tue, 16 Jun 2020 10:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 PtaHKvPrD4nR for ; Tue, 16 Jun 2020 10:04:48 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 4F2843A0538 for ; Tue, 16 Jun 2020 10:04:25 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id o4so4566130lfi.7 for ; Tue, 16 Jun 2020 10:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=2CsAkKK2lyuRDQx0qZ74OYTvhuSs/nvg87F2Afb4RSM=; b=knzSux7xwSwVXEz6VdQ6IGmwTEOwZ+PuKaQnCwcx+RORwtTWB+eZ7Q84/25Z9h7gLn iSbMZDaNQjs1tfwDpahXajgIzBAa6tRyp5IyqL9fKzGa02mHDK4r1AIVNNMsJ5l6Lzfn rTQo7yRhgMAUSamdLJQbCaeiVlZa5ysUgCgXkdJCua8XqgUToAVxxXsVizkEE9mqNnj3 e2ZREgWsqXdcyXw1zi8+XxpLOUmOaZsBEEQV94ufzOyWGA4A009eHEP5DDy5OL6Ot3Wu yIRggsKqnITKxzD6O0t4ZWFCC4C/VckfjkIgte/hGZVpFU1HGNFbDugBlmSSrsvpAXQy +xDw== 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:cc; bh=2CsAkKK2lyuRDQx0qZ74OYTvhuSs/nvg87F2Afb4RSM=; b=o7dJp6RAvfQzdeVySgQ7zsAnIxbusT7BAgnlQpxEjS42YUh6KWTrmoexPNJ83Ik5ps UUvr6plx+dJaY4wvMAp19eR6lQz3t81q+WKFG1hO2b1fUwysZyajcOkB4t+zdXaXXp7P /nDiEb+NwrS32MwuHLdkLZPRnZBuFAP9zy5ftdsEM2YQimRPZCWaOvYXa2d52u/kVja8 PBtWwgq5dUEn+Elr1eJJ0/aIU+VFO9fD8o1xcNK8YL3bq5zOrOLzfCpbecoWHIsdrpjJ xtSFAIsj5MZIHuDLUPEDa33QaxjPQ+3VF4sl6S3l39I8DwabiIB8vvxO6xmepMMz66zt hFBQ== X-Gm-Message-State: AOAM530AsSUsCEg14THBnKDymueK3bPa/6yTTU6bi6vdSUssN0tvgi8A wFFVym9XmS5wYBcnCT1wEaDWXnfVm1QKz+58teiVs4jF X-Google-Smtp-Source: ABdhPJyumV6gWo3ndt0EzIH2mVeEjy/4ynhqri7a9RpsDaxYMWL438MDQ4nu79Ilp8SB0NRpKLUSIR4MkC9/vzK8sFM= X-Received: by 2002:a19:64c:: with SMTP id 73mr2298947lfg.0.1592327063141; Tue, 16 Jun 2020 10:04:23 -0700 (PDT) MIME-Version: 1.0 From: Dick Hardt Date: Tue, 16 Jun 2020 10:03:57 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org, Daniel Fett Content-Type: multipart/alternative; boundary="000000000000f7055905a8368835" Archived-At: Subject: [Txauth] Interaction capabilities vs modes (was: XYZ-08 vs XAuth-08) 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, 16 Jun 2020 17:04:51 -0000 --000000000000f7055905a8368835 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Forking this thread to a new subject ... + Daniel for the security concern on preventing a session fixation attack. On Mon, Jun 15, 2020 at 5:19 PM Dick Hardt wrote: > > On Wed, Jun 10, 2020 at 7:54 AM Justin Richer wrote: > >> On Jun 9, 2020, at 4:11 PM, Dick Hardt wrote: >> >> >> On Tue, Jun 9, 2020 at 9:10 AM Justin Richer wrote: >> >>> >>> >>> On Jun 8, 2020, at 5:33 PM, Dick Hardt wrote: >>> >>> > In XAuth, if the server wants to protect itself from a session fixation >>> attack in a given request, and it wants to support both "redirect" and >>> "user_code" modes, >>> the server will return only those two modes and not "indirect". The >>> >>> In XAuth, if the server wants to protect itself from a session fixation >>> attack in a given request, and it wants to support both "redirect" and >>> "user_code" modes, >>> the server MUST return callback, redirect, and user_code. The client >>> does not know that the "indirect" mode is not supported, and may try th= at. >>> >>> >>> In XYZ, if the server wants to protect against a session fixation >>> attack, it will reject a request that doesn=E2=80=99t have a =E2=80=9Cc= allback=E2=80=9D field in >>> it. The AS always gets to choose which things it supports for any given >>> request. If the client wants to support both =E2=80=9Credirect=E2=80=9D= and =E2=80=9Cuser_code=E2=80=99 >>> modes AND has the ability to handle session fixation issues, it sends t= he >>> =E2=80=9Credirect=E2=80=9D, =E2=80=9Cuser_code=E2=80=99, and =E2=80=9Cc= allback=E2=80=9D fields in its interaction request. >>> >> >> If the client chooses to present the interaction_url as a scannable >> barcode, which is an option if it receives one, it will then get an erro= r >> when it tries to do a transaction continue request as the AS protects >> itself. Unfortunately the user has scanned the barcode and is now at the >> AS. I don't see how the client learns it is not able to do what I call a= n >> "indirect" mode interaction. Would you explain how this situation is >> prevented in XYZ? >> >> >> If the client has made a request with =E2=80=9Credirect=E2=80=9D and =E2= =80=9Ccallback=E2=80=9D in its >> request, and then decides to display the interaction URL as a scannable >> code, then the AS will just redirect to the client=E2=80=99s callback UR= L when it=E2=80=99s >> done, whatever that URL was. If the client sends a =E2=80=9Ccallback=E2= =80=9D URL that it >> can=E2=80=99t get information from, then that=E2=80=99s a poorly-written= client, isn=E2=80=99t it? >> > > Let me provide more clarity on the scenario. > > The client is a web app that can redirect the user to the AS, and receive > a callback, it can display a code and URI to enter the code, or it can sh= ow > a scannable code for the user to scan on their mobile phone. The user may > be using the web app on a PC, and the AS is on their phone. The user > chooses to scan the barcode with their phone. After authenticating with t= he > AS, the AS redirects back to the callback URL. But the webpage is now on > the user's mobile device, not the web app on the PC. > > >> >> If the client can=E2=80=99t get to the information in the callback URL u= nless >> it=E2=80=99s on the same device, then the client isn=E2=80=99t going to = show the user a >> scannable code to be read by a secondary device. Why would it? >> > > Because it is a better experience for the user per above. > > The AS parameters don't differentiate between a scannable URL and a URL > that can only be redirected, so the client will think it can do anything. > > Additionally, in XAuth, the client can provide an informational URI for > the AS to redirect after a scannable code or a user code flow. > > I'll add additional clarity on what happens when the user experience switches between the PC browser and the mobile browser. The client loses context of which user the client is interacting with. An attacker can take the interaction URL and trick a victim user into clicking on it (a session fixation attack). The client does not know the difference between a real user on the mobile device, and a victim on a mobile device. Neither scenario has any session state from the original user interaction at the client. Providing a clear signal to the client that the AS won't support a scannable code (or any other redirection to the AS that does not have a redirection back to the same instance of the client). /Dick --000000000000f7055905a8368835 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forking this thread to a new subject ...<= br>

+ Daniel for the security concern = on preventing a session fixation attack.

On Mon, Jun 15, 2020 at 5:19 PM= Dick Hardt <d= ick.hardt@gmail.com> wrote:

On Wed, Jun 10, 2020= at 7:54 AM Justin Richer <jricher@mit.edu> wrote:
On Jun 9, 2020, at 4:11 P= M, Dick Hardt <dick.hardt@gmail.com> wrote:


On Tue, Jun 9, 2020 at 9:10 AM Justin Richer <jricher@mit.edu> wrote:


On Jun 8, 2020, at 5:33 PM, Dick Hardt <dick.hardt@gmail.com> w= rote:
<snip>=C2=A0
In XAuth, if the server wants to protect itself from a session fixa= tion attack in a given request, and it wants to support both "redirect= " and "user_code" modes,=C2=A0
the server will ret= urn only those two modes and not "indirect". The=C2=A0
=
In XAuth, if the server wants to protect itself from a = session fixation attack in a given request, and it wants to support both &q= uot;redirect" and "user_code" modes,=C2=A0
<= /div>
the server MUST return=C2=A0callback, redirect, and user_code. Th= e client does not know that the "indirect" mode is not supported,= and may try that.

=
In XYZ, if the server wants to protect against a session fix= ation attack, it will reject a request that doesn=E2=80=99t have a =E2=80= =9Ccallback=E2=80=9D field in it. The AS always gets to choose which things= it supports for any given request. If the client wants to support both =E2= =80=9Credirect=E2=80=9D and =E2=80=9Cuser_code=E2=80=99 modes AND has the a= bility to handle session fixation issues, it sends the =E2=80=9Credirect=E2= =80=9D, =E2=80=9Cuser_code=E2=80=99, and =E2=80=9Ccallback=E2=80=9D fields = in its interaction request.=C2=A0

If the client chooses to present the interaction_url as a scannabl= e barcode, which is an option if it receives=C2=A0one, it will then get an = error when it tries to do a transaction continue request as the AS protects= itself. Unfortunately the user has scanned the barcode and is now at the A= S. I don't see how the client learns it is not able to do what I call a= n "indirect" mode interaction. Would you explain how this situati= on is prevented in XYZ?

=
If the client has made a request with =E2=80=9Credirect=E2=80=9D and = =E2=80=9Ccallback=E2=80=9D in its request, and then decides to display the = interaction URL as a scannable code, then the AS will just redirect to the = client=E2=80=99s callback URL when it=E2=80=99s done, whatever that URL was= . If the client sends a =E2=80=9Ccallback=E2=80=9D URL that it can=E2=80=99= t get information from, then that=E2=80=99s a poorly-written client, isn=E2= =80=99t it?

Let me provid= e more clarity on the scenario.

The client is a we= b app that can redirect the user to the AS, and receive a callback, it can = display a code and URI to enter the code, or it can show a scannable code f= or the user to scan on their mobile phone. The user may be using the web ap= p on a PC, and the AS is on their phone. The user chooses to scan the barco= de=C2=A0with their phone. After authenticating with the AS, the AS redirect= s back to the callback URL. But the webpage is now on the user's mobile= device, not the web app on the PC.
=C2=A0

If the clien= t can=E2=80=99t get to the information in the callback URL unless it=E2=80= =99s on the same device, then the client isn=E2=80=99t going to show the us= er a scannable code to be read by a secondary device. Why would it?

Because it is a better experienc= e for the user per above.=C2=A0

The AS parameters = don't differentiate between a scannable URL and a URL that can only be = redirected, so the client will think it can do anything.=C2=A0
Additionally, in XAuth, the client can provide an informationa= l URI for the AS to redirect after a scannable code or a user code flow.=C2= =A0


I'= ll add additional clarity on what happens when the user experience switches= between the PC browser and the mobile browser. The client loses context of= which user the client is interacting with. An attacker can take the intera= ction URL and trick a victim user into clicking on it (a session fixation a= ttack). The client does not know the difference between a real user on the = mobile device, and a victim on a mobile device. Neither scenario has any se= ssion state from the original user interaction at the client.=C2=A0

Providing a clear signal to the client that the AS won= 9;t support a scannable code (or any other redirection to the AS that does = not have a redirection back to the same instance of the client).
=
/Dick


--000000000000f7055905a8368835-- From nobody Tue Jun 16 10:09:20 2020 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 271243A0770 for ; Tue, 16 Jun 2020 10:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 vzRgq8sf_nMM for ; Tue, 16 Jun 2020 10:09:13 -0700 (PDT) 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 E6AB13A0765 for ; Tue, 16 Jun 2020 10:09:12 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id n23so24438239ljh.7 for ; Tue, 16 Jun 2020 10:09:12 -0700 (PDT) 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=ZrDctQg3IYt+vSB2pim69Ctz9xJWvkEJyakhPgnKvl8=; b=U1ER8bDcpqcdWlz9kMtQck1g8SRiRUZTpQP65QhKq+brg498KUT1A4kG1pmpdSp4TT pyC6v/0Z3Te0qjeXAn204cJJX9GDXFkh/4zeHQ9pRFRVFIs+la9wfE3kj+4Hhe9kMZUa 6rcDm8PlLDSkSeHZVoK+Oop7/kiNU40S8uK1HFk8dBqDlkt/f4HU03GFwwgR7wXa3Wfz WqhNR8F3CM+wETdfY06300/kuxUiLnQ9e50ljX2Cw9rbEJDQCukUrhRbGQ1UsdaMg56H UruNeEebSlv8otP03ao/rGrwjdEcZHul6F1y2E4XTCeh8TvNDIzm1ARvZhque9d/CpJi 7xPA== 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=ZrDctQg3IYt+vSB2pim69Ctz9xJWvkEJyakhPgnKvl8=; b=FvHrT4wxMqXPgUyo+pLr92JUGmuzu/YxCcwPR/63W8sruvfR205DEOP4XUWpmf5jYK 1W3o06S5taZV38CUVCwut7m4KaPzVa4HtS5jELuaFOEtMM3shc/oJXWr0VBDsmUW6RJU yOlTenshLpVVBHCjH2PcagNuSiKcKWUAoSh8iryhPAs8Qr09hizYaPbcH2vHQGPDjll3 lXImDwaK/q8CEqWj0jmflVBl9fbcXTwsbv6M3yJiN/JkXNcc/GyVCwsZdcTocpcYGiw1 ZoklTJLNxJZUJtKsDkQdMmihJdBJwOAmE9VlYHeTP1mgvAW9+HDcl9rGHmDZ35G4E/+A qGeQ== X-Gm-Message-State: AOAM5320STByk765PZBpMEM71m3j9V7aGu9Y+cPIttPoSgg/NgSOAnqC qciep/3iB3AER8v49qPvX21REqMsxUMlYyegb2Y= X-Google-Smtp-Source: ABdhPJxS/vaebEQQcUQgnLvWl6lpYqZ/JcZas9SsjuU3YbVLxVnDKCkAQx6UlpwlLlBz9GVjTtCMdvKSX9eKQaE/qTg= X-Received: by 2002:a2e:8e78:: with SMTP id t24mr1876777ljk.314.1592327350789; Tue, 16 Jun 2020 10:09:10 -0700 (PDT) MIME-Version: 1.0 References: <5443710B-05DB-4C4D-AC4B-0D8D173E131B@mit.edu> <1B439ED3-E7DF-49B2-A064-4CB5CC3147A0@mit.edu> In-Reply-To: <1B439ED3-E7DF-49B2-A064-4CB5CC3147A0@mit.edu> From: Dick Hardt Date: Tue, 16 Jun 2020 10:08:44 -0700 Message-ID: To: Justin Richer Cc: Mike Jones , "vittorio.bertocci@auth0.com" , Peter Saint-Andre , Fabien Imbault , Jared Jennings , Amanjeev Sethi , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001c339905a8369a5c" Archived-At: Subject: Re: [Txauth] GNAP it is 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, 16 Jun 2020 17:09:18 -0000 --0000000000001c339905a8369a5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems strange that you now call addressing the concerns you raised "silly". While there is no confusion in written communication with GNAP, there clearly will be in verbal communication. Starting off with a suggested pronunciation looks to me to nip a significant amount of the confusion in the bud. We can deal with it now, or deal with it later, or it can be a source of confusion and communication friction forever. Why not just pick one pronunciation and move on? On Tue, Jun 16, 2020 at 7:42 AM Justin Richer wrote: > I don=E2=80=99t believe we should add a proposed pronunciation to the cha= rter. It > seems silly to focus on this so much. > > =E2=80=94 Justin > > On Jun 15, 2020, at 6:14 PM, Dick Hardt wrote: > > I agree we should be prepared for both. Can we agree that we can be > consistent? Personally I don't care which we choose -- I only care that w= e > choose one. > > I was working to address the concern that you (Justin) had brought up: > > This is ok, but it has a couple downsides. The pronunciation of a hard > =E2=80=9Cg=E2=80=9D or not is going to potentially be confusing, as is th= e fact that it > looks like it=E2=80=99s part of the GNU project because of that. > > > > On Mon, Jun 15, 2020 at 1:56 PM Justin Richer wrote: > >> I agree with Mike, in that we should get used to answering to both. >> >> In my head, it reads with a hard =E2=80=9CG=E2=80=9D, at least partially= because of the >> Smurfs video=E2=80=99s legacy. >> >> =E2=80=94 Justin >> >> On Jun 15, 2020, at 3:38 PM, Mike Jones < >> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >> >> I don=E2=80=99t care a lot one way or the other. My main point is that = no matter >> what guidance we give, many people are likely to pronounce the =E2=80=9C= G=E2=80=9D. If we >> try to insist on it being silent, we should get used to the fact that we= =E2=80=99ll >> probably be hearing both pronunciations. >> >> -- Mike >> >> P.S. Thanks for the Smurfs link, Vittorio! >> >> *From:* vittorio.bertocci@auth0.com >> *Sent:* Monday, June 15, 2020 12:25 PM >> *To:* 'Dick Hardt' ; 'Peter Saint-Andre' < >> stpeter@mozilla.com> >> *Cc:* Mike Jones ; 'Jared Jennings' < >> jaredljennings@gmail.com>; 'Amanjeev Sethi' ; 'Fabien >> Imbault' ; txauth@ietf.org >> *Subject:* RE: [Txauth] GNAP it is >> >> Perhaps not to be taken too seriously, but here=E2=80=99s prior art on G= NAP >> pronunciation. >> As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the = Smurfs comic and >> was reprised in a cartoon episode as well. >> You=E2=80=99ll find few examples around 3:30 >> >> https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbclid= =3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ >> >> *From:* Txauth *On Behalf Of *Dick Hardt >> *Sent:* Monday, June 15, 2020 12:18 PM >> *To:* Peter Saint-Andre >> *Cc:* Mike Jones ; Jared Jennings < >> jaredljennings@gmail.com>; Amanjeev Sethi ; Fabien >> Imbault ; txauth@ietf.org >> *Subject:* Re: [Txauth] GNAP it is >> >> Checking in again on pronunciation. >> >> Mike: do you still have concerns with a silent 'G'? >> >> Anyone else have concerns? >> >> I'd like to nip pronunciation confusion in the bud by having the >> recommended pronunciation in the charter. >> >> >> =E1=90=A7 >> >> On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre >> wrote: >> >> Looks like we were caught gnapping. ;-) >> >> OK, that's the last of my snarky comments, let's get to work! >> >> Peter >> >> On 6/7/20 2:09 PM, Dick Hardt wrote: >> > It is if you are familiar with any of the GNU projects. >> > >> > https://www.gnu.org/gnu/pronunciation.en.html >> > >> > A quick search on the internet has the "normal" pronunciation of "gnu" >> > to have a silent 'g'. >> > >> > https://www.howtopronounce.com/gnu >> > https://dictionary.cambridge.org/us/pronunciation/english/gnu >> > >> > >> > =E1=90=A7 >> > >> > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones > > > wrote: >> > >> > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of G= NU. I >> > think that=E2=80=99s the most natural way to read it.____ >> > >> > __ __ >> > >> > -- Mike____ >> > >> > __ __ >> > >> > *From:* Txauth > > > *On Behalf Of *Dick Hardt >> > *Sent:* Sunday, June 7, 2020 12:45 PM >> > *To:* Amanjeev Sethi > >> > *Cc:* Fabien Imbault > > >; Jared Jennings >> > >; >> > txauth@ietf.org >> > *Subject:* Re: [Txauth] GNAP it is____ >> > >> > __ __ >> > >> > Anyone have objection to the recommended pronunciation being the >> > English word "nap", as in "gnaw"?____ >> > >> > __ __ >> > >> > If not, then we could add a pronunciation recommendation to the >> > Charter.____ >> > >> > __ __ >> > >> > =E1=90=A7____ >> > >> > __ __ >> > >> > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi > > > wrote:____ >> > >> > Vote for 'G' silent, as in 'lagnappe' ;)____ >> > >> > __ __ >> > >> > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____ >> > >> > I vote for G silent. For the reason it's most common to >> > pronounce, especially for those not familiar with open >> > source usages.____ >> > >> > __ __ >> > >> > On Sat, Jun 6, 2020, 08:45 Dick Hardt > > > wrote:____ >> > >> > The obvious pronunciation choices are:____ >> > >> > __ __ >> > >> > nap (silent g as in gnaw)____ >> > >> > __ __ >> > >> > guh-nap (as in the GNU OS >> > - https://www.gnu.org/gnu/pronunciation.en..html >> > )____ >> > >> > __ __ >> > >> > gee-nap (as in G-man - government man >> > - https://en.wikipedia.org/wiki/G-man)____ >> > >> > __ __ >> > >> > __ __ >> > >> > __ __ >> > >> > =E1=90=A7____ >> > >> > __ __ >> > >> > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault >> > > > > wrote:____ >> > >> > So, let's adopt a GNAP! We can even come with a >> > little mascot (a bit like go gopher) as imagined >> > by http://elisegravel.com/blog/adopte-un-gnap/, >> > loved by little Canadians :-) ____ >> > >> > __ __ >> > >> > Just to be sure, how do you recommand we pronounce >> > it? ____ >> > >> > __ __ >> > >> > Looking forward to the next steps too.. ____ >> > >> > __ __ >> > >> > Thxs____ >> > >> > Fabien____ >> > >> > --____ >> > >> > 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____ >> > >> > __ __ >> > >> > __ __ >> > >> > >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth >> >> >> > --0000000000001c339905a8369a5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems strange that you now call addres= sing the concerns yo= u raised "silly".=C2=A0

While there is n= o confusion in written communication with GNAP, there clearly will be in ve= rbal communication.=C2=A0

Starting off with a sugg= ested pronunciation looks to me to nip a significant amount of the confusio= n in the bud.

We can deal with it now, or deal wit= h it later, or it can be a source of confusion and communication friction f= orever.

Why not just pick one pronunciation and mo= ve on?

On Tue, Jun 16, 2020 at 7:42 AM Justin Richer <jricher@mit.edu> wrote:
= I don=E2=80=99t believe we should add a proposed pronunciation to the chart= er. It seems silly to focus on this so much.

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

On Jun 15, 2020, a= t 6:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I agree we should be prepared for both. Can we agree that= we can be consistent? Personally I don't care which we choose -- I onl= y care that we choose one.

I was working=C2=A0to address the concern that you (Justin) had brought up= :

This is ok, but it = has a couple downsides. The= pronunciation of a hard =E2=80=9Cg=E2=80=9D or not is going to potentially= be confusing, as is the fact that it looks like it=E2=80=99s part of the G= NU project because of that.



On Mon, Jun 15, 2020 at 1:56 PM Justin Richer <jricher@mit.edu> wro= te:
I agree= with Mike, in that we should get used to answering to both.

=
In my head, it reads with a hard =E2=80=9CG=E2=80=9D, at least partial= ly because of the Smurfs video=E2=80=99s legacy.

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

On Jun 15= , 2020, at 3:38 PM, Mike Jones <Michael.Jones=3D40microsoft.com= @dmarc.ietf.org> wrote:

I don=E2=80=99t care a lot one way or t= he other.=C2=A0 My main point is that no matter what guidance we give, many= people are likely to pronounce the =E2=80=9CG=E2=80=9D.=C2=A0 If we try to= insist on it being silent, we should get used to the fact that we=E2=80=99= ll probably be hearing both pronunciations.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mi= ke
<= u>=C2=A0
P.S.=C2=A0 Thanks for the Smurfs link, Vittorio!
=C2=A0<= /div>
From:=C2=A0vittorio.bertocci@= auth0.com=C2=A0<vi= ttorio.bertocci@auth0.com>=C2=A0
Sent:= =C2=A0Monday, June 15, 2020 12:25 PM
To:=C2=A0'Dick Hardt' <dick.hardt@gmail.co= m>; 'Peter Saint-Andre' <stp= eter@mozilla.com>
Cc:=C2=A0Mike Jones <Michael.Jones@microsoft.com>; '= ;Jared Jennings' <jaredljennings@= gmail.com>; 'Amanjeev Sethi' <aj= @amanjeev.com>; 'Fabien Imbault' <fabien.imbault@gmail.com>;=C2=A0txauth@ietf.org
Subject:=C2=A0RE: = [Txauth] GNAP it is
=C2=A0<= u>
Perhaps not to be taken too seriously, but here=E2=80= =99s prior art on GNAP pronunciation.
As Leif = mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the Smurfs comi= c and was reprised in a cartoon episode as well.
You=E2=80=99ll find few examples around 3:30
https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&am= p;fbclid=3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ
=C2=A0
From:=C2=A0Txauth &= lt;txauth-bounces@ietf.org>= =C2=A0On Behalf Of=C2=A0Dick Hardt
Sent:=C2=A0Monday, June 15, 2020 12:18 PM
To:=C2= =A0Peter Saint-Andre <stpeter@mozill= a.com>
Cc:=C2=A0Mike Jones <Michael.Jones@microsoft.com>; Jared Jennings = <jaredljennings@gmail.com>; Ama= njeev Sethi <aj@amanjeev.com>; Fabien Im= bault <fabien.imbault@gmail.com>= ;;=C2=A0txauth@ietf.org
Sub= ject:=C2=A0Re: [Txauth] GNAP it is
=C2=A0
Checking in again on p= ronunciation.
=C2=A0
<= /div>
Mike: do you still have concerns with a silent 'G&#= 39;?
=C2=A0
Anyone else have concerns?
<= div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san= s-serif">=C2=A0
I'd like to nip= pronunciation confusion in the bud by having the recommended pronunciation= =C2=A0in the charter.
=C2=A0=
=C2=A0
=E1=90=A7
=C2=A0
On Sun, Jun 7, 2020 at 1:= 23 PM Peter Saint-Andre <stpeter@mozilla.co= m> wrote:
Looks like = we were caught gnapping. ;-)

OK, that's the last of my snarky co= mments, let's get to work!

Peter

On 6/7/20 2:09 PM, Dick = Hardt wrote:
> It is if you are familiar with any of the GNU projects= .
>=C2=A0
>=C2=A0https://www.gnu.org/gnu/pronunciation.en.html
>=C2=A0
> A quick search on the internet has th= e "normal" pronunciation of "gnu"
> to have a sil= ent 'g'.
>=C2=A0
>=C2=A0https://www.howtopronounce.com/gnu
&= gt;=C2=A0https://dictionary.cambridge.org/us/pronunciation/english/gnu
>=C2=A0
>=C2=A0
>=C2= =A0=E1=90=A7>=C2=A0
> On Sun, Jun 7, 2020 at 12:51 PM Mike Jones= <Michael.Jones@microsoft.com> <mailto:Michael.Jones@micros= oft.com>> wrote:
>=C2=A0
>=C2=A0 =C2=A0 = =C2=A0I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of GNU.= =C2=A0 I
>=C2=A0 =C2=A0 =C2=A0think that=E2=80=99s the most natural w= ay to read it.____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0__= =C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 -- Mike____
>=C2=A0
>=C2=A0 =C2=A0 = =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0*Fro= m:* Txauth <txauth-bounces@ietf.org=
>=C2=A0 =C2=A0 =C2=A0<mailto:txa= uth-bounces@ietf.org>> *On Behalf Of *Dick Hardt
>=C2=A0 = =C2=A0 =C2=A0*Sent:* Sunday, June 7, 2020 12:45 PM
>=C2=A0 =C2=A0 =C2= =A0*To:* Amanjeev Sethi <aj@amanjeev.com=C2=A0<mailto:aj@amanjeev.com>= >
>=C2=A0 =C2=A0 =C2=A0*Cc:* Fabien Imbault <fabien.imbault@gmail.com
>=C2=A0 =C2=A0 =C2=A0<= ;mailto:fabien.imbault@gmail.com>&= gt;; Jared Jennings
>=C2=A0 =C2=A0 =C2=A0<jaredljennings@gmail.com=C2=A0<mailto:jaredljennings@gmail.com>>;
>= =C2=A0 =C2=A0 =C2=A0txauth@ietf.org=C2= =A0<mailto:txauth@ietf.org>
&g= t;=C2=A0 =C2=A0 =C2=A0*Subject:* Re: [Txauth] GNAP it is____
>= =C2=A0
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0Anyone have objection to the recommended pro= nunciation=C2=A0being the
>=C2=A0 =C2=A0 =C2=A0English word "nap= ", as in "gnaw"?____
>=C2=A0
>=C2= =A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0= =C2=A0If not, then we could add a pronunciation=C2=A0recommendation to the=
>=C2=A0 =C2=A0 =C2=A0Charter.____
>=C2=A0
>= =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2= =A0 =C2=A0=E1=90=A7___= _
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
><= span>=C2=A0
>=C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020 at 8:03 A= M Amanjeev Sethi <aj@amanjeev.com
>= =C2=A0 =C2=A0 =C2=A0<mailto:aj@amanjeev.com= >> wrote:____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Vote for 'G' silent, as in 'lagnappe' ;)____>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0= __
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On S= at, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____
>=C2=A0=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I vote for G= silent. For the reason it's most common to
>=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0pronounce, especially for those not familiar wi= th open
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0source usage= s.____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020, 08:45 Dick Hardt <= ;dick.hardt@gmail.com
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dick.hardt@gmail.com>> wrote:____
>=C2=A0<= br>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The ob= vious pronunciation choices are:____
>=C2=A0
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
&g= t;=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0nap (silent g as in gnaw)____
>=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2= =A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0guh-nap (as in the GNU OS
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0https://www.gnu.org/gnu/pronunciation.en..html=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&= lt;https://www.gnu.org/gnu/= pronunciation.en.html>)____
>=C2=A0
>=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
><= span>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0gee-nap (as in G-man - government man
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0https://en.wikipedia.org/wiki/G-man)____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E1=90=A7____
>=C2=A0
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2= =A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<fabien.imbault@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:fabien.imbault@gmail.com>> wrote:____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0So, let's adopt a GNAP! We can even come with a
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0li= ttle mascot (a bit like go gopher) as imagined
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by=C2=A0http://elisegravel.com/blog/adopte-un-gna= p/,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0loved by little Canadians :-)=C2=A0____
>=C2= =A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Just to b= e sure, how do you recommand we pronounce
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it?=C2=A0____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lo= oking forward to the next steps too..=C2=A0____
>=C2=A0<= br>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thxs____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Fabien____
>=C2=A0
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--= ____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth@ietf.org=C2=A0<mailto:Txauth@ietf.org>_= ___
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/txauth____
&g= t;=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0--____
>=C2=A0
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list____
>= ;=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Txauth@ietf.org=C2=A0<mailto:Txauth@ietf.org>____
>= ;=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0https:/= /www.ietf.org/mailman/listinfo/txauth____
>=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--=C2=A0____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tx= auth mailing list____
>=C2=A0
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth@ietf.org= =C2=A0<mailto:Txauth@ietf.org&= gt;____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0https:/= /www.ietf.org/mailman/listinfo/txauth____
>=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>= =C2=A0
>=C2=A0
--=C2= =A0
Txauth mailing list
Txauth@ie= tf.org
https://www.i= etf.org/mailman/listinfo/txauth


--0000000000001c339905a8369a5c-- From nobody Tue Jun 16 10:23:20 2020 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 171193A0794 for ; Tue, 16 Jun 2020 10:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 jKUz7Mefkx35 for ; Tue, 16 Jun 2020 10:23:17 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9AB3A0793 for ; Tue, 16 Jun 2020 10:23:16 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id s1so24557790ljo.0 for ; Tue, 16 Jun 2020 10:23:16 -0700 (PDT) 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=mxyuo1M7ihSM1Z5MnPRUwWYDJEP8fHtTge04CDnNuCE=; b=JdMmpftOMdzAa/JtbNZdCHtWvL+oqbgGHk5gv7wba7nWBkkcmkIaqW0N8YRirT5iaJ yysHLMEL8ACPGE0qtVHLUiUkzCKoDSCfFd8A95Fpo9VEA8QpvG6EGomch00RlWPlzLH8 uM7QTsnEMjLPpANlY924Cg3Bk9tkkUn3aJj4AUIVqzCQmb1cJaiAauBqgyJ7gnOktS6W ecDiGIkZkqBERFgYV23njgSuAWVgWG6zdzQxOr5tVpRpyPkk0pIl0Zmc1pP7F1C/P+M3 89WrdCdgoJS1ML1yhPKWGF2pSH9O1RWH1IpoaOPjSaTQmWgrKgifxVQ8UCpEHmTz7JZd MHMg== 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=mxyuo1M7ihSM1Z5MnPRUwWYDJEP8fHtTge04CDnNuCE=; b=srNGrAqZhBBnMMMc0X6do+2M3u+ooE8mmH3JrepTtDTwEz1z+5xyrx/cHXax6a1j6B x4/ppUMr/nb+lOW//66nZ//qMKw4XdGanihqbLKuxLkpBYm9zfPmh32vjGJY92UIOHiw NWAHBcquqXhZazFp/bo2y9QPYP27h6GMxPxL8FkzUggs6M/gO/2ZSmED6BMGZex7UcZA cxqOSi0xgX2Ow1OBszml16Ep5AAiJsp/emJyIilK7OxMYSBPLQvePHwj0Tr1u3cOOCEM fs8bphUmg9cwbcRNivPyBWWkczVsq3TvulUrAf7rve1+ESSrEBpp0MZH+jX4zqEcV6gF bsZQ== X-Gm-Message-State: AOAM533uPhxXnaWAkQIahhecHdDfag1CcchsE3YWtrURGEnfNnnm2gRT reNkx6sYupJqQd5wdWHGQLnfAHuIH8dFLZXgHlI= X-Google-Smtp-Source: ABdhPJzjYeCiHUVlOWOwrvcphIAj5Hlzk02dJNzWlNKBRvMDvoU43XWaIAMBtqtJOv6Ydlvwe0DzJMZjTfyNV5K7AwE= X-Received: by 2002:a2e:8e78:: with SMTP id t24mr1902700ljk.314.1592328194779; Tue, 16 Jun 2020 10:23:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dick Hardt Date: Tue, 16 Jun 2020 10:22:49 -0700 Message-ID: To: Fabien Imbault Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000006a70d605a836ccbb" Archived-At: Subject: Re: [Txauth] Additional implementation 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, 16 Jun 2020 17:23:19 -0000 --0000000000006a70d605a836ccbb Content-Type: text/plain; charset="UTF-8" Hi Fabien Thanks for diving in and doing an implementation, and providing your observations! ... comments inline ... On Wed, Jun 10, 2020 at 1:56 AM Fabien Imbault wrote: > Hi, > > Just to let you know that we started our own implementation of XYZ / XAuth > (and future GNAP). > It's just a first attempt of getting the concepts put into use quickly. We > wanted to have a clear separation between the client and the AS, and > demonstrate the retrieval of a protected resource to make it simpler for > people to understand (even if there's nothing new there). > > Here's a quick MVP of xyz. Currently it's just implementing a basic flow, > redirect with callback interaction. > https://github.com/acertio/mvp_xyz > (also working on the same for XAuth, because I sometimes get a bit lost in > discussions between Justin and Dick, really need to get down to the drafts > and write concrete examples to get a sense of what it means). > This is very basic/naive but really gave us some better ideas on what to > test/implement next, and contribute to the discussion. > I'm keen to see an XAuth implementation. Please let me know if there is anything underspecified that is holding you back. > > Note also that our target implementation will be in rust, and we are > currently testing the approach on how to best implement it using a system > oriented language (the fact that nodejs is very web oriented is abstracting > some important aspects in our view). > Our work is available under an MPLv2 licence, and we'll be happy to keep > working on a separate and open reference implementation. > > As a last comment, I'd like to say that both XYZ and XAuth are great work, > but it seems we're having 2 competing views, difficult to reconcile. I > believe we can do better. > > Following our experiments, I would say: > a) XYZ really makes a new experience possible, and the flow really fixes > common issues in OAuth2. I believe this design idea is of great value, but > the downside is that the written spec doesn't explicitly cover every aspect > yet, so sometimes you have to guess or dig into Justin's implementation. > But making sure we clarify that is also what the working group is there > for, isn't it? > Justin has even put his money where his mouth is by providing > implementations and integrating with legacy software (an old implementation > by mitre), so it's a very good sign that we won't end up with unnecessary > breaking changes. > In which areas did you need to dig into Justin's implementation? "XYZ really makes a new experience possible" -- do you think the new experience was not possible in XAuth? > > b) XAuth's spec is written in a more consistent way, which reflects the > fact that is closer to the previous art. There is no reference > implementation (as far as I'm aware) and it comes with the potential > downside of having a more opinionated/prescriptive stance and being much > closer to legacy (for good or worse). > In contrast to OAuth 2, which was a framework, our charter is to deliver a protocol. IMHO being opinionated and prescriptive simplifies interoperability or a protocol. > > However, I don't think the game of spotting the differences is that > meaningful, and the charter should provide sufficient common ground to > proceed forward despite or thanks to those differences. Otherwise we'll end > up in surprisingly narrow considerations, such as I prefer X because it's > reusing existing schemas. This is something we need to handle when time > comes, but that's really an implementation detail and obviously nobody > thinks we shouldn't reuse things that do work. > The intention is not a game of spot the difference, but to discuss different proposals for providing functionality. wrt. the schema discussion, one aspect is reusing an existing schema, which is not an implementation detail, but must be specified. The more significant point I was trying to make was that we should clearly define how new schemas are added, and that the claims object should contain only schema objects, which then contain how to request and respond to identity claims. > > A better way would be XYZ concepts challenged by XAuth's rigour (surely > Dick and others would make sure of that) and several iterative > implementations to make sure it does work as intended, as we propose to do. > I am challenging the XYZ concepts with XAuth! Would be great for you to provide feedback on the concepts I have challenged. Perhaps after you have implemented XAuth you can provide an implementation perspective? /Dick --0000000000006a70d605a836ccbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fabien

=
Thanks for diving in and doing an implementation, and providing your o= bservations! ... comments inline ...


On Wed, Jun 10, 20= 20 at 1:56 AM Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi,=C2=A0
=
Just to let you know that we started our own implementa= tion of XYZ / XAuth (and future GNAP).
It's just a first atte= mpt of getting the concepts put into use quickly. We wanted to have a clear= separation between the client and the AS, and demonstrate the retrieval of= a protected resource to make it simpler for people to understand (even if = there's nothing new there).=C2=A0

Here's a= quick MVP of xyz.=20 Currently it's just implementing a basic flow, redirect with callback i= nteraction.
(also working on the same for XAuth, because I sometimes get a bit lost i= n discussions between Justin and Dick, really need to get down to the draft= s and write concrete examples to=C2=A0get a sense of what it=C2=A0means).= =C2=A0
This is very=C2=A0basic/naive but really gave us some bett= er ideas on what to test/implement next,=C2=A0and contribute to the discuss= ion.=C2=A0

I'm keen t= o see an XAuth implementation. Please let me know if there is anything unde= rspecified that is holding you back.
=C2=A0
=C2=A0
Note also that our target implementation will be in rust, and we are cur= rently testing the approach on how to best implement it using a system orie= nted language (the fact that nodejs is very web oriented is abstracting som= e important aspects in our view).
Our work is available under an MPLv2 licence, and we'll be happy to kee= p working on=C2=A0a separate and open reference implementation.=C2=A0 =C2= =A0

As a last comment, I'd like to say that bo= th XYZ and XAuth are great work, but it seems we're having 2 competing = views,=C2=A0difficult=C2=A0to reconcile. I believe we can do better.
<= div>
Following our experiments, I would say:=C2=A0
= a) XYZ really makes a new experience possible, and the flow really fixes co= mmon issues in OAuth2. I believe this design idea is of great value, but th= e downside is that the written spec doesn't explicitly cover=C2=A0every= aspect yet,=C2=A0so sometimes you have to guess or dig into Justin's i= mplementation. But making sure we clarify that is also what the working gro= up is there for, isn't it?=C2=A0
Justin has even put his mone= y where his mouth is by providing implementations and integrating with lega= cy software (an old implementation by mitre), so it's a very good sign = that we won't end up with unnecessary breaking changes.=C2=A0

In which areas did you need to dig= into Justin's implementation?

"XYZ reall= y makes a new experience possible" -- do you think the new experience = was not possible in XAuth?
=C2=A0
=C2=A0 =C2=A0=C2=A0
b) XAuth's spec is written in a more consistent way, which=C2=A0r= eflects the fact that is closer to the previous art. There is no reference = implementation (as far as I'm aware) and it comes with the potential do= wnside of having a more opinionated/prescriptive stance and being much clos= er to legacy (for good or worse).=C2=A0
=
In contrast to OAuth 2, which was a framework, our charter i= s to deliver a protocol. IMHO being opinionated and prescriptive simplifies= interoperability or a protocol.=C2=A0
=C2=A0

However, I don't think the game of spotting the differences is that = meaningful, and the charter should provide sufficient common ground to proc= eed forward despite or thanks to those differences. Otherwise we'll end= up in surprisingly narrow considerations, such as I prefer X because it= 9;s reusing existing schemas. This is something we need to handle when time= comes, but that's really an implementation detail and obviously nobody= thinks we shouldn't reuse things that do work.=C2=A0
=

The intention is not a game of spot the di= fference, but to discuss different proposals for providing functionality.

wrt. the schema discussion, one aspect is reusing a= n existing schema, which is not an implementation detail, but must be speci= fied. The more significant point I was trying to make was that we should cl= early define how new schemas are added, and that the claims object should c= ontain only schema objects, which then contain how to request and respond t= o identity claims.

=C2=A0

= A better way would be XYZ concepts challenged by XAuth's rigour (surely= Dick and others would make sure of that) and several iterative implementat= ions to make sure it=C2=A0does work as intended,=C2=A0as we propose to do.= =C2=A0

I am challenging t= he XYZ concepts with XAuth! Would be great for you to provide feedback on t= he concepts I have challenged. Perhaps after you have implemented XAuth you= can provide an implementation perspective?
=C2=A0
/Dic= k
--0000000000006a70d605a836ccbb-- From nobody Tue Jun 16 10:44:26 2020 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 96BD03A0365 for ; Tue, 16 Jun 2020 10:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 taFvfDjzxlna for ; Tue, 16 Jun 2020 10:44:22 -0700 (PDT) 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 1CB833A03F6 for ; Tue, 16 Jun 2020 10:44:21 -0700 (PDT) Received: from [192.168.1.14] (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 05GHiEgv025636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Jun 2020 13:44:15 -0400 From: Justin Richer Message-Id: <8F9A2198-A6FB-4899-805B-E6AD9CE2BED2@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_F0AD1AC1-F13A-4354-854D-B7A0F8049AF3" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 16 Jun 2020 13:44:14 -0400 In-Reply-To: Cc: Mike Jones , "vittorio.bertocci@auth0.com" , Peter Saint-Andre , Fabien Imbault , Jared Jennings , Amanjeev Sethi , "txauth@ietf.org" To: Dick Hardt References: <5443710B-05DB-4C4D-AC4B-0D8D173E131B@mit.edu> <1B439ED3-E7DF-49B2-A064-4CB5CC3147A0@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] GNAP it is 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, 16 Jun 2020 17:44:25 -0000 --Apple-Mail=_F0AD1AC1-F13A-4354-854D-B7A0F8049AF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My concern on the pronunciation remains, and I don=E2=80=99t think = putting a pronunciation in the charter, which hardly anyone will read = again after a couple weeks from now, is going to address it. That=E2=80=99= s why I think we should just get used to hearing it multiple ways, which = you=E2=80=99ve agreed with. I personally think it=E2=80=99s just a = problem we=E2=80=99ll have to live with, and that was one of the = concerns I had with the name. But really, does it matter? I don=E2=80=99t think it does. =E2=80=94 Justin > On Jun 16, 2020, at 1:08 PM, Dick Hardt wrote: >=20 > It seems strange that you now call addressing the concerns you raised = "silly".=20 >=20 > While there is no confusion in written communication with GNAP, there = clearly will be in verbal communication.=20 >=20 > Starting off with a suggested pronunciation looks to me to nip a = significant amount of the confusion in the bud. >=20 > We can deal with it now, or deal with it later, or it can be a source = of confusion and communication friction forever. >=20 > Why not just pick one pronunciation and move on? >=20 > On Tue, Jun 16, 2020 at 7:42 AM Justin Richer > wrote: > I don=E2=80=99t believe we should add a proposed pronunciation to the = charter. It seems silly to focus on this so much. >=20 > =E2=80=94 Justin >=20 >> On Jun 15, 2020, at 6:14 PM, Dick Hardt > wrote: >>=20 >> I agree we should be prepared for both. Can we agree that we can be = consistent? Personally I don't care which we choose -- I only care that = we choose one. >>=20 >> I was working to address the concern that you (Justin) had brought = up: >>=20 >>> This is ok, but it has a couple downsides. The pronunciation of a = hard =E2=80=9Cg=E2=80=9D or not is going to potentially be confusing, as = is the fact that it looks like it=E2=80=99s part of the GNU project = because of that. >>>=20 >>>=20 >>=20 >> On Mon, Jun 15, 2020 at 1:56 PM Justin Richer > wrote: >> I agree with Mike, in that we should get used to answering to both. >>=20 >> In my head, it reads with a hard =E2=80=9CG=E2=80=9D, at least = partially because of the Smurfs video=E2=80=99s legacy. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jun 15, 2020, at 3:38 PM, Mike Jones = > wrote: >>>=20 >>> I don=E2=80=99t care a lot one way or the other. My main point is = that no matter what guidance we give, many people are likely to = pronounce the =E2=80=9CG=E2=80=9D. If we try to insist on it being = silent, we should get used to the fact that we=E2=80=99ll probably be = hearing both pronunciations. >>> =20 >>> -- Mike >>> =20 >>> P.S. Thanks for the Smurfs link, Vittorio! >>> =20 >>> From: vittorio.bertocci@auth0.com = >=20 >>> Sent: Monday, June 15, 2020 12:25 PM >>> To: 'Dick Hardt' >; 'Peter Saint-Andre' > >>> Cc: Mike Jones >; 'Jared Jennings' = >; 'Amanjeev = Sethi' >; 'Fabien Imbault' = >; = txauth@ietf.org >>> Subject: RE: [Txauth] GNAP it is >>> =20 >>> Perhaps not to be taken too seriously, but here=E2=80=99s prior art = on GNAP pronunciation. >>> As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on = the Smurfs comic and was reprised in a cartoon episode as well. >>> You=E2=80=99ll find few examples around 3:30 >>> = https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbclid=3D= IwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ = >>> =20 >>> From: Txauth > On Behalf Of Dick Hardt >>> Sent: Monday, June 15, 2020 12:18 PM >>> To: Peter Saint-Andre > >>> Cc: Mike Jones >; Jared Jennings = >; Amanjeev = Sethi >; Fabien Imbault = >; = txauth@ietf.org >>> Subject: Re: [Txauth] GNAP it is >>> =20 >>> Checking in again on pronunciation. >>> =20 >>> Mike: do you still have concerns with a silent 'G'? >>> =20 >>> Anyone else have concerns? >>> =20 >>> I'd like to nip pronunciation confusion in the bud by having the = recommended pronunciation in the charter. >>> =20 >>> =20 >>> =E1=90=A7 >>> =20 >>> On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre = > wrote: >>> Looks like we were caught gnapping. ;-) >>>=20 >>> OK, that's the last of my snarky comments, let's get to work! >>>=20 >>> Peter >>>=20 >>> On 6/7/20 2:09 PM, Dick Hardt wrote: >>> > It is if you are familiar with any of the GNU projects. >>> >=20 >>> > https://www.gnu.org/gnu/pronunciation.en.html = >>> >=20 >>> > A quick search on the internet has the "normal" pronunciation of = "gnu" >>> > to have a silent 'g'. >>> >=20 >>> > https://www.howtopronounce.com/gnu = >>> > https://dictionary.cambridge.org/us/pronunciation/english/gnu = >>> >=20 >>> >=20 >>> > =E1=90=A7 >>> >=20 >>> > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones = >>> > >> wrote: >>> >=20 >>> > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation = of GNU. I >>> > think that=E2=80=99s the most natural way to read it.____ >>> >=20 >>> > __ __ >>> >=20 >>> > -- = Mike____ >>> >=20 >>> > __ __ >>> >=20 >>> > *From:* Txauth >>> > >> *On Behalf Of *Dick Hardt >>> > *Sent:* Sunday, June 7, 2020 12:45 PM >>> > *To:* Amanjeev Sethi = >> >>> > *Cc:* Fabien Imbault >>> > >>; Jared Jennings >>> > = >>; >>> > txauth@ietf.org = > >>> > *Subject:* Re: [Txauth] GNAP it is____ >>> >=20 >>> > __ __ >>> >=20 >>> > Anyone have objection to the recommended pronunciation being = the >>> > English word "nap", as in "gnaw"?____ >>> >=20 >>> > __ __ >>> >=20 >>> > If not, then we could add a pronunciation recommendation to = the >>> > Charter.____ >>> >=20 >>> > __ __ >>> >=20 >>> > =E1=90=A7____ >>> >=20 >>> > __ __ >>> >=20 >>> > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi >>> > >> wrote:____ >>> >=20 >>> > Vote for 'G' silent, as in 'lagnappe' ;)____ >>> >=20 >>> > __ __ >>> >=20 >>> > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings = wrote:____ >>> >=20 >>> > I vote for G silent. For the reason it's most common = to >>> > pronounce, especially for those not familiar with open >>> > source usages.____ >>> >=20 >>> > __ __ >>> >=20 >>> > On Sat, Jun 6, 2020, 08:45 Dick Hardt = >>> > >> wrote:____ >>> >=20 >>> > The obvious pronunciation choices are:____ >>> >=20 >>> > __ __ >>> >=20 >>> > nap (silent g as in gnaw)____ >>> >=20 >>> > __ __ >>> >=20 >>> > guh-nap (as in the GNU OS >>> > - https://www.gnu.org/gnu/pronunciation.en..html = >>> > >)____ >>> >=20 >>> > __ __ >>> >=20 >>> > gee-nap (as in G-man - government man >>> > - https://en.wikipedia.org/wiki/G-man)____ = >>> >=20 >>> > __ __ >>> >=20 >>> > __ __ >>> >=20 >>> > __ __ >>> >=20 >>> > =E1=90=A7____ >>> >=20 >>> > __ __ >>> >=20 >>> > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault >>> > >>> > >> wrote:____ >>> >=20 >>> > So, let's adopt a GNAP! We can even come with = a >>> > little mascot (a bit like go gopher) as = imagined >>> > by http://elisegravel.com/blog/adopte-un-gnap/ = , >>> > loved by little Canadians :-) ____ >>> >=20 >>> > __ __ >>> >=20 >>> > Just to be sure, how do you recommand we = pronounce >>> > it? ____ >>> >=20 >>> > __ __ >>> >=20 >>> > Looking forward to the next steps too.. ____ >>> >=20 >>> > __ __ >>> >=20 >>> > Thxs____ >>> >=20 >>> > Fabien____ >>> >=20 >>> > --____ >>> >=20 >>> > Txauth mailing list____ >>> >=20 >>> > Txauth@ietf.org = >____ >>> >=20 >>> > = https://www.ietf.org/mailman/listinfo/txauth____ = >>> >=20 >>> > --____ >>> >=20 >>> > Txauth mailing list____ >>> >=20 >>> > Txauth@ietf.org = >____ >>> >=20 >>> > https://www.ietf.org/mailman/listinfo/txauth____ = >>> >=20 >>> > -- ____ >>> >=20 >>> > Txauth mailing list____ >>> >=20 >>> > Txauth@ietf.org = >____ >>> >=20 >>> > 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 --Apple-Mail=_F0AD1AC1-F13A-4354-854D-B7A0F8049AF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = concern on the pronunciation remains, and I don=E2=80=99t think putting = a pronunciation in the charter, which hardly anyone will read again = after a couple weeks from now, is going to address it. That=E2=80=99s = why I think we should just get used to hearing it multiple ways, which = you=E2=80=99ve agreed with. I personally think it=E2=80=99s just a = problem we=E2=80=99ll have to live with, and that was one of the = concerns I had with the name.

But really, does it matter? I don=E2=80=99t think it does.

 =E2=80= =94 Justin

On Jun 16, 2020, at 1:08 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:

It = seems strange that you now call addressing the concerns you = raised "silly". 

While there is no confusion in written communication with = GNAP, there clearly will be in verbal communication. 

Starting off with a = suggested pronunciation looks to me to nip a significant amount of the = confusion in the bud.

We can deal with it now, or deal with it later, or it can be = a source of confusion and communication friction forever.

Why not just pick one = pronunciation and move on?

On Tue, Jun = 16, 2020 at 7:42 AM Justin Richer <jricher@mit.edu> wrote:
I don=E2=80=99t believe we should add a proposed = pronunciation to the charter. It seems silly to focus on this so = much.

 =E2=80=94 = Justin

On Jun 15, 2020, at 6:14 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:

I = agree we should be prepared for both. Can we agree that we can be = consistent? Personally I don't care which we choose -- I only care that = we choose one.

I was working to address the concern that = you (Justin) had brought up:

This is ok, but it has a couple downsides. The pronunciation = of a hard =E2=80=9Cg=E2=80=9D or not is going to potentially be = confusing, as is the fact that it looks like it=E2=80=99s part of the = GNU project because of that.



On Mon, Jun = 15, 2020 at 1:56 PM Justin Richer <jricher@mit.edu> wrote:
I agree with Mike, in = that we should get used to answering to both.

In my head, it reads with a hard = =E2=80=9CG=E2=80=9D, at least partially because of the Smurfs video=E2=80=99= s legacy.

 =E2=80=94 Justin

On Jun = 15, 2020, at 3:38 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

I don=E2=80=99t care a lot one = way or the other.  My main point is that no matter what guidance we = give, many people are likely to pronounce the =E2=80=9CG=E2=80=9D.  = If we try to insist on it being silent, we should get used to the fact = that we=E2=80=99ll probably be hearing both pronunciations.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
P.S.  Thanks for the Smurfs = link, Vittorio!
 
From: vittorio.bertocci@auth0.com <vittorio.bertocci@auth0.com> 
Sent: Monday, June 15, 2020 12:25 PM
To: 'Dick Hardt' <dick.hardt@gmail.com>; 'Peter Saint-Andre' <stpeter@mozilla.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; 'Jared Jennings' <jaredljennings@gmail.com>; 'Amanjeev Sethi' <aj@amanjeev.com>; 'Fabien Imbault' <fabien.imbault@gmail.com>; txauth@ietf.org
Subject: RE: [Txauth] GNAP = it is
 
Perhaps not to be taken too seriously, but here=E2=80=99s = prior art on GNAP pronunciation.
As = Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the = Smurfs comic and was reprised in a cartoon episode as well.
You=E2=80=99ll find few examples around 3:30
 https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyou= tu.be&fbclid=3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WB= JgPbpQ
 
From: Txauth <txauth-bounces@ietf.org> On Behalf Of Dick Hardt
Sent: Monday, = June 15, 2020 12:18 PM
To: Peter Saint-Andre <stpeter@mozilla.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; Jared Jennings <jaredljennings@gmail.com>; Amanjeev Sethi <aj@amanjeev.com>; Fabien Imbault <fabien.imbault@gmail.com>; txauth@ietf.org
Subject: Re: [Txauth] GNAP = it is
 
Checking in again on pronunciation.
 
Mike: = do you still have concerns with a silent 'G'?
 
Anyone = else have concerns?
 
I'd = like to nip pronunciation confusion in the bud by having the recommended = pronunciation in the charter.
 
 
=E1=90=A7
 
On = Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre <stpeter@mozilla.com> wrote:
Looks like we were caught gnapping. ;-)

OK, that's the last of my snarky comments, let's get to = work!

Peter

On = 6/7/20 2:09 PM, Dick Hardt wrote:
> It is if you are = familiar with any of the GNU projects.
> 
> https://www.gnu.org/gnu/pronunciation.en.html
> 
> A quick = search on the internet has the "normal" pronunciation of "gnu"
> to have a silent 'g'.
> 
> https://www.howtopronounce.com/gnu
> https://dictionary.cambridge.org/us/pronunciation/english/gnu
> 
> 
> =E1=90=A7
> 
> On Sun, Jun 7, 2020 at 12:51 = PM Mike Jones <Michael.Jones@microsoft.com
> = <mailto:Michael.Jones@microsoft.com>> wrote:
> 
>  =    I had assumed Guh-Nap =E2=80=93 parallel to the = pronunciation of GNU.  I
>    =  think that=E2=80=99s the most natural way to read it.____
> 
>  =    __ __
> 
>    =             &n= bsp;           &nbs= p;            =             &n= bsp;      -- Mike____
> 
>    =  __ __
> 
>     *From:* Txauth <txauth-bounces@ietf.org
>    =  <mailto:txauth-bounces@ietf.org>> *On Behalf Of *Dick = Hardt
>     *Sent:* Sunday, June 7, 2020 = 12:45 PM
>     *To:* Amanjeev Sethi = <aj@amanjeev.com <mailto:aj@amanjeev.com>>
>    =  *Cc:* Fabien Imbault <fabien.imbault@gmail.com
>    =  <mailto:fabien.imbault@gmail.com>>; Jared Jennings
>     <jaredljennings@gmail.com <mailto:jaredljennings@gmail.com>>;
>  =    txauth@ietf.org <mailto:txauth@ietf.org>
>    =  *Subject:* Re: [Txauth] GNAP it is____
> 
>    =  __ __
> 
>     Anyone have objection to the = recommended pronunciation being the
>    =  English word "nap", as in "gnaw"?____
> 
>    =  __ __
> 
>     If not, then we could add a = pronunciation recommendation to the
>    =  Charter.____
> 
>     __ __
> 
>     =E1=90=A7____> 
>  =    __ __
> 
>     On Sat, = Jun 6, 2020 at 8:03 AM Amanjeev Sethi <aj@amanjeev.com
>    =  <mailto:aj@amanjeev.com>> wrote:____
> 
>        =  Vote for 'G' silent, as in 'lagnappe' ;)____
> 
>        =  __ __
> 
>         On Sat, Jun 6, 2020, at = 10:52 AM, Jared Jennings wrote:____
> 
>        =      I vote for G silent. For the reason it's most common = to
>            =  pronounce, especially for those not familiar with open
>             source = usages.____
> 
>            =  __ __
> 
>             On Sat, = Jun 6, 2020, 08:45 Dick Hardt <dick.hardt@gmail.com
>    =          <mailto:dick.hardt@gmail.com>> wrote:____
> 
>  =                The obvious = pronunciation choices are:____
> 
>        =          __ __
> 
>        =          nap (silent g as in gnaw)____
> 
>  =                __ __
> 
>  =                guh-nap (as in = the GNU OS
>            =      - https://www.gnu.org/gnu/pronunciation.en..html
>                =  <https://www.gnu.org/gnu/pronunciation.en.html>)____
> 
>  =                __ __
> 
>  =                gee-nap (as in = G-man - government man
>        =          - https://en.wikipedia.org/wiki/G-man)____
> 
>  =                __ __
> 
>  =                __ __
> 
>  =                __ __
> 
>  =                =E1=90=A7____> 
>  =                __ __
> 
>  =                On Sat, Jun 6, = 2020 at 1:34 AM Fabien Imbault
>      =            <fabien.imbault@gmail.com
>    =              <mailto:fabien.imbault@gmail.com>> wrote:____
> 
>  =                    So, = let's adopt a GNAP! We can even come with a
>  =                   =  little mascot (a bit like go gopher) as imagined
>                =      by http://elisegravel.com/blog/adopte-un-gnap/,
>                =      loved by little Canadians :-) ____
> 
>  =                   =  __ __
> 
>                =      Just to be sure, how do you recommand we = pronounce
>            =          it? ____
> 
>        =              __ __
> 
>  =                   =  Looking forward to the next steps too.. ____
> 
>  =                   =  __ __
> 
>                =      Thxs____
> 
>        =              Fabien____
> 
>  =                   =  --____
> 
>                =      Txauth mailing list____
> 
>        =              Txauth@ietf.org <mailto:Txauth@ietf.org>____
> 
>        =              https://www.ietf.org/mailman/listinfo/txauth____
> 
>  =                --____
> 
>  =                Txauth mailing = list____
> 
>                =  Txauth@ietf.org <mailto:Txauth@ietf.org>____
> 
>        =          https://www.ietf.org/mailman/listinfo/txauth____
> 
>  =            -- ____
> 
>  =            Txauth mailing list____
> 
>  =            Txauth@ietf.org <mailto: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=_F0AD1AC1-F13A-4354-854D-B7A0F8049AF3-- From nobody Tue Jun 16 10:53:08 2020 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 307ED3A07C4 for ; Tue, 16 Jun 2020 10:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 rgGbcpBxKS7C for ; Tue, 16 Jun 2020 10:53:03 -0700 (PDT) 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 91DA83A0486 for ; Tue, 16 Jun 2020 10:53:02 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id w15so12262538lfe.11 for ; Tue, 16 Jun 2020 10:53:02 -0700 (PDT) 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=/NDtI7I6HvVJpqCcBG28g1u7OHyS9OMyLd6OcBcsb7o=; b=olEThn8KDo1Pif8D5xlI31B77gztEwqTFczd0nAtwBozqd5bFUUFtezNjIzbu/ZKh5 1XSs+B3n2QuilWEIpL0ReY/opumY5j70P7p3EPJ5QTwDZFLIbuT9QE4XaQravWcclDJF UkpLqn/1ixD9u/fa3TZ/cA9sumwDNBl1w4Jvzj2dbMb7iXBwkMoEgHoHESgdQLan997h uZmodGDdlSoQZLCf15rT6d+EKpbUiF/SODDAT2fI5zTUuRn1gr1Q9d7YBibwJCs1pz3y OORGR57EpUkyimwvQ2NKvtw0erASfTI6Fcu+LLokP3IMDwOfl7sEBHdDNFQloRh+9MO8 P8iw== 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=/NDtI7I6HvVJpqCcBG28g1u7OHyS9OMyLd6OcBcsb7o=; b=bnMA7spCPb36OPW0WGwTio0j+5zYgVBsJD5E+VcaO6/mKxBm21YMGDT1xlv4cq7fGH MouPYw0WgvITw5hOZ/UUI/OK2fmh+rg0rTz+JiN7Tn9rQIWpQG+6B+0iT02TUITpski/ Iu/lq1F6XSqOarwH3dUuyXetilT4eyfDMnLuY/1FsJKbf8d3T1xPYGptwBNJUUAf25JH WTTliNgwX4OKb2QlSb1B5+Wf+7ujt96RGMJjbi7AUY4vYDG2NJqZEQDo9rH2Sfy6nEIN MPkmb/oYs92/0AisYrP8bwb3dIg1+jixnq+h5mgQTUqfRHWMQtMs3QuGKRquaJYpwbgE dUQw== X-Gm-Message-State: AOAM533uRFG0ZjLyyBYMiXLdFW01TviZGdaMhqUM2F4kxr9zNxV3kS9z 1mMIRvJkpLIaKVX8LIM3QOiUDk61e6ladcNuOzY= X-Google-Smtp-Source: ABdhPJzvpC6Pul/iTy5ELDaFOaE4JJd+yWwtJ8mDq0DEO3V9+dcBsFip+2hNC41UahH0Qe9Xe9S/64//6WL9KIUhl9s= X-Received: by 2002:a19:14e:: with SMTP id 75mr2256358lfb.7.1592329980552; Tue, 16 Jun 2020 10:53:00 -0700 (PDT) MIME-Version: 1.0 References: <5443710B-05DB-4C4D-AC4B-0D8D173E131B@mit.edu> <1B439ED3-E7DF-49B2-A064-4CB5CC3147A0@mit.edu> <8F9A2198-A6FB-4899-805B-E6AD9CE2BED2@mit.edu> In-Reply-To: <8F9A2198-A6FB-4899-805B-E6AD9CE2BED2@mit.edu> From: Dick Hardt Date: Tue, 16 Jun 2020 10:52:34 -0700 Message-ID: To: Justin Richer Cc: Mike Jones , "vittorio.bertocci@auth0.com" , Peter Saint-Andre , Fabien Imbault , Jared Jennings , Amanjeev Sethi , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000db289405a83736a0" Archived-At: Subject: Re: [Txauth] GNAP it is 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, 16 Jun 2020 17:53:07 -0000 --000000000000db289405a83736a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think precision in communication matters, so yes, I think it matters. How will we pronounce it in our in-person or virtual meetings? While I agree that we need to anticipate people will mispronounce it, we can inform them of the suggested pronunciation. While putting the pronunciation in the charter does not solve the issue, it is a starting point. I have added the suggested pronunciation to XAuth. What is your concern with putting it in the charter? Why would you not want to minimize miscommunication? FWIW: I think that guh-nap is a better pronunciation choice as it makes it clear it is not spelled "NAP" On Tue, Jun 16, 2020 at 10:44 AM Justin Richer wrote: > My concern on the pronunciation remains, and I don=E2=80=99t think puttin= g a > pronunciation in the charter, which hardly anyone will read again after a > couple weeks from now, is going to address it. That=E2=80=99s why I think= we should > just get used to hearing it multiple ways, which you=E2=80=99ve agreed wi= th. I > personally think it=E2=80=99s just a problem we=E2=80=99ll have to live w= ith, and that was > one of the concerns I had with the name. > > But really, does it matter? I don=E2=80=99t think it does. > > =E2=80=94 Justin > > On Jun 16, 2020, at 1:08 PM, Dick Hardt wrote: > > It seems strange that you now call addressing the concerns you raised > "silly". > > While there is no confusion in written communication with GNAP, there > clearly will be in verbal communication. > > Starting off with a suggested pronunciation looks to me to nip a > significant amount of the confusion in the bud. > > We can deal with it now, or deal with it later, or it can be a source of > confusion and communication friction forever. > > Why not just pick one pronunciation and move on? > > On Tue, Jun 16, 2020 at 7:42 AM Justin Richer wrote: > >> I don=E2=80=99t believe we should add a proposed pronunciation to the ch= arter. It >> seems silly to focus on this so much. >> >> =E2=80=94 Justin >> >> On Jun 15, 2020, at 6:14 PM, Dick Hardt wrote: >> >> I agree we should be prepared for both. Can we agree that we can be >> consistent? Personally I don't care which we choose -- I only care that = we >> choose one. >> >> I was working to address the concern that you (Justin) had brought up: >> >> This is ok, but it has a couple downsides. The pronunciation of a hard >> =E2=80=9Cg=E2=80=9D or not is going to potentially be confusing, as is t= he fact that it >> looks like it=E2=80=99s part of the GNU project because of that. >> >> >> >> On Mon, Jun 15, 2020 at 1:56 PM Justin Richer wrote: >> >>> I agree with Mike, in that we should get used to answering to both. >>> >>> In my head, it reads with a hard =E2=80=9CG=E2=80=9D, at least partiall= y because of the >>> Smurfs video=E2=80=99s legacy. >>> >>> =E2=80=94 Justin >>> >>> On Jun 15, 2020, at 3:38 PM, Mike Jones < >>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >>> >>> I don=E2=80=99t care a lot one way or the other. My main point is that= no >>> matter what guidance we give, many people are likely to pronounce the = =E2=80=9CG=E2=80=9D. >>> If we try to insist on it being silent, we should get used to the fact = that >>> we=E2=80=99ll probably be hearing both pronunciations. >>> >>> -- Mike >>> >>> P.S. Thanks for the Smurfs link, Vittorio! >>> >>> *From:* vittorio.bertocci@auth0.com >>> *Sent:* Monday, June 15, 2020 12:25 PM >>> *To:* 'Dick Hardt' ; 'Peter Saint-Andre' < >>> stpeter@mozilla.com> >>> *Cc:* Mike Jones ; 'Jared Jennings' < >>> jaredljennings@gmail.com>; 'Amanjeev Sethi' ; 'Fabien >>> Imbault' ; txauth@ietf.org >>> *Subject:* RE: [Txauth] GNAP it is >>> >>> Perhaps not to be taken too seriously, but here=E2=80=99s prior art on = GNAP >>> pronunciation. >>> As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the= Smurfs comic and >>> was reprised in a cartoon episode as well. >>> You=E2=80=99ll find few examples around 3:30 >>> >>> https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbclid= =3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ >>> >>> *From:* Txauth *On Behalf Of *Dick Hardt >>> *Sent:* Monday, June 15, 2020 12:18 PM >>> *To:* Peter Saint-Andre >>> *Cc:* Mike Jones ; Jared Jennings < >>> jaredljennings@gmail.com>; Amanjeev Sethi ; Fabien >>> Imbault ; txauth@ietf.org >>> *Subject:* Re: [Txauth] GNAP it is >>> >>> Checking in again on pronunciation. >>> >>> Mike: do you still have concerns with a silent 'G'? >>> >>> Anyone else have concerns? >>> >>> I'd like to nip pronunciation confusion in the bud by having the >>> recommended pronunciation in the charter. >>> >>> >>> =E1=90=A7 >>> >>> On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre >>> wrote: >>> >>> Looks like we were caught gnapping. ;-) >>> >>> OK, that's the last of my snarky comments, let's get to work! >>> >>> Peter >>> >>> On 6/7/20 2:09 PM, Dick Hardt wrote: >>> > It is if you are familiar with any of the GNU projects. >>> > >>> > https://www.gnu.org/gnu/pronunciation.en.html >>> > >>> > A quick search on the internet has the "normal" pronunciation of "gnu= " >>> > to have a silent 'g'. >>> > >>> > https://www.howtopronounce.com/gnu >>> > https://dictionary.cambridge.org/us/pronunciation/english/gnu >>> > >>> > >>> > =E1=90=A7 >>> > >>> > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones < >>> Michael.Jones@microsoft.com >>> > > wrote: >>> > >>> > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of = GNU. I >>> > think that=E2=80=99s the most natural way to read it.____ >>> > >>> > __ __ >>> > >>> > -- Mike___= _ >>> > >>> > __ __ >>> > >>> > *From:* Txauth >> > > *On Behalf Of *Dick Hardt >>> > *Sent:* Sunday, June 7, 2020 12:45 PM >>> > *To:* Amanjeev Sethi > >>> > *Cc:* Fabien Imbault >> > >; Jared Jennings >>> > >; >>> > txauth@ietf.org >>> > *Subject:* Re: [Txauth] GNAP it is____ >>> > >>> > __ __ >>> > >>> > Anyone have objection to the recommended pronunciation being the >>> > English word "nap", as in "gnaw"?____ >>> > >>> > __ __ >>> > >>> > If not, then we could add a pronunciation recommendation to the >>> > Charter.____ >>> > >>> > __ __ >>> > >>> > =E1=90=A7____ >>> > >>> > __ __ >>> > >>> > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi >> > > wrote:____ >>> > >>> > Vote for 'G' silent, as in 'lagnappe' ;)____ >>> > >>> > __ __ >>> > >>> > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____ >>> > >>> > I vote for G silent. For the reason it's most common to >>> > pronounce, especially for those not familiar with open >>> > source usages.____ >>> > >>> > __ __ >>> > >>> > On Sat, Jun 6, 2020, 08:45 Dick Hardt < >>> dick.hardt@gmail.com >>> > > wrote:____ >>> > >>> > The obvious pronunciation choices are:____ >>> > >>> > __ __ >>> > >>> > nap (silent g as in gnaw)____ >>> > >>> > __ __ >>> > >>> > guh-nap (as in the GNU OS >>> > - https://www.gnu.org/gnu/pronunciation.en..html >>> > )____ >>> > >>> > __ __ >>> > >>> > gee-nap (as in G-man - government man >>> > - https://en.wikipedia.org/wiki/G-man)____ >>> > >>> > __ __ >>> > >>> > __ __ >>> > >>> > __ __ >>> > >>> > =E1=90=A7____ >>> > >>> > __ __ >>> > >>> > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault >>> > >> > > wrote:____ >>> > >>> > So, let's adopt a GNAP! We can even come with a >>> > little mascot (a bit like go gopher) as imagined >>> > by http://elisegravel.com/blog/adopte-un-gnap/, >>> > loved by little Canadians :-) ____ >>> > >>> > __ __ >>> > >>> > Just to be sure, how do you recommand we pronounc= e >>> > it? ____ >>> > >>> > __ __ >>> > >>> > Looking forward to the next steps too.. ____ >>> > >>> > __ __ >>> > >>> > Thxs____ >>> > >>> > Fabien____ >>> > >>> > --____ >>> > >>> > 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____ >>> > >>> > __ __ >>> > >>> > __ __ >>> > >>> > >>> >>> -- >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth >>> >>> >>> >> > --000000000000db289405a83736a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think precision in communication matters, so yes, I thin= k it matters. How will we pronounce it in our in-person or virtual meetings= ?=C2=A0

While I agree that we need to anticipate peo= ple will mispronounce it, we can inform them of the suggested pronunciation= .

While=C2=A0putting the pronunciation=C2=A0in the= charter does not solve the issue, it is a starting point. I have added the= suggested pronunciation=C2=A0to XAuth.

What is yo= ur concern with putting it in the charter? Why would you not want to minimi= ze miscommunication?

FWIW: I think=C2=A0that guh-n= ap is a better pronunciation choice as it makes it clear it is not spelled = "NAP"




--000000000000db289405a83736a0-- From nobody Tue Jun 16 11:23:42 2020 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 183663A0835 for ; Tue, 16 Jun 2020 11:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 yV8Vhh6qCgH9 for ; Tue, 16 Jun 2020 11:23:38 -0700 (PDT) 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 351FC3A0838 for ; Tue, 16 Jun 2020 11:23:38 -0700 (PDT) Received: from [192.168.1.14] (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 05GINUul009906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 16 Jun 2020 14:23:30 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AF6EAE6B-726B-4002-A865-F95E2E4C13A9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 16 Jun 2020 14:23:30 -0400 In-Reply-To: Cc: Mike Jones , "vittorio.bertocci@auth0.com" , Peter Saint-Andre , Fabien Imbault , Jared Jennings , Amanjeev Sethi , "txauth@ietf.org" To: Dick Hardt References: <5443710B-05DB-4C4D-AC4B-0D8D173E131B@mit.edu> <1B439ED3-E7DF-49B2-A064-4CB5CC3147A0@mit.edu> <8F9A2198-A6FB-4899-805B-E6AD9CE2BED2@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] GNAP it is 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, 16 Jun 2020 18:23:41 -0000 --Apple-Mail=_AF6EAE6B-726B-4002-A865-F95E2E4C13A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m really confused as to what the problem here is: I=E2=80=99ve said that I prefer it with a hard =E2=80=9Cg=E2=80=9D and = will likely continue to read it like that in my head. I have also stated = that I don=E2=80=99t think putting it in the charter will help people = people =E2=80=9Cfix=E2=80=9D the pronunciation. This is my opinion on = the matter, which I have stated and now been made to defend a number of = times. None of this stops anyone from putting pronunciation guides into the = charter or eventual specs if people think it=E2=80=99s worth it. I=E2=80=99= m not the only voice here, and I=E2=80=99ve said it doesn=E2=80=99t = really matter to me because I don=E2=80=99t think it will actually help.=20= Therefore if it really is that important to you, and the chairs and ADs = agree to the charter text change, then just do it.=20 Can you help me understand what else you=E2=80=99re looking for from me? =E2=80=94 Justin > On Jun 16, 2020, at 1:52 PM, Dick Hardt wrote: >=20 > I think precision in communication matters, so yes, I think it = matters. How will we pronounce it in our in-person or virtual meetings?=20= >=20 > While I agree that we need to anticipate people will mispronounce it, = we can inform them of the suggested pronunciation. >=20 > While putting the pronunciation in the charter does not solve the = issue, it is a starting point. I have added the suggested pronunciation = to XAuth. >=20 > What is your concern with putting it in the charter? Why would you not = want to minimize miscommunication? >=20 > FWIW: I think that guh-nap is a better pronunciation choice as it = makes it clear it is not spelled "NAP" >=20 >=20 >=20 > On Tue, Jun 16, 2020 at 10:44 AM Justin Richer > wrote: > My concern on the pronunciation remains, and I don=E2=80=99t think = putting a pronunciation in the charter, which hardly anyone will read = again after a couple weeks from now, is going to address it. That=E2=80=99= s why I think we should just get used to hearing it multiple ways, which = you=E2=80=99ve agreed with. I personally think it=E2=80=99s just a = problem we=E2=80=99ll have to live with, and that was one of the = concerns I had with the name. >=20 > But really, does it matter? I don=E2=80=99t think it does. >=20 > =E2=80=94 Justin >=20 >> On Jun 16, 2020, at 1:08 PM, Dick Hardt > wrote: >>=20 >> It seems strange that you now call addressing the concerns you raised = "silly".=20 >>=20 >> While there is no confusion in written communication with GNAP, there = clearly will be in verbal communication.=20 >>=20 >> Starting off with a suggested pronunciation looks to me to nip a = significant amount of the confusion in the bud. >>=20 >> We can deal with it now, or deal with it later, or it can be a source = of confusion and communication friction forever. >>=20 >> Why not just pick one pronunciation and move on? >>=20 >> On Tue, Jun 16, 2020 at 7:42 AM Justin Richer > wrote: >> I don=E2=80=99t believe we should add a proposed pronunciation to the = charter. It seems silly to focus on this so much. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jun 15, 2020, at 6:14 PM, Dick Hardt > wrote: >>>=20 >>> I agree we should be prepared for both. Can we agree that we can be = consistent? Personally I don't care which we choose -- I only care that = we choose one. >>>=20 >>> I was working to address the concern that you (Justin) had brought = up: >>>=20 >>>> This is ok, but it has a couple downsides. The pronunciation of a = hard =E2=80=9Cg=E2=80=9D or not is going to potentially be confusing, as = is the fact that it looks like it=E2=80=99s part of the GNU project = because of that. >>>>=20 >>>>=20 >>>=20 >>> On Mon, Jun 15, 2020 at 1:56 PM Justin Richer > wrote: >>> I agree with Mike, in that we should get used to answering to both. >>>=20 >>> In my head, it reads with a hard =E2=80=9CG=E2=80=9D, at least = partially because of the Smurfs video=E2=80=99s legacy. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Jun 15, 2020, at 3:38 PM, Mike Jones = > wrote: >>>>=20 >>>> I don=E2=80=99t care a lot one way or the other. My main point is = that no matter what guidance we give, many people are likely to = pronounce the =E2=80=9CG=E2=80=9D. If we try to insist on it being = silent, we should get used to the fact that we=E2=80=99ll probably be = hearing both pronunciations. >>>> =20 >>>> -- Mike >>>> =20 >>>> P.S. Thanks for the Smurfs link, Vittorio! >>>> =20 >>>> From: vittorio.bertocci@auth0.com = >=20 >>>> Sent: Monday, June 15, 2020 12:25 PM >>>> To: 'Dick Hardt' >; 'Peter Saint-Andre' > >>>> Cc: Mike Jones >; 'Jared Jennings' = >; 'Amanjeev = Sethi' >; 'Fabien Imbault' = >; = txauth@ietf.org >>>> Subject: RE: [Txauth] GNAP it is >>>> =20 >>>> Perhaps not to be taken too seriously, but here=E2=80=99s prior art = on GNAP pronunciation. >>>> As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on = the Smurfs comic and was reprised in a cartoon episode as well. >>>> You=E2=80=99ll find few examples around 3:30 >>>> = https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbclid=3D= IwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ = >>>> =20 >>>> From: Txauth > On Behalf Of Dick Hardt >>>> Sent: Monday, June 15, 2020 12:18 PM >>>> To: Peter Saint-Andre > >>>> Cc: Mike Jones >; Jared Jennings = >; Amanjeev = Sethi >; Fabien Imbault = >; = txauth@ietf.org >>>> Subject: Re: [Txauth] GNAP it is >>>> =20 >>>> Checking in again on pronunciation. >>>> =20 >>>> Mike: do you still have concerns with a silent 'G'? >>>> =20 >>>> Anyone else have concerns? >>>> =20 >>>> I'd like to nip pronunciation confusion in the bud by having the = recommended pronunciation in the charter. >>>> =20 >>>> =20 >>>> =E1=90=A7 >>>> =20 >>>> On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre = > wrote: >>>> Looks like we were caught gnapping. ;-) >>>>=20 >>>> OK, that's the last of my snarky comments, let's get to work! >>>>=20 >>>> Peter >>>>=20 >>>> On 6/7/20 2:09 PM, Dick Hardt wrote: >>>> > It is if you are familiar with any of the GNU projects. >>>> >=20 >>>> > https://www.gnu.org/gnu/pronunciation.en.html = >>>> >=20 >>>> > A quick search on the internet has the "normal" pronunciation of = "gnu" >>>> > to have a silent 'g'. >>>> >=20 >>>> > https://www.howtopronounce.com/gnu = >>>> > https://dictionary.cambridge.org/us/pronunciation/english/gnu = >>>> >=20 >>>> >=20 >>>> > =E1=90=A7 >>>> >=20 >>>> > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones = >>>> > >> wrote: >>>> >=20 >>>> > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation = of GNU. I >>>> > think that=E2=80=99s the most natural way to read it.____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > -- = Mike____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > *From:* Txauth >>>> > >> *On Behalf Of *Dick Hardt >>>> > *Sent:* Sunday, June 7, 2020 12:45 PM >>>> > *To:* Amanjeev Sethi >> >>>> > *Cc:* Fabien Imbault >>>> > >>; Jared Jennings >>>> > = >>; >>>> > txauth@ietf.org = > >>>> > *Subject:* Re: [Txauth] GNAP it is____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > Anyone have objection to the recommended pronunciation being = the >>>> > English word "nap", as in "gnaw"?____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > If not, then we could add a pronunciation recommendation to = the >>>> > Charter.____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > =E1=90=A7____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi = >>>> > >> wrote:____ >>>> >=20 >>>> > Vote for 'G' silent, as in 'lagnappe' ;)____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings = wrote:____ >>>> >=20 >>>> > I vote for G silent. For the reason it's most common = to >>>> > pronounce, especially for those not familiar with = open >>>> > source usages.____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > On Sat, Jun 6, 2020, 08:45 Dick Hardt = >>>> > >> wrote:____ >>>> >=20 >>>> > The obvious pronunciation choices are:____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > nap (silent g as in gnaw)____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > guh-nap (as in the GNU OS >>>> > - https://www.gnu.org/gnu/pronunciation.en..html = >>>> > >)____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > gee-nap (as in G-man - government man >>>> > - https://en.wikipedia.org/wiki/G-man)____ = >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > =E1=90=A7____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault >>>> > >>>> > >> wrote:____ >>>> >=20 >>>> > So, let's adopt a GNAP! We can even come with = a >>>> > little mascot (a bit like go gopher) as = imagined >>>> > by = http://elisegravel.com/blog/adopte-un-gnap/ = , >>>> > loved by little Canadians :-) ____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > Just to be sure, how do you recommand we = pronounce >>>> > it? ____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > Looking forward to the next steps too.. ____ >>>> >=20 >>>> > __ __ >>>> >=20 >>>> > Thxs____ >>>> >=20 >>>> > Fabien____ >>>> >=20 >>>> > --____ >>>> >=20 >>>> > Txauth mailing list____ >>>> >=20 >>>> > Txauth@ietf.org = >____ >>>> >=20 >>>> > = https://www.ietf.org/mailman/listinfo/txauth____ = >>>> >=20 >>>> > --____ >>>> >=20 >>>> > Txauth mailing list____ >>>> >=20 >>>> > Txauth@ietf.org = >____ >>>> >=20 >>>> > https://www.ietf.org/mailman/listinfo/txauth____ = >>>> >=20 >>>> > -- ____ >>>> >=20 >>>> > Txauth mailing list____ >>>> >=20 >>>> > Txauth@ietf.org = >____ >>>> >=20 >>>> > 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 --Apple-Mail=_AF6EAE6B-726B-4002-A865-F95E2E4C13A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I=E2=80=99m really confused as to what the problem here = is:

I=E2=80=99ve said that I = prefer it with a hard =E2=80=9Cg=E2=80=9D and will likely continue to = read it like that in my head. I have also stated that I don=E2=80=99t = think putting it in the charter will help people people =E2=80=9Cfix=E2=80= =9D the pronunciation. This is my opinion on the matter, which I have = stated and now been made to defend a number of times.

None of this stops anyone from putting = pronunciation guides into the charter or eventual specs if people think = it=E2=80=99s worth it. I=E2=80=99m not the only voice here, and I=E2=80=99= ve said it doesn=E2=80=99t really matter to me because I don=E2=80=99t = think it will actually help. 

Therefore if it really is that = important to you, and the chairs and ADs agree to the charter text = change, then just do it. 

Can you help me understand what else = you=E2=80=99re looking for from me?

 =E2=80=94 Justin

On Jun 16, 2020, at 1:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I think precision in = communication matters, so yes, I think it matters. How will we pronounce = it in our in-person or virtual meetings? 

While I agree that we = need to anticipate people will mispronounce it, we can inform them of = the suggested pronunciation.

While putting the = pronunciation in the charter does not solve the issue, it is a = starting point. I have added the suggested pronunciation to = XAuth.

What is = your concern with putting it in the charter? Why would you not want to = minimize miscommunication?

FWIW: I think that guh-nap is a better pronunciation = choice as it makes it clear it is not spelled "NAP"



On Tue, Jun 16, 2020 at 10:44 AM Justin = Richer <jricher@mit.edu> wrote:
My concern on the pronunciation remains, and I = don=E2=80=99t think putting a pronunciation in the charter, which hardly = anyone will read again after a couple weeks from now, is going to = address it. That=E2=80=99s why I think we should just get used to = hearing it multiple ways, which you=E2=80=99ve agreed with. I personally = think it=E2=80=99s just a problem we=E2=80=99ll have to live with, and = that was one of the concerns I had with the name.

But really, does it matter? I don=E2=80=99= t think it does.

 =E2=80=94 Justin

On Jun = 16, 2020, at 1:08 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It = seems strange that you now call addressing the concerns you = raised "silly". 

While there is no confusion in written communication with = GNAP, there clearly will be in verbal communication. 

Starting off with a = suggested pronunciation looks to me to nip a significant amount of the = confusion in the bud.

We can deal with it now, or deal with it later, or it can be = a source of confusion and communication friction forever.

Why not just pick one = pronunciation and move on?

On Tue, Jun = 16, 2020 at 7:42 AM Justin Richer <jricher@mit.edu> wrote:
I don=E2=80=99t = believe we should add a proposed pronunciation to the charter. It seems = silly to focus on this so much.

 =E2=80=94 Justin

On Jun = 15, 2020, at 6:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

I = agree we should be prepared for both. Can we agree that we can be = consistent? Personally I don't care which we choose -- I only care that = we choose one.

I was working to address the concern that = you (Justin) had brought up:

This is ok, but it has a couple downsides. The pronunciation = of a hard =E2=80=9Cg=E2=80=9D or not is going to potentially be = confusing, as is the fact that it looks like it=E2=80=99s part of the = GNU project because of that.



On Mon, Jun = 15, 2020 at 1:56 PM Justin Richer <jricher@mit.edu> wrote:
I agree with Mike, in = that we should get used to answering to both.

In my head, it reads with a hard = =E2=80=9CG=E2=80=9D, at least partially because of the Smurfs video=E2=80=99= s legacy.

 =E2=80=94 Justin

On Jun = 15, 2020, at 3:38 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> = wrote:

I don=E2=80=99t care a lot one = way or the other.  My main point is that no matter what guidance we = give, many people are likely to pronounce the =E2=80=9CG=E2=80=9D.  = If we try to insist on it being silent, we should get used to the fact = that we=E2=80=99ll probably be hearing both pronunciations.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;       -- Mike
 
P.S.  Thanks for the Smurfs = link, Vittorio!
 
From: vittorio.bertocci@auth0.com <vittorio.bertocci@auth0.com> 
Sent: Monday, June 15, 2020 12:25 PM
To: 'Dick Hardt' <dick.hardt@gmail.com>; 'Peter Saint-Andre' <stpeter@mozilla.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; 'Jared Jennings' <jaredljennings@gmail.com>; 'Amanjeev Sethi' <aj@amanjeev.com>; 'Fabien Imbault' <fabien.imbault@gmail.com>; txauth@ietf.org
Subject: RE: [Txauth] GNAP = it is
 
Perhaps not to be taken too seriously, but here=E2=80=99s = prior art on GNAP pronunciation.
As = Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on the = Smurfs comic and was reprised in a cartoon episode as well.
You=E2=80=99ll find few examples around 3:30
 https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyou= tu.be&fbclid=3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WB= JgPbpQ
 
From: Txauth <txauth-bounces@ietf.org> On Behalf Of Dick Hardt
Sent: Monday, = June 15, 2020 12:18 PM
To: Peter Saint-Andre <stpeter@mozilla.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; Jared Jennings <jaredljennings@gmail.com>; Amanjeev Sethi <aj@amanjeev.com>; Fabien Imbault <fabien.imbault@gmail.com>; txauth@ietf.org
Subject: Re: [Txauth] GNAP = it is
 
Checking in again on pronunciation.
 
Mike: = do you still have concerns with a silent 'G'?
 
Anyone = else have concerns?
 
I'd = like to nip pronunciation confusion in the bud by having the recommended = pronunciation in the charter.
 
 
=E1=90=A7
 
On = Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre <stpeter@mozilla.com> wrote:
Looks like we were caught gnapping. ;-)

OK, that's the last of my snarky comments, let's get to = work!

Peter

On = 6/7/20 2:09 PM, Dick Hardt wrote:
> It is if you are = familiar with any of the GNU projects.
> 
> https://www.gnu.org/gnu/pronunciation.en.html
> 
> A quick = search on the internet has the "normal" pronunciation of "gnu"
> to have a silent 'g'.
> 
> https://www.howtopronounce.com/gnu
> https://dictionary.cambridge.org/us/pronunciation/english/gnu
> 
> 
> =E1=90=A7
> 
> On Sun, Jun 7, 2020 at 12:51 = PM Mike Jones <Michael.Jones@microsoft.com
> = <mailto:Michael.Jones@microsoft.com>> wrote:
> 
>  =    I had assumed Guh-Nap =E2=80=93 parallel to the = pronunciation of GNU.  I
>    =  think that=E2=80=99s the most natural way to read it.____
> 
>  =    __ __
> 
>    =             &n= bsp;           &nbs= p;            =             &n= bsp;      -- Mike____
> 
>    =  __ __
> 
>     *From:* Txauth <txauth-bounces@ietf.org
>    =  <mailto:txauth-bounces@ietf.org>> *On Behalf Of *Dick = Hardt
>     *Sent:* Sunday, June 7, 2020 = 12:45 PM
>     *To:* Amanjeev Sethi = <aj@amanjeev.com <mailto:aj@amanjeev.com>>
>    =  *Cc:* Fabien Imbault <fabien.imbault@gmail.com
>    =  <mailto:fabien.imbault@gmail.com>>; Jared Jennings
>     <jaredljennings@gmail.com <mailto:jaredljennings@gmail.com>>;
>  =    txauth@ietf.org <mailto:txauth@ietf.org>
>    =  *Subject:* Re: [Txauth] GNAP it is____
> 
>    =  __ __
> 
>     Anyone have objection to the = recommended pronunciation being the
>    =  English word "nap", as in "gnaw"?____
> 
>    =  __ __
> 
>     If not, then we could add a = pronunciation recommendation to the
>    =  Charter.____
> 
>     __ __
> 
>     =E1=90=A7____> 
>  =    __ __
> 
>     On Sat, = Jun 6, 2020 at 8:03 AM Amanjeev Sethi <aj@amanjeev.com
>    =  <mailto:aj@amanjeev.com>> wrote:____
> 
>        =  Vote for 'G' silent, as in 'lagnappe' ;)____
> 
>        =  __ __
> 
>         On Sat, Jun 6, 2020, at = 10:52 AM, Jared Jennings wrote:____
> 
>        =      I vote for G silent. For the reason it's most common = to
>            =  pronounce, especially for those not familiar with open
>             source = usages.____
> 
>            =  __ __
> 
>             On Sat, = Jun 6, 2020, 08:45 Dick Hardt <dick.hardt@gmail.com
>    =          <mailto:dick.hardt@gmail.com>> wrote:____
> 
>  =                The obvious = pronunciation choices are:____
> 
>        =          __ __
> 
>        =          nap (silent g as in gnaw)____
> 
>  =                __ __
> 
>  =                guh-nap (as in = the GNU OS
>            =      - https://www.gnu.org/gnu/pronunciation.en..html
>                =  <https://www.gnu.org/gnu/pronunciation.en.html>)____
> 
>  =                __ __
> 
>  =                gee-nap (as in = G-man - government man
>        =          - https://en.wikipedia.org/wiki/G-man)____
> 
>  =                __ __
> 
>  =                __ __
> 
>  =                __ __
> 
>  =                =E1=90=A7____> 
>  =                __ __
> 
>  =                On Sat, Jun 6, = 2020 at 1:34 AM Fabien Imbault
>      =            <fabien.imbault@gmail.com
>    =              <mailto:fabien.imbault@gmail.com>> wrote:____
> 
>  =                    So, = let's adopt a GNAP! We can even come with a
>  =                   =  little mascot (a bit like go gopher) as imagined
>                =      by http://elisegravel.com/blog/adopte-un-gnap/,
>                =      loved by little Canadians :-) ____
> 
>  =                   =  __ __
> 
>                =      Just to be sure, how do you recommand we = pronounce
>            =          it? ____
> 
>        =              __ __
> 
>  =                   =  Looking forward to the next steps too.. ____
> 
>  =                   =  __ __
> 
>                =      Thxs____
> 
>        =              Fabien____
> 
>  =                   =  --____
> 
>                =      Txauth mailing list____
> 
>        =              Txauth@ietf.org <mailto:Txauth@ietf.org>____
> 
>        =              https://www.ietf.org/mailman/listinfo/txauth____
> 
>  =                --____
> 
>  =                Txauth mailing = list____
> 
>                =  Txauth@ietf.org <mailto:Txauth@ietf.org>____
> 
>        =          https://www.ietf.org/mailman/listinfo/txauth____
> 
>  =            -- ____
> 
>  =            Txauth mailing list____
> 
>  =            Txauth@ietf.org <mailto: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=_AF6EAE6B-726B-4002-A865-F95E2E4C13A9-- From nobody Tue Jun 16 11:31:10 2020 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 380523A0CCA for ; Tue, 16 Jun 2020 11:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 NBPiiuIrI-ia for ; Tue, 16 Jun 2020 11:31:06 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54CBD3A0CBE for ; Tue, 16 Jun 2020 11:31:05 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id n24so24719512lji.10 for ; Tue, 16 Jun 2020 11:31:05 -0700 (PDT) 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=xTa73EqYXjI5JRi7NSaQwExTnlcvOgv8Rk1+RN3Dftc=; b=HiLH4y8v2vDKmIYUUHQhJjgVCObhpCKLl5jcerH6JzMyKd1pJyhs/mNGJk4YdE7Gvh 5J0Si3jmmtVhP2LUkEOQO3VbchynJFE3k2zkNZAtCQEO4J85W5nodIvfDjwDxhTHJxw/ nTixuOrBJZk7caeFM63m1gx35Bh3FenhP3wqnn0zA1pLB9o8X0JN6cXbnP74jfaJNpei KbJG67HYWVni0csjYiq8uZXIGkTHtIjCV5E/zlqPO9NsiVJCxtQufUThwiYsNfakbfHp EIk4y2xY9Fanv9C8NKM/rTbrgxBuBluxXOyxl0nAyEzQdcQiorMux+0hsYrgGJ3Eog4I xROQ== 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=xTa73EqYXjI5JRi7NSaQwExTnlcvOgv8Rk1+RN3Dftc=; b=eg7y3AhkmxdRzZSWHf4qgEKOZ8sujqV/4XFIBIQcKWYL9M4Z1lkPfBHS6FADQUBeeR 0T4M0b40cP2s1SpdfafGh6813Uz5iKWkfagZaNtLDTzGLiXs1HIz1Hj8PPlZxLBCyF57 Wcf/SDoLFC6WnZtfZPXbB0dXYJQmemfNFqEmKH5/t0TaqsY+zgEhKWb6mhMxHWrt94kF qlxIrihn/64MeiN5Zzzn7O2mAYTNsxOA2fPdky/SAyB6zG9YVSxP/Onro8o6HsDEjuBy kURdbVb5BXqcZqh6mL0pRqPXFh3Vy+yCw8yC8nZIXd0UcTK2qwXxFwk2gWNez4jIYOwy zPfA== X-Gm-Message-State: AOAM53196Cq2+UsbLcOUVQT9eR0u0jccLI7MmBwemNC+b3t3tjHHhl3D qrIhVk57rAc1f4NQIPAGiKSvYTwqpjlHULBfnyk= X-Google-Smtp-Source: ABdhPJw5BpW/hpKjWfeB7Su0VBvclUunjqbEN99qkmFoAOXgj5uMhsRkFpTE2Eg9ss7zwWGTRwvT37RCsupwYxqUgHo= X-Received: by 2002:a2e:9987:: with SMTP id w7mr1981121lji.215.1592332263157; Tue, 16 Jun 2020 11:31:03 -0700 (PDT) MIME-Version: 1.0 References: <5443710B-05DB-4C4D-AC4B-0D8D173E131B@mit.edu> <1B439ED3-E7DF-49B2-A064-4CB5CC3147A0@mit.edu> <8F9A2198-A6FB-4899-805B-E6AD9CE2BED2@mit.edu> In-Reply-To: From: Dick Hardt Date: Tue, 16 Jun 2020 11:30:37 -0700 Message-ID: To: Justin Richer Cc: Mike Jones , "vittorio.bertocci@auth0.com" , Peter Saint-Andre , Fabien Imbault , Jared Jennings , Amanjeev Sethi , "txauth@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e8f50505a837be7a" Archived-At: Subject: Re: [Txauth] GNAP it is 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, 16 Jun 2020 18:31:08 -0000 --000000000000e8f50505a837be7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You stated "I don=E2=80=99t believe we should add a proposed pronunciation = to the charter" Which sounds like a concern with putting it in the charter. If you now don't care about putting it in the charter, then we can end the discussion. I missed your preference for a hard G. Nice to know we are aligned on our opinions there! On Tue, Jun 16, 2020 at 11:23 AM Justin Richer wrote: > I=E2=80=99m really confused as to what the problem here is: > > I=E2=80=99ve said that I prefer it with a hard =E2=80=9Cg=E2=80=9D and wi= ll likely continue to > read it like that in my head. I have also stated that I don=E2=80=99t thi= nk putting > it in the charter will help people people =E2=80=9Cfix=E2=80=9D the pronu= nciation. This is > my opinion on the matter, which I have stated and now been made to defend= a > number of times. > > None of this stops anyone from putting pronunciation guides into the > charter or eventual specs if people think it=E2=80=99s worth it. I=E2=80= =99m not the only > voice here, and I=E2=80=99ve said it doesn=E2=80=99t really matter to me = because I don=E2=80=99t > think it will actually help. > > Therefore if it really is that important to you, and the chairs and ADs > agree to the charter text change, then just do it. > > Can you help me understand what else you=E2=80=99re looking for from me? > > =E2=80=94 Justin > > On Jun 16, 2020, at 1:52 PM, Dick Hardt wrote: > > I think precision in communication matters, so yes, I think it matters. > How will we pronounce it in our in-person or virtual meetings? > > While I agree that we need to anticipate people will mispronounce it, we > can inform them of the suggested pronunciation. > > While putting the pronunciation in the charter does not solve the issue, > it is a starting point. I have added the suggested pronunciation to XAuth= . > > What is your concern with putting it in the charter? Why would you not > want to minimize miscommunication? > > FWIW: I think that guh-nap is a better pronunciation choice as it makes i= t > clear it is not spelled "NAP" > > > > On Tue, Jun 16, 2020 at 10:44 AM Justin Richer wrote: > >> My concern on the pronunciation remains, and I don=E2=80=99t think putti= ng a >> pronunciation in the charter, which hardly anyone will read again after = a >> couple weeks from now, is going to address it. That=E2=80=99s why I thin= k we should >> just get used to hearing it multiple ways, which you=E2=80=99ve agreed w= ith. I >> personally think it=E2=80=99s just a problem we=E2=80=99ll have to live = with, and that was >> one of the concerns I had with the name. >> >> But really, does it matter? I don=E2=80=99t think it does. >> >> =E2=80=94 Justin >> >> On Jun 16, 2020, at 1:08 PM, Dick Hardt wrote: >> >> It seems strange that you now call addressing the concerns you raised >> "silly". >> >> While there is no confusion in written communication with GNAP, there >> clearly will be in verbal communication. >> >> Starting off with a suggested pronunciation looks to me to nip a >> significant amount of the confusion in the bud. >> >> We can deal with it now, or deal with it later, or it can be a source of >> confusion and communication friction forever. >> >> Why not just pick one pronunciation and move on? >> >> On Tue, Jun 16, 2020 at 7:42 AM Justin Richer wrote: >> >>> I don=E2=80=99t believe we should add a proposed pronunciation to the c= harter. >>> It seems silly to focus on this so much. >>> >>> =E2=80=94 Justin >>> >>> On Jun 15, 2020, at 6:14 PM, Dick Hardt wrote: >>> >>> I agree we should be prepared for both. Can we agree that we can be >>> consistent? Personally I don't care which we choose -- I only care that= we >>> choose one. >>> >>> I was working to address the concern that you (Justin) had brought up: >>> >>> This is ok, but it has a couple downsides. The pronunciation of a hard >>> =E2=80=9Cg=E2=80=9D or not is going to potentially be confusing, as is = the fact that it >>> looks like it=E2=80=99s part of the GNU project because of that. >>> >>> >>> >>> On Mon, Jun 15, 2020 at 1:56 PM Justin Richer wrote: >>> >>>> I agree with Mike, in that we should get used to answering to both. >>>> >>>> In my head, it reads with a hard =E2=80=9CG=E2=80=9D, at least partial= ly because of the >>>> Smurfs video=E2=80=99s legacy. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Jun 15, 2020, at 3:38 PM, Mike Jones < >>>> Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote: >>>> >>>> I don=E2=80=99t care a lot one way or the other. My main point is tha= t no >>>> matter what guidance we give, many people are likely to pronounce the = =E2=80=9CG=E2=80=9D. >>>> If we try to insist on it being silent, we should get used to the fact= that >>>> we=E2=80=99ll probably be hearing both pronunciations. >>>> >>>> -- Mike >>>> >>>> P.S. Thanks for the Smurfs link, Vittorio! >>>> >>>> *From:* vittorio.bertocci@auth0.com >>>> *Sent:* Monday, June 15, 2020 12:25 PM >>>> *To:* 'Dick Hardt' ; 'Peter Saint-Andre' < >>>> stpeter@mozilla.com> >>>> *Cc:* Mike Jones ; 'Jared Jennings' < >>>> jaredljennings@gmail.com>; 'Amanjeev Sethi' ; 'Fabien >>>> Imbault' ; txauth@ietf.org >>>> *Subject:* RE: [Txauth] GNAP it is >>>> >>>> Perhaps not to be taken too seriously, but here=E2=80=99s prior art on= GNAP >>>> pronunciation. >>>> As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D appeared on th= e Smurfs comic >>>> and was reprised in a cartoon episode as well. >>>> You=E2=80=99ll find few examples around 3:30 >>>> >>>> https://www.youtube.com/watch?v=3DGEl8IBv98vg&feature=3Dyoutu.be&fbcli= d=3DIwAR0GVfFeNl4M1OhHKE7FfyCqKTDJI960mU-ai8hLqMO8A_qzCS-WBJgPbpQ >>>> >>>> *From:* Txauth *On Behalf Of *Dick Hardt >>>> *Sent:* Monday, June 15, 2020 12:18 PM >>>> *To:* Peter Saint-Andre >>>> *Cc:* Mike Jones ; Jared Jennings < >>>> jaredljennings@gmail.com>; Amanjeev Sethi ; Fabien >>>> Imbault ; txauth@ietf.org >>>> *Subject:* Re: [Txauth] GNAP it is >>>> >>>> Checking in again on pronunciation. >>>> >>>> Mike: do you still have concerns with a silent 'G'? >>>> >>>> Anyone else have concerns? >>>> >>>> I'd like to nip pronunciation confusion in the bud by having the >>>> recommended pronunciation in the charter. >>>> >>>> >>>> =E1=90=A7 >>>> >>>> On Sun, Jun 7, 2020 at 1:23 PM Peter Saint-Andre >>>> wrote: >>>> >>>> Looks like we were caught gnapping. ;-) >>>> >>>> OK, that's the last of my snarky comments, let's get to work! >>>> >>>> Peter >>>> >>>> On 6/7/20 2:09 PM, Dick Hardt wrote: >>>> > It is if you are familiar with any of the GNU projects. >>>> > >>>> > https://www.gnu.org/gnu/pronunciation.en.html >>>> > >>>> > A quick search on the internet has the "normal" pronunciation of "gn= u" >>>> > to have a silent 'g'. >>>> > >>>> > https://www.howtopronounce.com/gnu >>>> > https://dictionary.cambridge.org/us/pronunciation/english/gnu >>>> > >>>> > >>>> > =E1=90=A7 >>>> > >>>> > On Sun, Jun 7, 2020 at 12:51 PM Mike Jones < >>>> Michael.Jones@microsoft.com >>>> > > wrote: >>>> > >>>> > I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of= GNU. I >>>> > think that=E2=80=99s the most natural way to read it.____ >>>> > >>>> > __ __ >>>> > >>>> > -- Mike__= __ >>>> > >>>> > __ __ >>>> > >>>> > *From:* Txauth >>> > > *On Behalf Of *Dick Hardt >>>> > *Sent:* Sunday, June 7, 2020 12:45 PM >>>> > *To:* Amanjeev Sethi > >>>> > *Cc:* Fabien Imbault >>> > >; Jared Jennings >>>> > >; >>>> > txauth@ietf.org >>>> > *Subject:* Re: [Txauth] GNAP it is____ >>>> > >>>> > __ __ >>>> > >>>> > Anyone have objection to the recommended pronunciation being the >>>> > English word "nap", as in "gnaw"?____ >>>> > >>>> > __ __ >>>> > >>>> > If not, then we could add a pronunciation recommendation to the >>>> > Charter.____ >>>> > >>>> > __ __ >>>> > >>>> > =E1=90=A7____ >>>> > >>>> > __ __ >>>> > >>>> > On Sat, Jun 6, 2020 at 8:03 AM Amanjeev Sethi >>> > > wrote:____ >>>> > >>>> > Vote for 'G' silent, as in 'lagnappe' ;)____ >>>> > >>>> > __ __ >>>> > >>>> > On Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____ >>>> > >>>> > I vote for G silent. For the reason it's most common to >>>> > pronounce, especially for those not familiar with open >>>> > source usages.____ >>>> > >>>> > __ __ >>>> > >>>> > On Sat, Jun 6, 2020, 08:45 Dick Hardt < >>>> dick.hardt@gmail.com >>>> > > wrote:____ >>>> > >>>> > The obvious pronunciation choices are:____ >>>> > >>>> > __ __ >>>> > >>>> > nap (silent g as in gnaw)____ >>>> > >>>> > __ __ >>>> > >>>> > guh-nap (as in the GNU OS >>>> > - https://www.gnu.org/gnu/pronunciation.en..html >>>> > )____ >>>> > >>>> > __ __ >>>> > >>>> > gee-nap (as in G-man - government man >>>> > - https://en.wikipedia.org/wiki/G-man)____ >>>> > >>>> > __ __ >>>> > >>>> > __ __ >>>> > >>>> > __ __ >>>> > >>>> > =E1=90=A7____ >>>> > >>>> > __ __ >>>> > >>>> > On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault >>>> > >>> > > wrote:____ >>>> > >>>> > So, let's adopt a GNAP! We can even come with a >>>> > little mascot (a bit like go gopher) as imagined >>>> > by http://elisegravel.com/blog/adopte-un-gnap/, >>>> > loved by little Canadians :-) ____ >>>> > >>>> > __ __ >>>> > >>>> > Just to be sure, how do you recommand we pronoun= ce >>>> > it? ____ >>>> > >>>> > __ __ >>>> > >>>> > Looking forward to the next steps too.. ____ >>>> > >>>> > __ __ >>>> > >>>> > Thxs____ >>>> > >>>> > Fabien____ >>>> > >>>> > --____ >>>> > >>>> > 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____ >>>> > >>>> > __ __ >>>> > >>>> > __ __ >>>> > >>>> > >>>> >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>>> >>>> >>>> >>> >> > --000000000000e8f50505a837be7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You stated "I don= =E2=80=99t believe we should add a proposed pronunciation to the charter&qu= ot;

Which sounds like a concern with p= utting it in the charter. If you now don't care about putting it in the= charter, then we can end the discussion.

I missed= your preference for a hard G. Nice to know we are aligned on our opinions = there!


On Tue, Jun 16, 2020 at 11:23 AM Justin Ri= cher <jricher@mit.edu> wrote:<= br>
I=E2=80=99m really confused as to what the p= roblem here is:

I=E2=80=99ve said that I prefer it with= a hard =E2=80=9Cg=E2=80=9D and will likely continue to read it like that i= n my head. I have also stated that I don=E2=80=99t think putting it in the = charter will help people people =E2=80=9Cfix=E2=80=9D the pronunciation. Th= is is my opinion on the matter, which I have stated and now been made to de= fend a number of times.

None of this stops anyone from p= utting pronunciation guides into the charter or eventual specs if people th= ink it=E2=80=99s worth it. I=E2=80=99m not the only voice here, and I=E2=80= =99ve said it doesn=E2=80=99t really matter to me because I don=E2=80=99t t= hink it will actually help.=C2=A0

Therefore if it = really is that important to you, and the chairs and ADs agree to the charte= r text change, then just do it.=C2=A0

Can you help= me understand what else you=E2=80=99re looking for from me?

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

On Jun 16, 2020, at 1:52 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

<= div>
I think precision in communication matters, so yes, I = think it matters. How will we pronounce it in our in-person or virtual meet= ings?=C2=A0

While I agree that we need to anticipate= people will mispronounce it, we can inform them of the suggested pronuncia= tion.

While=C2=A0putting the pronunciation=C2=A0in= the charter does not solve the issue, it is a starting point. I have added= the suggested pronunciation=C2=A0to XAuth.

What i= s your concern with putting it in the charter? Why would you not want to mi= nimize miscommunication?

FWIW: I think=C2=A0that g= uh-nap is a better pronunciation choice as it makes it clear it is not spel= led "NAP"



On Tue, Jun 16, 2020= at 10:44 AM Justin Richer <jricher@mit.edu> wrote:
My concern on the pronunciation remains, and I= don=E2=80=99t think putting a pronunciation in the charter, which hardly a= nyone will read again after a couple weeks from now, is going to address it= . That=E2=80=99s why I think we should just get used to hearing it multiple= ways, which you=E2=80=99ve agreed with. I personally think it=E2=80=99s ju= st a problem we=E2=80=99ll have to live with, and that was one of the conce= rns I had with the name.

But really, does it matter? I d= on=E2=80=99t think it does.

=C2=A0=E2=80=94 Justin

On Jun 16, 2020, at 1:08 PM, Dick= Hardt <dick.h= ardt@gmail.com> wrote:

It seems strange that you now call addressing the concerns you raised "silly".=C2= =A0

While there is no confusion in written communi= cation with GNAP, there clearly will be in verbal communication.=C2=A0

Starting off with a suggested pronunciation looks to m= e to nip a significant amount of the confusion in the bud.

We can deal with it now, or deal with it later, or it can be a sou= rce of confusion and communication friction forever.

Why not just pick one pronunciation and move on?

On Tue, Jun 16, 2020 at = 7:42 AM Justin Richer <jricher@mit.edu> wrote:
I don=E2=80=99t believe we should add a proposed pr= onunciation to the charter. It seems silly to focus on this so much.
=C2=A0=E2=80=94 Justin

<= div>On Jun 15, 2020, at 6:14 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I agree we should be prepared for b= oth. Can we agree that we can be consistent? Personally I don't care wh= ich we choose -- I only care that we choose one.

=
I was working=C2=A0to address the concern that you (= Justin) had brought up:

This is ok, but it has a couple downsides. The pronunciation of a hard =E2=80=9Cg=E2=80=9D or not i= s going to potentially be confusing, as is the fact that it looks like it= =E2=80=99s part of the GNU project because of that.



On Mon, Jun 15, 2020 at 1:56 PM= Justin Richer <jri= cher@mit.edu> wrote:
I agree with Mike, in that we should get used to answering= to both.

In my head, it reads with a hard =E2=80=9CG=E2= =80=9D, at least partially because of the Smurfs video=E2=80=99s legacy.

=C2=A0=E2=80=94 Justin

On Jun 15, 2020, at 3:38 PM, Mike Jones <Michael= .Jones=3D40microsoft.com@dmarc.ietf.org> wrote:

I don=E2=80=99t= care a lot one way or the other.=C2=A0 My main point is that no matter wha= t guidance we give, many people are likely to pronounce the =E2=80=9CG=E2= =80=9D.=C2=A0 If we try to insist on it being silent, we should get used to= the fact that we=E2=80=99ll probably be hearing both pronunciations.
= =C2=A0
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 -- Mike
=C2=A0
P.S.=C2=A0 Thanks for the Smurfs link, Vittori= o!
<= u>=C2=A0
From:=C2=A0vittorio.bertocci@auth0.com=C2=A0<vittorio.bertocci@auth0.com>=C2=A0
Sent:=C2=A0Monday, June 15, 2020 12:25 PM
To:=C2=A0'Dick Hardt' <dick.hardt@gmail.com>; 'Peter Saint-Andre' <stpeter@mozilla.com>
Cc:=C2= =A0Mike Jones <Michael.Jones= @microsoft.com>; 'Jared Jennings' <jaredljennings@gmail.com>; 'Amanjeev Sethi' <= aj@amanjeev.com>; 'Fabien Imbault' = <fabien.imbault@gmail.com>;=C2=A0txauth@ietf.org
Subject:<= /b>=C2=A0RE: [Txauth] GNAP it is
=C2=A0
Perhaps not to be taken too= seriously, but here=E2=80=99s prior art on GNAP pronunciation.
As Leif mentioned few mails ago, =E2=80=9CGNAP=E2=80=9D a= ppeared on the Smurfs comic and was reprised in a cartoon episode as well.<= u>
You=E2=80=99ll find few examples around 3:30
=C2=A0
From:<= span>=C2=A0Txauth <txauth-bounce= s@ietf.org>=C2=A0On Behalf Of=C2=A0= Dick Hardt
Sent:=C2=A0Monday, June 15, 2020 12:18 PM=
To:=C2=A0Peter Saint-Andre <stpeter@mozilla.com>
Cc:=C2=A0Mike J= ones <Michael.Jones@microsoft.com>; Jared Jennings <jaredljennings= @gmail.com>; Amanjeev Sethi <aj@amanjeev= .com>; Fabien Imbault <fabien.i= mbault@gmail.com>;=C2=A0txauth= @ietf.org
Subject:=C2=A0Re: [Txauth] GNAP it is<= u>
=C2=A0
Checking in again on pronunciation.
<= /u>=C2=A0
Mike: do you still have concerns= with a silent 'G'?
= =C2=A0
Anyone else have concerns?
=C2=A0
I'd like to nip pronunciation confusion in the bud by having the re= commended pronunciation=C2=A0in the charter.
=
=C2=A0
=C2=A0
=E1=90=A7
=
=C2=A0
On Sun, Jun 7, 2020= at 1:23 PM Peter Saint-Andre <stpeter@mozi= lla.com> wrote:
Looks= like we were caught gnapping. ;-)

OK, that's the last of my sna= rky comments, let's get to work!

Peter

On 6/7/20 2:09 PM,= Dick Hardt wrote:
> It is if you are familiar with any of the GNU pr= ojects.
>=C2=A0
>=C2=A0https://www.gnu.org/gnu/pronunciation.en.= html
>=C2=A0
> A quick search on the internet = has the "normal" pronunciation of "gnu"
> to have= a silent 'g'.
>=C2=A0
>=C2=A0https://www.howtopronounce.com/gnu
>=C2=A0https://dictionary.cambridge.org/us/pronunciation/english/= gnu
>=C2=A0
>=C2=A0
>= =C2=A0=E1=90=A7=
>=C2=A0
> On Sun, Jun 7, 2020 at 12:51 PM Mike Jo= nes <Michael.Jones@microsoft.com
> <mailto:Michael.Jones@m= icrosoft.com>> wrote:
>=C2=A0
>=C2=A0 = =C2=A0 =C2=A0I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation = of GNU.=C2=A0 I
>=C2=A0 =C2=A0 =C2=A0think that=E2=80=99s the most na= tural way to read it.____
>=C2=A0
>=C2=A0 =C2=A0 = =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 -- Mike____
>=C2=A0
>=C2=A0 = =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2= =A0*From:* Txauth <txauth-bounces@ietf.= org
>=C2=A0 =C2=A0 =C2=A0<mailto:txauth-bounces@ietf.org>> *On Behalf Of *Dick Hardt
>= =C2=A0 =C2=A0 =C2=A0*Sent:* Sunday, June 7, 2020 12:45 PM
>=C2=A0 =C2= =A0 =C2=A0*To:* Amanjeev Sethi <aj@amanjeev.com= =C2=A0<mailto:aj@amanjeev.com= >>
>=C2=A0 =C2=A0 =C2=A0*Cc:* Fabien Imbault <fabien.imbault@gmail.com
>=C2=A0 =C2=A0 = =C2=A0<mailto:fabien.imbault@gmail.com= >>; Jared Jennings
>=C2=A0 =C2=A0 =C2=A0<jaredljennings@gmail.com=C2=A0<mailt= o:jaredljennings@gmail.com>>;>=C2=A0 =C2=A0 =C2=A0txauth@ietf.org=C2=A0<mailto:txauth@ietf.org>>=C2=A0 =C2=A0 =C2=A0*Subject:* Re: [Txauth] GNAP it is____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0<= /span>
>=C2=A0 =C2=A0 =C2=A0Anyone have objection to the recommended = pronunciation=C2=A0being the
>=C2=A0 =C2=A0 =C2=A0English word "= nap", as in "gnaw"?____
>=C2=A0
>= =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2= =A0 =C2=A0If not, then we could add a pronunciation=C2=A0recommendation to = the
>=C2=A0 =C2=A0 =C2=A0Charter.____
>=C2=A0
&= gt;=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 = =C2=A0 =C2=A0=E1=90=A7= ____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
&g= t;=C2=A0
>=C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020 at 8:0= 3 AM Amanjeev Sethi <aj@amanjeev.com
>= ;=C2=A0 =C2=A0 =C2=A0<mailto:aj@amanjeev.com>> wrote:____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0Vote for 'G' silent, as in 'lagnappe' ;)____<= br>>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2= =A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0O= n Sat, Jun 6, 2020, at 10:52 AM, Jared Jennings wrote:____
>=C2= =A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I vote fo= r G silent. For the reason it's most common to
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pronounce, especially for those not familiar= with open
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0source us= ages.____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020, 08:45 Dick Hardt &l= t;dick.hardt@gmail.com
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dick.hardt@gmail.com>> wrote:____
>=C2=A0<= br>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The ob= vious pronunciation choices are:____
>=C2=A0
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
&g= t;=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0nap (silent g as in gnaw)____
>=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2= =A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0guh-nap (as in the GNU OS
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0https://www.gnu.org/gnu/pronunciation.en..html=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&= lt;https://www.gnu.org/gnu/= pronunciation.en.html>)____
>=C2=A0
>=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
><= span>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0gee-nap (as in G-man - government man
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0https://en.wikipedia.org/wiki/G-man)____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E1=90=A7____
>=C2=A0
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2= =A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0On Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<fabien.imbault@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:fabien.imbault@gmail.com>> wrote:____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0So, let's adopt a GNAP! We can even come with a
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0li= ttle mascot (a bit like go gopher) as imagined
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by=C2=A0http://elisegravel.com/blog/adopte-un-gna= p/,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0loved by little Canadians :-)=C2=A0____
>=C2= =A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Just to b= e sure, how do you recommand we pronounce
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it?=C2=A0____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lo= oking forward to the next steps too..=C2=A0____
>=C2=A0<= br>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thxs____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Fabien____
>=C2=A0
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--= ____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth@ietf.org=C2=A0<mailto:Txauth@ietf.org>_= ___
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/txauth____
&g= t;=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0--____
>=C2=A0
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list____
>= ;=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Txauth@ietf.org=C2=A0<mailto:Txauth@ietf.org>____
>= ;=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0https:/= /www.ietf.org/mailman/listinfo/txauth____
>=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--=C2=A0____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tx= auth mailing list____
>=C2=A0
>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth@ietf.org= =C2=A0<mailto:Txauth@ietf.org&= gt;____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0https:/= /www.ietf.org/mailman/listinfo/txauth____
>=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>= =C2=A0
>=C2=A0
--=C2= =A0
Txauth mailing list
Txauth@ie= tf.org
https://www.i= etf.org/mailman/listinfo/txauth




--000000000000e8f50505a837be7a-- From nobody Wed Jun 17 00:44:39 2020 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 0F2EA3A0F62 for ; Wed, 17 Jun 2020 00:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 vHrZUtRktCAb for ; Wed, 17 Jun 2020 00:44:36 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 CB1873A0F61 for ; Wed, 17 Jun 2020 00:44:36 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id i25so1721907iog.0 for ; Wed, 17 Jun 2020 00:44:36 -0700 (PDT) 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=2XwsEFxL4YsoUM4SEhinz4K/IgmtufoOoemQUfVn+Kw=; b=lv/Q04nvxShWDxbfkuMRjE5vdS0VEavEz6oJzrMqq80Qcd+adWvbKC9rmlF9cJsDPT +/NefJeo0DTpoikN5KhP7E08ImW6WIFaK+iq6xbezeIPhJwKUCg/mkwLVswGvOjXd5Wv EjRSbivG5vXxCZKi360X/8PxZAvzvb8vtwsUXLPn6HOQeH6Wo86YlGnj6DOEteyXPnSH 6KPT+uw4FJtAdD7Mlu0d9klfcktvJm7schoV3ngunG1lMXfXBcFCTK8VvPJUvQ5zQ6BJ c+0UXRorIynRQYNWoRAmdscI4kpei4aqf1DcOaH8XZwZwOJex7LsEPrsz6mLzaHvc+hK tYtQ== 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=2XwsEFxL4YsoUM4SEhinz4K/IgmtufoOoemQUfVn+Kw=; b=FXVG0BuAR/THX5FIcY8GrpY5EJ/cMe4bRAh+80YM08K08tZXDURQNj8sZd+VtZX1Y0 2mIPn729Y/Y8ZRBowf7KvIB28yJ+X8RPjotzIu7SxXTD3upDJauMFRzuLm6N+ox0W90K g9vmT8S+lQYuArsIWPB3dRuO/spyFFT7LZbvEO31GZIRXBDb2E6wcmZnMG+zlbaQJNbV KuBLCaG1tvgcee7U9Xjp4g5K0N8u0bzhNLyzTJ7dj4Guh3jKcFlJkhJiOcB+jQlyceoR S31uVnjinjx72J37puFttXLRsOBu87CDws/Uv3xNi2hM59IlRahfpqHUig2XPk9i7E1E rjxQ== X-Gm-Message-State: AOAM531BUvzqnq+bwJB5pgbakGU9g/6R6IY43bK2PkLLc3+FWiWZsnHU f4uWl9l0eMag8RXsbTvuoDMFtKMaG2mSFJPUAAyQvt6N X-Google-Smtp-Source: ABdhPJybILRBkwMvvj/h2g4YQjyy8kezOMGLQo9NaZhPzT5X/m/h4YArVQwTZYKJkEGIa9NjD9Qc4c67TPeA3ZzFV+Y= X-Received: by 2002:a5e:d90c:: with SMTP id n12mr7055776iop.144.1592379875911; Wed, 17 Jun 2020 00:44:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 17 Jun 2020 09:44:23 +0200 Message-ID: To: Dick Hardt Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000d9ebd205a842d4a8" Archived-At: Subject: Re: [Txauth] Additional implementation 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, 17 Jun 2020 07:44:39 -0000 --000000000000d9ebd205a842d4a8 Content-Type: text/plain; charset="UTF-8" Hi Dick, First I'd like to thank you for your work as co-chair, and I think it's great you will focus on the spec. Very much looking forward to it, there's ground to make something great. We are also working on a (partial) XAuth implementation, nothing is holding back apart from the time to do it. As soon as it's ready, we'll publish it with comments on our thoughts. We started with XYZ with a very basic starter, but Justin provided great comments that we're integrating (though not had too much time since last Friday to work on it). Will publish an update soon as it clarifies a lot the intended flow between the client and the AS. Basically, this initial work is intended as on-going microtests for people to play with (and better understand, beyond the very people that initially wrote the spec), and in time we'll work on a more solid GNAP implementation. For the rest of your comments, I just think we need a way forward, beyond both XYZ and XAuth. Either we start from one, and complement with the other; or we start from basic principles (although that may take longer...), I don't exactly know which path is best, but what's certain is that we need to get going. In all cases, I'm a great believer in having concrete implementations (as well as docs and compliance tests) to make sure people do understand and implement the spec as it must (or should, depending on which part). Just as for the pronunciation ("nap" is fine with me), people can still do whatever they want, but it's probably best to clarify our intent as much as we possibly can. Fabien On Tue, Jun 16, 2020 at 7:23 PM Dick Hardt wrote: > Hi Fabien > > Thanks for diving in and doing an implementation, and providing your > observations! ... comments inline ... > > > On Wed, Jun 10, 2020 at 1:56 AM Fabien Imbault > wrote: > >> Hi, >> >> Just to let you know that we started our own implementation of XYZ / >> XAuth (and future GNAP). >> It's just a first attempt of getting the concepts put into use quickly. >> We wanted to have a clear separation between the client and the AS, and >> demonstrate the retrieval of a protected resource to make it simpler for >> people to understand (even if there's nothing new there). >> >> Here's a quick MVP of xyz. Currently it's just implementing a basic flow, >> redirect with callback interaction. >> https://github.com/acertio/mvp_xyz >> (also working on the same for XAuth, because I sometimes get a bit lost >> in discussions between Justin and Dick, really need to get down to the >> drafts and write concrete examples to get a sense of what it means). >> This is very basic/naive but really gave us some better ideas on what to >> test/implement next, and contribute to the discussion. >> > > I'm keen to see an XAuth implementation. Please let me know if there is > anything underspecified that is holding you back. > > >> >> Note also that our target implementation will be in rust, and we are >> currently testing the approach on how to best implement it using a system >> oriented language (the fact that nodejs is very web oriented is abstracting >> some important aspects in our view). >> Our work is available under an MPLv2 licence, and we'll be happy to keep >> working on a separate and open reference implementation. >> >> As a last comment, I'd like to say that both XYZ and XAuth are great >> work, but it seems we're having 2 competing views, difficult to reconcile. >> I believe we can do better. >> >> Following our experiments, I would say: >> a) XYZ really makes a new experience possible, and the flow really fixes >> common issues in OAuth2. I believe this design idea is of great value, but >> the downside is that the written spec doesn't explicitly cover every aspect >> yet, so sometimes you have to guess or dig into Justin's implementation. >> But making sure we clarify that is also what the working group is there >> for, isn't it? >> Justin has even put his money where his mouth is by providing >> implementations and integrating with legacy software (an old implementation >> by mitre), so it's a very good sign that we won't end up with unnecessary >> breaking changes. >> > > In which areas did you need to dig into Justin's implementation? > > "XYZ really makes a new experience possible" -- do you think the new > experience was not possible in XAuth? > > >> >> b) XAuth's spec is written in a more consistent way, which reflects the >> fact that is closer to the previous art. There is no reference >> implementation (as far as I'm aware) and it comes with the potential >> downside of having a more opinionated/prescriptive stance and being much >> closer to legacy (for good or worse). >> > > In contrast to OAuth 2, which was a framework, our charter is to deliver a > protocol. IMHO being opinionated and prescriptive simplifies > interoperability or a protocol. > > >> >> However, I don't think the game of spotting the differences is that >> meaningful, and the charter should provide sufficient common ground to >> proceed forward despite or thanks to those differences. Otherwise we'll end >> up in surprisingly narrow considerations, such as I prefer X because it's >> reusing existing schemas. This is something we need to handle when time >> comes, but that's really an implementation detail and obviously nobody >> thinks we shouldn't reuse things that do work. >> > > The intention is not a game of spot the difference, but to discuss > different proposals for providing functionality. > > wrt. the schema discussion, one aspect is reusing an existing schema, > which is not an implementation detail, but must be specified. The more > significant point I was trying to make was that we should clearly define > how new schemas are added, and that the claims object should contain only > schema objects, which then contain how to request and respond to identity > claims. > > > >> >> A better way would be XYZ concepts challenged by XAuth's rigour (surely >> Dick and others would make sure of that) and several iterative >> implementations to make sure it does work as intended, as we propose to do. >> > > I am challenging the XYZ concepts with XAuth! Would be great for you to > provide feedback on the concepts I have challenged. Perhaps after you have > implemented XAuth you can provide an implementation perspective? > > /Dick > --000000000000d9ebd205a842d4a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dick,=C2=A0

First I= 'd like to thank you for your work as co-chair, and I think it's gr= eat you will focus on the spec. Very much looking forward to it, there'= s ground to make something great.

We are also work= ing on a (partial) XAuth implementation, nothing is holding back apart from= the time to do it. As soon as it's ready, we'll publish it with co= mments on our thoughts.
We started with XYZ with a very basic sta= rter, but Justin provided great comments that we're integrating (though= =C2=A0not had too much time since last Friday to work on it). Will publish = an update soon as it clarifies a lot the intended flow between the client a= nd the AS.=C2=A0
Basically, this initial work is intended as on-g= oing microtests for people to play with (and better understand, beyond the = very people that initially wrote the spec), and in time we'll work on a= more solid GNAP implementation.=C2=A0

For the res= t of your comments, I just think we need a way forward, beyond both XYZ and= XAuth. Either we start from one, and complement with the other; or we star= t from basic principles (although that may take longer...), I don't exa= ctly know which path is best, but what's certain is that we need to get= going.
In all cases, I'm a great believer in having concrete= implementations (as well as docs and compliance tests) to make sure people= do understand and implement the spec as it must (or should, depending on w= hich part).=C2=A0
Just as for the pronunciation ("nap" = is fine with me), people can still do whatever they want, but it's prob= ably best to clarify our intent as much as we possibly can.

<= /div>
Fabien=C2=A0

On Tue, Jun 16, 2020 at 7:23 PM Dick Hardt &l= t;dick.hardt@gmail.com> wrot= e:
Hi Fabien

Thanks f= or diving in and doing an implementation, and providing your observations! = ... comments inline ...


On Wed, Jun 10, 2020 at 1:56 AM= Fabien Imbault <fabien.imbault@gmail.com> wrote:
Hi,=C2=A0

<= div>
Just to let you know that we started our own implementation of XYZ= / XAuth (and future GNAP).
It's just a first attempt of gett= ing the concepts put into use quickly. We wanted to have a clear separation= between the client and the AS, and demonstrate the retrieval of a protecte= d resource to make it simpler for people to understand (even if there's= nothing new there).=C2=A0

Here's a quick MVP = of xyz.=20 Currently it's just implementing a basic flow, redirect with callback i= nteraction.
(also working on the same for XAuth, because I sometimes get a bit lost i= n discussions between Justin and Dick, really need to get down to the draft= s and write concrete examples to=C2=A0get a sense of what it=C2=A0means).= =C2=A0
This is very=C2=A0basic/naive but really gave us some bett= er ideas on what to test/implement next,=C2=A0and contribute to the discuss= ion.=C2=A0

I'm keen t= o see an XAuth implementation. Please let me know if there is anything unde= rspecified that is holding you back.
=C2=A0
=C2=A0
Note also that our target implementation will be in rust, and we are cur= rently testing the approach on how to best implement it using a system orie= nted language (the fact that nodejs is very web oriented is abstracting som= e important aspects in our view).
Our work is available under an MPLv2 licence, and we'll be happy to kee= p working on=C2=A0a separate and open reference implementation.=C2=A0 =C2= =A0

As a last comment, I'd like to say that bo= th XYZ and XAuth are great work, but it seems we're having 2 competing = views,=C2=A0difficult=C2=A0to reconcile. I believe we can do better.
<= div>
Following our experiments, I would say:=C2=A0
= a) XYZ really makes a new experience possible, and the flow really fixes co= mmon issues in OAuth2. I believe this design idea is of great value, but th= e downside is that the written spec doesn't explicitly cover=C2=A0every= aspect yet,=C2=A0so sometimes you have to guess or dig into Justin's i= mplementation. But making sure we clarify that is also what the working gro= up is there for, isn't it?=C2=A0
Justin has even put his mone= y where his mouth is by providing implementations and integrating with lega= cy software (an old implementation by mitre), so it's a very good sign = that we won't end up with unnecessary breaking changes.=C2=A0

In which areas did you need to dig= into Justin's implementation?

"XYZ reall= y makes a new experience possible" -- do you think the new experience = was not possible in XAuth?
=C2=A0
=C2=A0 =C2=A0=C2=A0
b) XAuth's spec is written in a more consistent way, which=C2=A0r= eflects the fact that is closer to the previous art. There is no reference = implementation (as far as I'm aware) and it comes with the potential do= wnside of having a more opinionated/prescriptive stance and being much clos= er to legacy (for good or worse).=C2=A0
=
In contrast to OAuth 2, which was a framework, our charter i= s to deliver a protocol. IMHO being opinionated and prescriptive simplifies= interoperability or a protocol.=C2=A0
=C2=A0

However, I don't think the game of spotting the differences is that = meaningful, and the charter should provide sufficient common ground to proc= eed forward despite or thanks to those differences. Otherwise we'll end= up in surprisingly narrow considerations, such as I prefer X because it= 9;s reusing existing schemas. This is something we need to handle when time= comes, but that's really an implementation detail and obviously nobody= thinks we shouldn't reuse things that do work.=C2=A0
=

The intention is not a game of spot the di= fference, but to discuss different proposals for providing functionality.

wrt. the schema discussion, one aspect is reusing a= n existing schema, which is not an implementation detail, but must be speci= fied. The more significant point I was trying to make was that we should cl= early define how new schemas are added, and that the claims object should c= ontain only schema objects, which then contain how to request and respond t= o identity claims.

=C2=A0

= A better way would be XYZ concepts challenged by XAuth's rigour (surely= Dick and others would make sure of that) and several iterative implementat= ions to make sure it=C2=A0does work as intended,=C2=A0as we propose to do.= =C2=A0

I am challenging t= he XYZ concepts with XAuth! Would be great for you to provide feedback on t= he concepts I have challenged. Perhaps after you have implemented XAuth you= can provide an implementation perspective?
=C2=A0
/Dic= k
--000000000000d9ebd205a842d4a8-- From nobody Wed Jun 17 03:47:41 2020 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 2D1A63A093C for ; Wed, 17 Jun 2020 03:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.097 X-Spam-Level: X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_OTHER_BAD_TLD=2, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 pGWAtq6DJ7xc for ; Wed, 17 Jun 2020 03:47:37 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 2D2303A093B for ; Wed, 17 Jun 2020 03:47:37 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id q8so2168471iow.7 for ; Wed, 17 Jun 2020 03:47:37 -0700 (PDT) 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=7oIWvDGZaKxfiJEj/c7MbXlPnoCW+h5X/sorwuNKNAQ=; b=jdf6frmpeNBuXJfoue+gB/9kTrKt2HFyP5E/N7OverslzRQd8RGLlvQ1BaWb746joi uFzb2ju80Im8bLvimDf1CWg2xLutaAwwn8YRb592HMyFS8ZwQqNJNcLGSeUx8e5+zshq gfAcxF5sC9lpy+L/b30H50jXl2cNBzLlj5EaL2VWWr6tF9tgIuhhaYTLdA5VhlXJm+0n BklQvdgbCYU9QIit0H4Jnh6F6Ee6omfuCq8KBLGoZltWzDxe2rNURSO8lzq9NeP3w1ah 5j8AddQfj773BoZ3lH4Ojj+sjhIhxU2mV490NDm7XbQtbfMQw+OWrfWOuCtseVlAZkvK 3+QA== 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=7oIWvDGZaKxfiJEj/c7MbXlPnoCW+h5X/sorwuNKNAQ=; b=YH/P/E2ENa8wmexAEmJhFkGTh8hUpA2TITANVjLap4oeEyoy5kSSS4vXUMJoSG4MGA QBgWHSBJbQmHFabtovJ306T6w1UMPtjsMan6rOPmDo+K+pmDlDobstweWSeH1q1N91jh 7juCPYiD7VVmeVg6p/4EEt3NvI5qdaJ7xWtKlC4BD8fqfz5VrUvAVI7zslb6MkFhw4BZ LxPxhi3CnVhd/GC9cJag+d01I2OtcgIw9wSfBDUeCKOXIscyLTCcNhhcQqbO5EoQg63m toC8padNomrSyV3LivPFP88KW54MQlm5P666Rocu2xaPliM0Jl0h4ZtRa5s/RK2CMuJk 8EQA== X-Gm-Message-State: AOAM532yMJh4ZQKF9Qvbno/dyrWpulDi9bLc3b/WL++08gHLrSeCZe5V Lr7VuFD052hM6tIUqyaI/8xC22Q9FSSLPUdnF4s= X-Google-Smtp-Source: ABdhPJxiujaaQoyPSrxZFQqdpjS8UZDVQJKno6mMMKg+JH+qXDUxOEK5dXhQS9hWI4hGdVEuTUP/vxGbpiSnHbg72QY= X-Received: by 2002:a05:6602:2408:: with SMTP id s8mr7665995ioa.78.1592390855357; Wed, 17 Jun 2020 03:47:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabien Imbault Date: Wed, 17 Jun 2020 12:47:22 +0200 Message-ID: To: Dick Hardt Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000046faeb05a8456334" Archived-At: Subject: Re: [Txauth] Additional implementation 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, 17 Jun 2020 10:47:40 -0000 --00000000000046faeb05a8456334 Content-Type: text/plain; charset="UTF-8" Hi again, Maybe to already provide a bit more feedback to the spec writers from the external implementations done so far: I'll take the example of the redirect flow. Related parts that I focus on the remaining of this message: https://oauth.xyz/interaction/ https://tools.ietf.org/html/draft-hardt-xauth-protocol-10#section-2.1 In XYZ: - the vocabulary should be updated to reflect the underlying GNAP idea ("grant") - the discovery mechanism is pretty nice https://oauth.xyz/discovery - the request is very simple, the client just needs to know the URL of the grant server. No clientID registration needed, which is good in my opinion (if we don't need it, we shouldn't include it). - the fields within request/responses are more examples than complete specs. The current version shows the intent, but for the external implementor it's not always straightforward. - the protocol is very clear on the verifications that should be done (pretty similar to a PKCE flow idea) -> that's really useful - the proposal provides some interesting insights in how tokens should be managed (see https://oauth.xyz/tokens, with a great deal of care on providing proofs) and more generally we see the proposal integrates/unifies the advances from many advanced schemes in OAuth (DPoP for instance), although there's still work to make things crystal clear - the authentication part has been discussed at https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz so there's no real difficulty here (but that needs to be integrated) in XAuth: - the vocabulary is quite nice (grant, etc.) - the proposal is much more detailed on all the required and possible fields within requests/responses -> so far, although it would require a detailed study, I haven't spent much time of that since it is fairly close to previous art, but it will be very useful - but sometimes I'm not sure it's 100% correct (or at least that it can be misleading): for instance 7. *Read Grant* The Client makes an HTTP GET request to the Grant URI, should be called "Request grant read' in my opinion, so that we understand it's actually a request. - it already integrates the authentication part, in line with OIDC - the suggested protocol is HTTP2, while I don't exactly see why that is required. HTTP1.1 (with TLS) would be just fine for the proposed scope, and generally speaking I don't think there's a strict requirement on the version (I'm working on HTTP3 too which would be a great fit as well, later on). Note that I haven't yet read the exchanges between Justin and Dick on the differences, as I wanted to make my own idea before refining based on their comments. So I'm probably missing some details as of now. But it gives the intuition on why I (as an external reader) think both proposals are complementary and why the concepts are not that different, except on relatively low details (which matter of course, but at a later stage). A common starting point seems really feasible -> there's really the possibility to merge the core ideas quickly, and iterate from there. I would really favor a very minimal spec on which we can build quickly (instead of 2 "competing" views, even if as I described earlier there's a lot of common ground, it requires a lot of effort to get a consistent picture, and we would benefit from reducing that complexity). Beyond what I said on the redirect, we could probably benefit from a more formal definition of the flows (a bit different between the 2 proposals), as proposed recently by Francis Pouatcha for instance (interact/decoupled/embedded flows, TBD). What I'm missing in both proposals (personal opinion): - I know that JSON is the usual format, but it would be really useful to complement the schemas with some JSON-LD descriptions as well. It would ease extensions and interoperability (by avoiding conflicting schemas), and could even provide a more generic way of representing verifiable presentations (challenge/nonce associated to a domain for instance). While most of this work on linked data has been done at W3C, it would add value to the current proposal so I think we should consider it. - from an extensibility point of view, I'm not sure it's very useful to list all possibilities. For instance, as of now, it wouldn't be possible to use the protocol for constrained devices, so there's no real value in saying that it could be extended with CoAP (then we need a separate document, that references the current GNAP rfc). What's more useful to know if the context of the current document, when you're implementing it, is what behaviour can really be extended in a fairly straightforward way, without changing anything in the core spec. For instance, what can I do with other types of tokens than JWT? Neither proposal is very clear as to how we would implement extensions in practice. - from an implementation perspective, it would make sense to decompose the flow between the Grant Server (GS) and the login/consent part (as done for instance by ory.sh). This way you would separate the concerns: on one side you have the HTTP flows (managed by the GS, which can be very optimized from a backend perspective), but you can delegate/customize the interaction UI to some agreed dedicated endpoint (typically a JS site). Maybe that's just a detail which doesn't have its place in the spec, but since it would change the flow, it might be important to consider, at least as a possibility/extension. Fabien On Wed, Jun 17, 2020 at 9:44 AM Fabien Imbault wrote: > Hi Dick, > > First I'd like to thank you for your work as co-chair, and I think it's > great you will focus on the spec. Very much looking forward to it, there's > ground to make something great. > > We are also working on a (partial) XAuth implementation, nothing is > holding back apart from the time to do it. As soon as it's ready, we'll > publish it with comments on our thoughts. > We started with XYZ with a very basic starter, but Justin provided great > comments that we're integrating (though not had too much time since last > Friday to work on it). Will publish an update soon as it clarifies a lot > the intended flow between the client and the AS. > Basically, this initial work is intended as on-going microtests for people > to play with (and better understand, beyond the very people that initially > wrote the spec), and in time we'll work on a more solid GNAP > implementation. > > For the rest of your comments, I just think we need a way forward, beyond > both XYZ and XAuth. Either we start from one, and complement with the > other; or we start from basic principles (although that may take > longer...), I don't exactly know which path is best, but what's certain is > that we need to get going. > In all cases, I'm a great believer in having concrete implementations (as > well as docs and compliance tests) to make sure people do understand and > implement the spec as it must (or should, depending on which part). > Just as for the pronunciation ("nap" is fine with me), people can still do > whatever they want, but it's probably best to clarify our intent as much as > we possibly can. > > Fabien > > On Tue, Jun 16, 2020 at 7:23 PM Dick Hardt wrote: > >> Hi Fabien >> >> Thanks for diving in and doing an implementation, and providing your >> observations! ... comments inline ... >> >> >> On Wed, Jun 10, 2020 at 1:56 AM Fabien Imbault >> wrote: >> >>> Hi, >>> >>> Just to let you know that we started our own implementation of XYZ / >>> XAuth (and future GNAP). >>> It's just a first attempt of getting the concepts put into use quickly. >>> We wanted to have a clear separation between the client and the AS, and >>> demonstrate the retrieval of a protected resource to make it simpler for >>> people to understand (even if there's nothing new there). >>> >>> Here's a quick MVP of xyz. Currently it's just implementing a basic >>> flow, redirect with callback interaction. >>> https://github.com/acertio/mvp_xyz >>> (also working on the same for XAuth, because I sometimes get a bit lost >>> in discussions between Justin and Dick, really need to get down to the >>> drafts and write concrete examples to get a sense of what it means). >>> This is very basic/naive but really gave us some better ideas on what to >>> test/implement next, and contribute to the discussion. >>> >> >> I'm keen to see an XAuth implementation. Please let me know if there is >> anything underspecified that is holding you back. >> >> >>> >>> Note also that our target implementation will be in rust, and we are >>> currently testing the approach on how to best implement it using a system >>> oriented language (the fact that nodejs is very web oriented is abstracting >>> some important aspects in our view). >>> Our work is available under an MPLv2 licence, and we'll be happy to keep >>> working on a separate and open reference implementation. >>> >>> As a last comment, I'd like to say that both XYZ and XAuth are great >>> work, but it seems we're having 2 competing views, difficult to reconcile. >>> I believe we can do better. >>> >>> Following our experiments, I would say: >>> a) XYZ really makes a new experience possible, and the flow really fixes >>> common issues in OAuth2. I believe this design idea is of great value, but >>> the downside is that the written spec doesn't explicitly cover every aspect >>> yet, so sometimes you have to guess or dig into Justin's implementation. >>> But making sure we clarify that is also what the working group is there >>> for, isn't it? >>> Justin has even put his money where his mouth is by providing >>> implementations and integrating with legacy software (an old implementation >>> by mitre), so it's a very good sign that we won't end up with unnecessary >>> breaking changes. >>> >> >> In which areas did you need to dig into Justin's implementation? >> >> "XYZ really makes a new experience possible" -- do you think the new >> experience was not possible in XAuth? >> >> >>> >>> b) XAuth's spec is written in a more consistent way, which reflects the >>> fact that is closer to the previous art. There is no reference >>> implementation (as far as I'm aware) and it comes with the potential >>> downside of having a more opinionated/prescriptive stance and being much >>> closer to legacy (for good or worse). >>> >> >> In contrast to OAuth 2, which was a framework, our charter is to deliver >> a protocol. IMHO being opinionated and prescriptive simplifies >> interoperability or a protocol. >> >> >>> >>> However, I don't think the game of spotting the differences is that >>> meaningful, and the charter should provide sufficient common ground to >>> proceed forward despite or thanks to those differences. Otherwise we'll end >>> up in surprisingly narrow considerations, such as I prefer X because it's >>> reusing existing schemas. This is something we need to handle when time >>> comes, but that's really an implementation detail and obviously nobody >>> thinks we shouldn't reuse things that do work. >>> >> >> The intention is not a game of spot the difference, but to discuss >> different proposals for providing functionality. >> >> wrt. the schema discussion, one aspect is reusing an existing schema, >> which is not an implementation detail, but must be specified. The more >> significant point I was trying to make was that we should clearly define >> how new schemas are added, and that the claims object should contain only >> schema objects, which then contain how to request and respond to identity >> claims. >> >> >> >>> >>> A better way would be XYZ concepts challenged by XAuth's rigour (surely >>> Dick and others would make sure of that) and several iterative >>> implementations to make sure it does work as intended, as we propose to do. >>> >> >> I am challenging the XYZ concepts with XAuth! Would be great for you to >> provide feedback on the concepts I have challenged. Perhaps after you have >> implemented XAuth you can provide an implementation perspective? >> >> /Dick >> > --00000000000046faeb05a8456334 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi again,=C2=A0

Maybe to already provid= e a bit more feedback to the spec writers from the external implementations= done so far: I'll take the example of the redirect flow.
Rel= ated parts that I focus on the remaining of this message:=C2=A0
<= a href=3D"https://oauth.xyz/interaction/">https://oauth.xyz/interaction/=C2=A0=C2=A0

In X= YZ:=C2=A0
- the vocabulary should be updated to reflect the under= lying GNAP idea ("grant")=C2=A0
- the discovery mechani= sm is pretty nice=C2=A0https://oau= th.xyz/discovery
- the request is very simple, the client jus= t needs to know the URL of the grant server. No clientID registration neede= d, which is good in=C2=A0my=C2=A0opinion (if we don't need it, we shoul= dn't include it).
-=C2=A0the fields within request/responses = are more examples than complete specs. The current version shows the intent= , but for the external implementor it's not always straightforward.
- the protocol is very clear on the verifications that should be don= e (pretty similar to a PKCE flow idea) -> that's really useful
=
- the proposal provides some interesting insights in how tokens should= be managed (see=C2=A0https://oauth.x= yz/tokens, with a great deal of care on providing proofs) and more gene= rally we see the proposal integrates/unifies the advances from many advance= d schemes in OAuth (DPoP for instance), although there's still work to = make things crystal clear

- the suggested protocol is HT= TP2, while I don't exactly see why that is required. HTTP1.1 (with=C2= =A0TLS) would be just fine for the proposed scope,=C2=A0and generally speak= ing I don't think there's a strict requirement on the version (I= 9;m working on HTTP3 too which would be a great fit as well, later on).

Note that I haven't yet read the exchanges betwee= n Justin and Dick on the differences, as I wanted to make my own idea befor= e refining based on their comments. So I'm probably missing some detail= s as of now.

But it gives the intuition on why= I (as an external reader) think both proposals are complementary and why t= he concepts are not that different, except on relatively low details (which= matter of course, but at a later stage). A common starting point seems rea= lly feasible -> there's really the possibility to merge the core ide= as quickly, and iterate from there. I would really favor a very minimal spe= c on which we can build quickly (instead of 2 "competing" views, = even if as I described earlier there's a lot of common ground,=C2=A0it = requires a lot of effort to=C2=A0get a consistent picture, and we would ben= efit from reducing that complexity).=C2=A0

Beyond = what I said on the redirect, we could probably benefit from a more formal d= efinition of the flows (a bit different between the 2 proposals), as propos= ed recently by Francis Pouatcha for instance (interact/decoupled/embedded f= lows, TBD).

What I'm missing in both propo= sals (personal opinion):=C2=A0

- I know that JSON = is the usual format, but it would be really useful to complement the schema= s with some JSON-LD descriptions as well. It would ease extensions and inte= roperability (by avoiding conflicting schemas), and could even provide a mo= re generic way of representing verifiable presentations (challenge/nonce as= sociated to a domain for instance). While most of this work on linked data = has been done at W3C, it would add value to the current proposal so=C2=A0I = think we should consider it.=C2=A0

- from an exten= sibility point of view, I'm not sure it's very useful to list all p= ossibilities. For instance, as of now, it wouldn't be possible to use t= he protocol for constrained devices, so there's no real value in saying= that it could be extended with CoAP (then we need a separate document, tha= t references the current GNAP rfc). What's more useful to know if the c= ontext of the current document, when you're implementing it, is what be= haviour can really be extended in a fairly straightforward way,=C2=A0withou= t changing anything in the core spec. For instance, what can I do with othe= r types of tokens than JWT? Neither proposal is very clear as to how we wou= ld implement extensions in practice.

- from an imp= lementation perspective, it would make sense to decompose the flow between = the Grant Server (GS) and the login/consent part (as done for instance by o= ry.sh). This way you would separate the concerns: on one side you have the = HTTP flows (managed by the GS, which can be very optimized from a backend p= erspective), but you can delegate/customize the interaction UI to some agre= ed dedicated endpoint (typically a JS site). Maybe that's just a detail= which doesn't have its place in the spec, but since it would change th= e flow, it might be important to consider,=C2=A0at least as a possibility/e= xtension.
=C2=A0
Fabien

On Wed, Jun 17, 2020 at 9:= 44 AM Fabien Imbault <fabien= .imbault@gmail.com> wrote:
Hi Dick,=C2=A0

=
First I'd like to thank you for your work as co-chair, and I= think it's great you will focus on the spec. Very much looking forward= to it, there's ground to make something great.

We are also working on a (partial) XAuth implementation, nothing is holdi= ng back apart from the time to do it. As soon as it's ready, we'll = publish it with comments on our thoughts.
We started with XYZ wit= h a very basic starter, but Justin provided great comments that we're i= ntegrating (though=C2=A0not had too much time since last Friday to work on = it). Will publish an update soon as it clarifies a lot the intended flow be= tween the client and the AS.=C2=A0
Basically, this initial work i= s intended as on-going microtests for people to play with (and better under= stand, beyond the very people that initially wrote the spec), and in time w= e'll work on a more solid GNAP implementation.=C2=A0

For the rest of your comments, I just think we need a way forward, b= eyond both XYZ and XAuth. Either we start from one, and complement with the= other; or we start from basic principles (although that may take longer...= ), I don't exactly know which path is best, but what's certain is t= hat we need to get going.
In all cases, I'm a great believer = in having concrete implementations (as well as docs and compliance tests) t= o make sure people do understand and implement the spec as it must (or shou= ld, depending on which part).=C2=A0
Just as for the pronunciation= ("nap" is fine with me), people can still do whatever they want,= but it's probably best to clarify our intent as much as we possibly ca= n.

Fabien=C2=A0

On Tue, Jun 16, 2020 at 7:23 = PM Dick Hardt <dick.hardt@gmail.com> wrote:
Hi = Fabien

Thanks for diving in and doing an implementation,= and providing your observations! ... comments inline ...


On Wed, Jun 10, 2020 at 1:56 AM Fabien Imbault <fabien.imbault@gmail.com> w= rote:
Hi,=C2=A0

Just to let you know that we sta= rted our own implementation of XYZ / XAuth (and future GNAP).
It&= #39;s just a first attempt of getting the concepts put into use quickly. We= wanted to have a clear separation between the client and the AS, and demon= strate the retrieval of a protected resource to make it simpler for people = to understand (even if there's nothing new there).=C2=A0

=
Here's a quick MVP of xyz.=20 Currently it's just implementing a basic flow, redirect with callback i= nteraction.
(also working on the same for XAuth, because I sometimes get a bit lost i= n discussions between Justin and Dick, really need to get down to the draft= s and write concrete examples to=C2=A0get a sense of what it=C2=A0means).= =C2=A0
This is very=C2=A0basic/naive but really gave us some bett= er ideas on what to test/implement next,=C2=A0and contribute to the discuss= ion.=C2=A0

I'm keen t= o see an XAuth implementation. Please let me know if there is anything unde= rspecified that is holding you back.
=C2=A0
=C2=A0
Note also that our target implementation will be in rust, and we are cur= rently testing the approach on how to best implement it using a system orie= nted language (the fact that nodejs is very web oriented is abstracting som= e important aspects in our view).
Our work is available under an MPLv2 licence, and we'll be happy to kee= p working on=C2=A0a separate and open reference implementation.=C2=A0 =C2= =A0

As a last comment, I'd like to say that bo= th XYZ and XAuth are great work, but it seems we're having 2 competing = views,=C2=A0difficult=C2=A0to reconcile. I believe we can do better.
<= div>
Following our experiments, I would say:=C2=A0
= a) XYZ really makes a new experience possible, and the flow really fixes co= mmon issues in OAuth2. I believe this design idea is of great value, but th= e downside is that the written spec doesn't explicitly cover=C2=A0every= aspect yet,=C2=A0so sometimes you have to guess or dig into Justin's i= mplementation. But making sure we clarify that is also what the working gro= up is there for, isn't it?=C2=A0
Justin has even put his mone= y where his mouth is by providing implementations and integrating with lega= cy software (an old implementation by mitre), so it's a very good sign = that we won't end up with unnecessary breaking changes.=C2=A0

In which areas did you need to dig= into Justin's implementation?

"XYZ reall= y makes a new experience possible" -- do you think the new experience = was not possible in XAuth?
=C2=A0
=C2=A0 =C2=A0=C2=A0
b) XAuth's spec is written in a more consistent way, which=C2=A0r= eflects the fact that is closer to the previous art. There is no reference = implementation (as far as I'm aware) and it comes with the potential do= wnside of having a more opinionated/prescriptive stance and being much clos= er to legacy (for good or worse).=C2=A0
=
In contrast to OAuth 2, which was a framework, our charter i= s to deliver a protocol. IMHO being opinionated and prescriptive simplifies= interoperability or a protocol.=C2=A0
=C2=A0

However, I don't think the game of spotting the differences is that = meaningful, and the charter should provide sufficient common ground to proc= eed forward despite or thanks to those differences. Otherwise we'll end= up in surprisingly narrow considerations, such as I prefer X because it= 9;s reusing existing schemas. This is something we need to handle when time= comes, but that's really an implementation detail and obviously nobody= thinks we shouldn't reuse things that do work.=C2=A0
=

The intention is not a game of spot the di= fference, but to discuss different proposals for providing functionality.

wrt. the schema discussion, one aspect is reusing a= n existing schema, which is not an implementation detail, but must be speci= fied. The more significant point I was trying to make was that we should cl= early define how new schemas are added, and that the claims object should c= ontain only schema objects, which then contain how to request and respond t= o identity claims.

=C2=A0

= A better way would be XYZ concepts challenged by XAuth's rigour (surely= Dick and others would make sure of that) and several iterative implementat= ions to make sure it=C2=A0does work as intended,=C2=A0as we propose to do.= =C2=A0

I am challenging t= he XYZ concepts with XAuth! Would be great for you to provide feedback on t= he concepts I have challenged. Perhaps after you have implemented XAuth you= can provide an implementation perspective?
=C2=A0
/Dic= k
--00000000000046faeb05a8456334-- From nobody Fri Jun 19 13:49:36 2020 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 26F613A0D06 for ; Fri, 19 Jun 2020 13:49:35 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 Xzdt6IBuvpab for ; Fri, 19 Jun 2020 13:49:33 -0700 (PDT) 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 520183A0D04 for ; Fri, 19 Jun 2020 13:49:33 -0700 (PDT) Received: from [192.168.1.14] (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 05JKnVhx030578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 19 Jun 2020 16:49:32 -0400 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_298E93A2-CE2C-4730-AF5C-C658BCBA8428" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> Date: Fri, 19 Jun 2020 16:49:31 -0400 To: txauth@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Txauth] Use Case: Directed Tokens 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, 19 Jun 2020 20:49:35 -0000 --Apple-Mail=_298E93A2-CE2C-4730-AF5C-C658BCBA8428 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One of the most important aspects to GNAP is going to be an ability to = address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do = without significant gymnastics. So with that, I wanted to bring back a = use case discussion that originally came up while we were talking about = the possibility of multiple access tokens, a few months back. I don=E2=80=99= t know if this concept has a regular term, so I=E2=80=99m going to call = it =E2=80=9Cdirected access tokens=E2=80=9D until we come up with = something better =E2=80=94 assuming we decide this is worthwhile.=20 In OAuth, the client=E2=80=99s supposed to always know where to send its = access token, and that knowledge is completely outside the protocol. = This makes a lot of sense for many (if not most) deployments, as OAuth = is really there to enable the API access that the client already knows = about. But we=E2=80=99re now in a world where a client could be talking to a = generic API that could be deployed at a number of different places, or a = cloud deployment that the AS wants to be able to dispatch the client to. = In order to do this, the AS needs to be able to communicate to the = client not only the token information (and any related key and = presentation information), but also a set of directions about what that = specific token is good for. This needs to be information outside the = token itself, since I believe we want to keep OAuth 2=E2=80=99s feature = of having the token be opaque to the client. Note: while we could map = all of these to different resource requests (in XYZ parlance) or scopes = (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t = enough to tell the client what to do with the token if it doesn=E2=80=99t = know already.=20 I know of two use cases already in the wild, where people are addressing = things using a mix of existing standards and some proprietary extensions = to address things within their silos. I=E2=80=99ll try to summarize = here, but I know the folks I=E2=80=99ve been talking to about this are = also on the list so hopefully they can chime in with more detail or any = corrections for something I=E2=80=99ve missed.=20 (1) The client knows what resource it=E2=80=99s calling, but it = doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in a = single security domain controlled by the AS, but the AS needs to decide = at runtime which specific instance of the API to direct the client to. = Since things are closely tied together, the client just needs to = effectively known an identifier for the RS, and this is currently = implemented as a URI. Once the client has that identifier, it knows how = to dispatch that token to that instance of the RS. (2) The client knows what kind of thing it=E2=80=99s looking for, but = doesn=E2=80=99t know who to ask it from. There=E2=80=99s a cross-domain = trust that=E2=80=99s bridged by the AS, and the AS needs to dispatch to = different resources depending on which user logged in (and possibly what = the user consented to). To make things more concrete, the client needs = to get driver=E2=80=99s license information, but doesn=E2=80=99t know = ahead of time which of the many state/provincial bureaus to call to get = that information because it doesn=E2=80=99t know yet who the user is. = The AS will know who the user is once they log in and approve things, = and so it can direct the client to call the correct RS. Since this is a = relatively simple API with a pre-negotiated cross-domain trust, the AS = returns a URL that the client presents the token at.=20 As far as I know, in both of these cases, the token is only good for = that API and not others =E2=80=94 but more on that later. A simple thing to do is just give back a URL with the access token, = which tells the client where to go.=20 { =E2=80=9Caccess_token=E2=80=9D: { =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80= =9D, =E2=80=9Cresource_uri=E2=80=9D: = =E2=80=9Chttps://example/foo" } } This is good for some kinds of APIs, but it=E2=80=99s limiting because = not all APIs dispatch based on the URL. An AS might want to divvy up = access tokens to an API that=E2=80=99s keyed on headers, or verbs, or = any number of things. And it doesn=E2=80=99t tell us immediately what to = do about non-exact URL matches. Can the client add query parameters and = still use the token? What about path segments? I like that this simple = approach addresses some common deployments that we already see today = (see above), it=E2=80=99s not universal. Do we want or need a universal = description language for directing where tokens go? This also opens up a whole new set of security questions. If the AS can = now direct the client where to use the token, could a rogue AS convince = a legit client to use a stolen token at the wrong RS? And what if the = client ignores the directions from the AS entirely? Could this open up = new avenues of attack? This is just the start, too. Things get even more complex if the client = can ask for multiple different kinds of resources at once. What if the = AS decides that the client needs a hyper-focused directed token for one = part of the API, but can use a general token for other stuff? Can it = signal that to the client? And if it can, does that mean that all = clients need to be prepared for that kind of thing? I firmly believe that whatever we build in GNAP, we need to optimize for = the overwhelmingly common use case of a client getting a single access = token to call APIs that it already knows about. Anything we add on top = of that really can=E2=80=99t get in the way of this, because if it does, = there=E2=80=99s very small chance that people will try to use this for = everyday things. Keep the simple things simple, and the complex things = possible, after all. I=E2=80=99m really looking forward to hearing what the community thinks = about these use cases, and hopefully the people I=E2=80=99ve chatted = with offline about this can join the conversation and provide more light = than I was able to. =E2=80=94 Justin= --Apple-Mail=_298E93A2-CE2C-4730-AF5C-C658BCBA8428 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 One = of the most important aspects to GNAP is going to be an ability to = address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do = without significant gymnastics. So with that, I wanted to bring back a = use case discussion that originally came up while we were talking about = the possibility of multiple access tokens, a few months back. I don=E2=80=99= t know if this concept has a regular term, so I=E2=80=99m going to call = it =E2=80=9Cdirected access tokens=E2=80=9D until we come up with = something better =E2=80=94 assuming we decide this is = worthwhile. 

In = OAuth, the client=E2=80=99s supposed to always know where to send its = access token, and that knowledge is completely outside the protocol. = This makes a lot of sense for many (if not most) deployments, as OAuth = is really there to enable the API access that the client already knows = about.

But = we=E2=80=99re now in a world where a client could be talking to a = generic API that could be deployed at a number of different places, or a = cloud deployment that the AS wants to be able to dispatch the client to. = In order to do this, the AS needs to be able to communicate to the = client not only the token information (and any related key and = presentation information), but also a set of directions about what that specific token is good = for. This needs to be information outside the token itself, since = I believe we want to keep OAuth 2=E2=80=99s feature of having the = token be opaque to the client. Note: while we could map all of these to = different resource requests (in XYZ parlance) or scopes (in OAuth 2 = legacy parlance) on the request side, this isn=E2=80=99t enough to tell = the client what to do with the token if it doesn=E2=80=99t = know already. 

I know of two use cases already in the wild, where people are = addressing things using a mix of existing standards and some proprietary = extensions to address things within their silos. I=E2=80=99ll try to = summarize here, but I know the folks I=E2=80=99ve been talking to about = this are also on the list so hopefully they can chime in with more = detail or any corrections for something I=E2=80=99ve = missed. 

(1) The client knows what resource it=E2=80=99s calling, but = it doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in a = single security domain controlled by the AS, but the AS needs to decide = at runtime which specific instance of the API to direct the client to. = Since things are closely tied together, the client just needs to = effectively known an identifier for the RS, and this is currently = implemented as a URI. Once the client has that identifier, it knows how = to dispatch that token to that instance of the RS.

(2) The client knows = what kind of thing it=E2=80=99s looking for, but doesn=E2=80=99t know = who to ask it from. There=E2=80=99s a cross-domain trust that=E2=80=99s = bridged by the AS, and the AS needs to dispatch to different resources = depending on which user logged in (and possibly what the user consented = to). To make things more concrete, the client needs to get driver=E2=80=99= s license information, but doesn=E2=80=99t know ahead of time which of = the many state/provincial bureaus to call to get that information = because it doesn=E2=80=99t know yet who the user is. The AS will know = who the user is once they log in and approve things, and so it can = direct the client to call the correct RS. Since this is a relatively = simple API with a pre-negotiated cross-domain trust, the AS returns a = URL that the client presents the token at. 

As far as I know, in both of these = cases, the token is only good for that API and not others =E2=80=94 but = more on that later.

A simple thing to do is just give back a URL with the access = token, which tells the client where to go. 

{
= =E2=80=9Caccess_token=E2=80=9D: {
= =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
= =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
= }
}

This is good for some kinds of APIs, = but it=E2=80=99s limiting because not all APIs dispatch based on the = URL. An AS might want to divvy up access tokens to an API that=E2=80=99s = keyed on headers, or verbs, or any number of things. And it doesn=E2=80=99= t tell us immediately what to do about non-exact URL matches. Can the = client add query parameters and still use the token? What about path = segments? I like that this simple approach addresses some common = deployments that we already see today (see above), it=E2=80=99s not = universal. Do we want or need a universal description language for = directing where tokens go?

This also opens up a whole new set of security questions. If = the AS can now direct the client where to use the token, could a rogue = AS convince a legit client to use a stolen token at the wrong RS? And = what if the client ignores the directions from the AS entirely? Could = this open up new avenues of attack?

This is just the start, too. Things get = even more complex if the client can ask for multiple different kinds of = resources at once. What if the AS decides that the client needs a = hyper-focused directed token for one part of the API, but can use a = general token for other stuff? Can it signal that to the client? And if = it can, does that mean that all clients need to be prepared for that = kind of thing?

I= firmly believe that whatever we build in GNAP, we need to optimize for = the overwhelmingly common use case of a client getting a single access = token to call APIs that it already knows about. Anything we add on top = of that really can=E2=80=99t get in the way of this, because if it does, = there=E2=80=99s very small chance that people will try to use this for = everyday things. Keep the simple things simple, and the complex things = possible, after all.

I=E2=80=99m really looking forward to hearing what the = community thinks about these use cases, and hopefully the people I=E2=80=99= ve chatted with offline about this can join the conversation and provide = more light than I was able to.

 =E2=80=94 = Justin
= --Apple-Mail=_298E93A2-CE2C-4730-AF5C-C658BCBA8428-- From nobody Fri Jun 19 13:58:27 2020 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 A23E93A0E81 for ; Fri, 19 Jun 2020 13:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 9G8V7Yi9ICG0 for ; Fri, 19 Jun 2020 13:58:12 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 166363A0EAD for ; Fri, 19 Jun 2020 13:58:11 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id v13so8336657otp.4 for ; Fri, 19 Jun 2020 13:58:11 -0700 (PDT) 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=+Um3wOeIrFnTc3dE/q6LfARS4HLp1xyjDHDt30Gl4/Y=; b=jHM7/kg0XbpZXWvdffugOSC+koOlLqQKTrQkVZsX2MiDaJIJ1C4YLL6LYxzLIJQMxg H+6GI4/riAlodEZeHk4mkbMobzltzFpeashnqksych9NhXYSbSTpzZMBoBdgCA1WE6bF naL9bLurkS0kitJjB0p6GN+KhhKu4fCvd7JtY9RRUK+p9/Vw2fqFNUvLlY3ZJCBLwmyJ oR5jdsQX3dtmgkLbB5q9uWRC0avHFc12qPG8vaJZ/fHC46k/PbL9HrOQRozxesOxBnRh a1eGwmaZw9lHtgTa5fx7fIH02KSbOcnijLH2dH2eoILAbnwC0j27vWf1ozVuvgvnDtKp BGyA== 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=+Um3wOeIrFnTc3dE/q6LfARS4HLp1xyjDHDt30Gl4/Y=; b=rb8JYBuRc8i8M3jJQeQ7IUH0fIMzJ7xqTBSFiRvd2tutZjAEBB37UtOLddoDsKqfTm pdCAGcdTvymOZjRu86xZqA+ApsOHT1ABJnBw1mO5r/ekJ0Dkc8vGHSvtAUjRKn1qu+Hd Shl489qqQzsoowpRF6Qz+Wq3rI6fgTqlTrT2ULh4UBqhRaJeyNpyDfCsxDwRNdJijBZX 6dxklkPeFXEn6/Y/6am/L+6oStjGNiMZlPbnRJDFIovGy9TDpiUoQrdvVoUzYD4qrtBG wofcRWU8AUCRktr8Oj7R89r0qN+8tj63hQ6UfN1Jbet8giheOu1wsyNYyubxzCE5lCwz 8M7A== X-Gm-Message-State: AOAM532di3pK0GsxUGDTEDRxqwsKyzjFVvvVjbMBjAXkQSkdurHHr0f/ /UOxiU9qU+Gu9kgeMLA1cZws/JlSf8sCCwuNCBg= X-Google-Smtp-Source: ABdhPJzoUIf8SI2ZgZGRkiJPknqg4LySDEOqEtC3KwiFP01MTPEQjAztu7lzLLtvxUTOFTNK+aIWelWOxykRxW83Xkg= X-Received: by 2002:a05:6830:837:: with SMTP id t23mr4425531ots.87.1592600291162; Fri, 19 Jun 2020 13:58:11 -0700 (PDT) MIME-Version: 1.0 References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> In-Reply-To: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> From: Tom Jones Date: Fri, 19 Jun 2020 13:57:59 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000009fbdc705a876261e" Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 19 Jun 2020 20:58:26 -0000 --0000000000009fbdc705a876261e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable here are some worked out samples of this: https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ Peace ..tom On Fri, Jun 19, 2020 at 1:49 PM Justin Richer wrote: > One of the most important aspects to GNAP is going to be an ability to > address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do w= ithout significant > gymnastics. So with that, I wanted to bring back a use case discussion th= at > originally came up while we were talking about the possibility of multipl= e > access tokens, a few months back. I don=E2=80=99t know if this concept ha= s a > regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access to= kens=E2=80=9D until we > come up with something better =E2=80=94 assuming we decide this is worthw= hile. > > In OAuth, the client=E2=80=99s supposed to always know where to send its = access > token, and that knowledge is completely outside the protocol. This makes = a > lot of sense for many (if not most) deployments, as OAuth is really there > to enable the API access that the client already knows about. > > But we=E2=80=99re now in a world where a client could be talking to a gen= eric API > that could be deployed at a number of different places, or a cloud > deployment that the AS wants to be able to dispatch the client to. In ord= er > to do this, the AS needs to be able to communicate to the client not only > the token information (and any related key and presentation information), > but also a set of *directions* about what that specific token is good > for. This needs to be information outside the token itself, since I belie= ve > we want to keep OAuth 2=E2=80=99s feature of having the token be opaque t= o the > client. Note: while we could map all of these to different resource > requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the > request side, this isn=E2=80=99t enough to tell the client what to do wit= h the > token *if it doesn=E2=80=99t know already*. > > I know of two use cases already in the wild, where people are addressing > things using a mix of existing standards and some proprietary extensions = to > address things within their silos. I=E2=80=99ll try to summarize here, bu= t I know > the folks I=E2=80=99ve been talking to about this are also on the list so= hopefully > they can chime in with more detail or any corrections for something I=E2= =80=99ve > missed. > > (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2= =80=99t know where > it=E2=80=99s hosted. Everything is in a single security domain controlled= by the > AS, but the AS needs to decide at runtime which specific instance of the > API to direct the client to. Since things are closely tied together, the > client just needs to effectively known an identifier for the RS, and this > is currently implemented as a URI. Once the client has that identifier, i= t > knows how to dispatch that token to that instance of the RS. > > (2) The client knows what kind of thing it=E2=80=99s looking for, but doe= sn=E2=80=99t know > who to ask it from. There=E2=80=99s a cross-domain trust that=E2=80=99s b= ridged by the AS, > and the AS needs to dispatch to different resources depending on which us= er > logged in (and possibly what the user consented to). To make things more > concrete, the client needs to get driver=E2=80=99s license information, b= ut doesn=E2=80=99t > know ahead of time which of the many state/provincial bureaus to call to > get that information because it doesn=E2=80=99t know yet who the user is.= The AS > will know who the user is once they log in and approve things, and so it > can direct the client to call the correct RS. Since this is a relatively > simple API with a pre-negotiated cross-domain trust, the AS returns a URL > that the client presents the token at. > > As far as I know, in both of these cases, the token is only good for that > API and not others =E2=80=94 but more on that later. > > A simple thing to do is just give back a URL with the access token, which > tells the client where to go. > > { > =E2=80=9Caccess_token=E2=80=9D: { > =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D, > =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo" > } > } > > This is good for some kinds of APIs, but it=E2=80=99s limiting because no= t all > APIs dispatch based on the URL. An AS might want to divvy up access token= s > to an API that=E2=80=99s keyed on headers, or verbs, or any number of thi= ngs. And > it doesn=E2=80=99t tell us immediately what to do about non-exact URL mat= ches. Can > the client add query parameters and still use the token? What about path > segments? I like that this simple approach addresses some common > deployments that we already see today (see above), it=E2=80=99s not unive= rsal. Do > we want or need a universal description language for directing where toke= ns > go? > > This also opens up a whole new set of security questions. If the AS can > now direct the client where to use the token, could a rogue AS convince a > legit client to use a stolen token at the wrong RS? And what if the clien= t > ignores the directions from the AS entirely? Could this open up new avenu= es > of attack? > > This is just the start, too. Things get even more complex if the client > can ask for multiple different kinds of resources at once. What if the AS > decides that the client needs a hyper-focused directed token for one part > of the API, but can use a general token for other stuff? Can it signal th= at > to the client? And if it can, does that mean that all clients need to be > prepared for that kind of thing? > > I firmly believe that whatever we build in GNAP, we need to optimize for > the overwhelmingly common use case of a client getting a single access > token to call APIs that it already knows about. Anything we add on top of > that really can=E2=80=99t get in the way of this, because if it does, the= re=E2=80=99s very > small chance that people will try to use this for everyday things. Keep t= he > simple things simple, and the complex things possible, after all. > > I=E2=80=99m really looking forward to hearing what the community thinks a= bout > these use cases, and hopefully the people I=E2=80=99ve chatted with offli= ne about > this can join the conversation and provide more light than I was able to. > > =E2=80=94 Justin > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000009fbdc705a876261e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
here are some worked out samples of this:
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
Peace ..tom


On Fri, Jun 19, 2020 at 1:49 PM Justin Richer <jricher@mit.edu> wrote:
One of the most important aspects to GNAP is going to be an abil= ity to address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t= do without significant gymnastics. So with that, I wanted to bring back a = use case discussion that originally came up while we were talking about the= possibility of multiple access tokens, a few months back. I don=E2=80=99t = know if this concept has a regular term, so I=E2=80=99m going to call it = =E2=80=9Cdirected access tokens=E2=80=9D until we come up with something be= tter =E2=80=94 assuming we decide this is worthwhile.=C2=A0

<= div>In OAuth, the client=E2=80=99s supposed to always know where to send it= s access token, and that knowledge is completely outside the protocol. This= makes a lot of sense for many (if not most) deployments, as OAuth is reall= y there to enable the API access that the client already knows about.
=

But we=E2=80=99re now in a world where a client could b= e talking to a generic API that could be deployed at a number of different = places, or a cloud deployment that the AS wants to be able to dispatch the = client to. In order to do this, the AS needs to be able to communicate to t= he client not only the token information (and any related key and presentat= ion information), but also a set of directions=C2=A0about what that = specific token is good for. This needs to be information outside the token = itself, since I=C2=A0believe we want to keep OAuth 2=E2=80=99s feature of h= aving the token be opaque to the client. Note: while we could map all of th= ese to different resource requests (in XYZ parlance) or scopes (in OAuth 2 = legacy parlance) on the request side, this isn=E2=80=99t enough to tell the= client what to do with the token if it doesn=E2=80=99t know already= .=C2=A0

I know of two use cases already in the wil= d, where people are addressing things using a mix of existing standards and= some proprietary extensions to address things within their silos. I=E2=80= =99ll try to summarize here, but I know the folks I=E2=80=99ve been talking= to about this are also on the list so hopefully they can chime in with mor= e detail or any corrections for something I=E2=80=99ve missed.=C2=A0
<= div>
(1) The client knows what resource it=E2=80=99s calling,= but it doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in a = single security domain controlled by the AS, but the AS needs to decide at = runtime which specific instance of the API to direct the client to. Since t= hings are closely tied together, the client just needs to effectively known= an identifier for the RS, and this is currently implemented as a URI. Once= the client has that identifier, it knows how to dispatch that token to tha= t instance of the RS.

(2) The client knows what ki= nd of thing it=E2=80=99s looking for, but doesn=E2=80=99t know who to ask i= t from. There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the = AS, and the AS needs to dispatch to different resources depending on which = user logged in (and possibly what the user consented to). To make things mo= re concrete, the client needs to get driver=E2=80=99s license information, = but doesn=E2=80=99t know ahead of time which of the many state/provincial b= ureaus to call to get that information because it doesn=E2=80=99t know yet = who the user is. The AS will know who the user is once they log in and appr= ove things, and so it can direct the client to call the correct RS. Since t= his is a relatively simple API with a pre-negotiated cross-domain trust, th= e AS returns a URL that the client presents the token at.=C2=A0
<= br>
As far as I know, in both of these cases, the token is only g= ood for that API and not others =E2=80=94 but more on that later.

A simple thing to do is just give back a URL with the acces= s token, which tells the client where to go.=C2=A0

{
=E2=80=9Caccess_token=E2=80=9D: {
=E2=80=9Cvalue=E2=80=9D: =E2= =80=9C87yui843yfer=E2=80=9D,
=E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
}
}

This is good for some kinds = of APIs, but it=E2=80=99s limiting because not all APIs dispatch based on t= he URL. An AS might want to divvy up access tokens to an API that=E2=80=99s= keyed on headers, or verbs, or any number of things. And it doesn=E2=80=99= t tell us immediately what to do about non-exact URL matches. Can the clien= t add query parameters and still use the token? What about path segments? I= like that this simple approach addresses some common deployments that we a= lready see today (see above), it=E2=80=99s not universal. Do we want or nee= d a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. I= f the AS can now direct the client where to use the token, could a rogue AS= convince a legit client to use a stolen token at the wrong RS? And what if= the client ignores the directions from the AS entirely? Could this open up= new avenues of attack?

This is just the start, to= o. Things get even more complex if the client can ask for multiple differen= t kinds of resources at once. What if the AS decides that the client needs = a hyper-focused directed token for one part of the API, but can use a gener= al token for other stuff? Can it signal that to the client? And if it can, = does that mean that all clients need to be prepared for that kind of thing?=

I firmly believe that whatever we build in GNAP, = we need to optimize for the overwhelmingly common use case of a client gett= ing a single access token to call APIs that it already knows about. Anythin= g we add on top of that really can=E2=80=99t get in the way of this, becaus= e if it does, there=E2=80=99s very small chance that people will try to use= this for everyday things. Keep the simple things simple, and the complex t= hings possible, after all.

I=E2=80=99m really look= ing forward to hearing what the community thinks about these use cases, and= hopefully the people I=E2=80=99ve chatted with offline about this can join= the conversation and provide more light than I was able to.

=
=C2=A0=E2=80=94 Justin
--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000009fbdc705a876261e-- From nobody Mon Jun 22 00:55:38 2020 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 158D53A0970 for ; Mon, 22 Jun 2020 00:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 Qq_T9zQERo3X for ; Mon, 22 Jun 2020 00:55:35 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDAA3A0B8E for ; Mon, 22 Jun 2020 00:55:34 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d69 with ME id u7vX220094FMSmm037vXz0; Mon, 22 Jun 2020 09:55:32 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 22 Jun 2020 09:55:32 +0200 X-ME-IP: 86.238.65.197 To: txauth@ietf.org References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> From: Denis Message-ID: <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> Date: Mon, 22 Jun 2020 09:55:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> Content-Type: multipart/alternative; boundary="------------3E9B39D26B3A0FB4674D879D" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 22 Jun 2020 07:55:37 -0000 This is a multi-part message in MIME format. --------------3E9B39D26B3A0FB4674D879D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Justin, A few comments between the lines. > One of the most important aspects to GNAP is going to be an ability to > address things that OAuth 2 can’t, or at least can’t do without > significant gymnastics. So with that, I wanted to bring back a use > case discussion that originally came up while we were talking about > the possibility of multiple access tokens, a few months back. I don’t > know if this concept has a regular term, so I’m going to call it > “directed access tokens” until we come up with something better — > assuming we decide this is worthwhile. I don't understand what may mean "directed access tokens” but I understand what means "multiple access tokens". When speaking of "multiple access tokens", these access tokens may come from one or more ASs. > In OAuth, the client’s supposed to always know where to send its > access token, and that knowledge is completely outside the protocol. > This makes a lot of sense for many (if not most) deployments, as OAuth > is really there to enable the API access that the client already knows > about. > > But we’re now in a world where a client could be talking to a generic > API that could be deployed at a number of different places, or a cloud > deployment that the AS wants to be able to dispatch the client to. As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother". OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them. > In order to do this, the AS needs to be able to communicate to the > client not only the token information (and any related key and > presentation information), but also a set of /directions/ about what > that specific token is good for. This needs to be information outside > the token itself, since I believe we want to keep OAuth 2’s feature of > having the token be opaque to the client. Note: while we could map all > of these to different resource requests (in XYZ parlance) or scopes > (in OAuth 2 legacy parlance) on the request side, this isn’t enough to > tell the client what to do with the token /if it doesn’t know already/. > > I know of two use cases already in the wild, where people are > addressing things using a mix of existing standards and some > proprietary extensions to address things within their silos. I’ll try > to summarize here, but I know the folks I’ve been talking to about > this are also on the list so hopefully they can chime in with more > detail or any corrections for something I’ve missed. > > (1) The client knows what resource it’s calling, but it doesn’t know > where it’s hosted. Everything is in a single security domain > controlled by the AS, Speaking of "multiple access tokens" is in contradiction with single security domain "controlled" by an AS. A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be the "primary issuer" of a university diploma. It should not be either a "secondary issuer", because the bank does not "/need to know"/ what are the diplomas of the user. > but the AS needs to decide at runtime which specific instance of the > API to direct the client to. Since things are closely tied together, > the client just needs to effectively known an identifier for the RS, > and this is currently implemented as a URI. Once the client has that > identifier, it knows how to dispatch that token to that instance of > the RS. There is no good reason why the AS should be involved in that step. OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable. GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes. An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it. A client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it. > (2) The client knows what kind of thing it’s looking for, but doesn’t > know who to ask it from. Once again, the client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it. > There’s a cross-domain trust that’s bridged by the AS, and the AS > needs to dispatch to different resources depending on which user > logged in (and possibly what the user consented to). To make things > more concrete, the client needs to get driver’s license information, > but doesn’t know ahead of time which of the many state/provincial > bureaus to call to get that information because it doesn’t know yet > who the user is. When a user has a driving license, he knows its issuer. The user can then provide some hint to the client. > The AS will know who the user is once they log in and approve things, > and so it can direct the client to call the correct RS. Since this is > a relatively simple API with a pre-negotiated cross-domain trust, the > AS returns a URL that the client presents the token at.  A single AS should not be aware of all the attributes a user has. > > As far as I know, in both of these cases, the token is only good for > that API and not others — but more on that later. > > A simple thing to do is just give back a URL with the access token, > which tells the client where to go. > > { > “access_token”: { > “value”: “87yui843yfer”, > “resource_uri”: “https://example/foo" > } > } > > This is good for some kinds of APIs, but it’s limiting because not all > APIs dispatch based on the URL. An AS might want to divvy up access > tokens to an API that’s keyed on headers, or verbs, or any number of > things. And it doesn’t tell us immediately what to do about non-exact > URL matches. Can the client add query parameters and still use the > token? What about path segments? I like that this simple approach > addresses some common deployments that we already see today (see > above), it’s not universal. Do we want or need a universal description > language for directing where tokens go? > > This also opens up a whole new set of security questions. If the AS > can now direct the client where to use the token, could a rogue AS > convince a legit client to use a stolen token at the wrong RS? And > what if the client ignores the directions from the AS entirely? Could > this open up new avenues of attack? > > This is just the start, too. Things get even more complex if the > client can ask for multiple different kinds of resources at once. What > if the AS decides that the client needs a hyper-focused directed token > for one part of the API, but can use a general token for other stuff? > Can it signal that to the client? And if it can, does that mean that > all clients need to be prepared for that kind of thing? > > I firmly believe that whatever we build in GNAP, we need to optimize > for the overwhelmingly common use case of a client getting a single > access token to call APIs that it already knows about. Anything we add > on top of that really can’t get in the way of this, because if it > does, there’s very small chance that people will try to use this for > everyday things. Keep the simple things simple, and the complex things > possible, after all. > > I’m really looking forward to hearing what the community thinks about > these use cases, and hopefully the people I’ve chatted with offline > about this can join the conversation and provide more light than I was > able to. The two use cases which are considered above are: (1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted. (2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from. That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution. Denis > >  — Justin > --------------3E9B39D26B3A0FB4674D879D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hello Justin,

A few comments between the lines.

One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can’t, or at least can’t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don’t know if this concept has a regular term, so I’m going to call it “directed access tokens” until we come up with something better — assuming we decide this is worthwhile.

I don't understand what may mean "directed access tokens” but I understand what means "multiple access tokens".
When speaking of "multiple access tokens", these access tokens may come from one or more ASs.

In OAuth, the client’s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we’re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of directions about what that specific token is good for. This needs to be information outside the token itself, since I believe we want to keep OAuth 2’s feature of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn’t enough to tell the client what to do with the token if it doesn’t know already. 

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I’ll try to summarize here, but I know the folks I’ve been talking to about this are also on the list so hopefully they can chime in with more detail or any corrections for something I’ve missed. 

(1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted. Everything is in a single security domain controlled by the AS,

Speaking of "multiple access tokens" is in contradiction with single security domain "controlled" by an AS.
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be
the "primary issuer" of a university diploma. It should not be either a "secondary issuer", because
the bank does not "need to know" what are the diplomas of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved in that step.
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it.

(2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from.

Once again, the client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it.

There’s a cross-domain trust that’s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver’s license information, but doesn’t know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn’t know yet who the user is.

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at.

 A single AS should not be aware of all the attributes a user has.


As far as I know, in both of these cases, the token is only good for that API and not others — but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go. 

{
“access_token”: {
“value”: “87yui843yfer”,
“resource_uri”: “https://example/foo"
}
}

This is good for some kinds of APIs, but it’s limiting because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that’s keyed on headers, or verbs, or any number of things. And it doesn’t tell us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it’s not universal. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can’t get in the way of this, because if it does, there’s very small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I’m really looking forward to hearing what the community thinks about these use cases, and hopefully the people I’ve chatted with offline about this can join the conversation and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted.
(2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from.

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Denis


 — Justin


--------------3E9B39D26B3A0FB4674D879D-- From nobody Mon Jun 22 06:37:27 2020 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 514463A0D14 for ; Mon, 22 Jun 2020 06:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 756_rL8kKBzI for ; Mon, 22 Jun 2020 06:37:22 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 ABA1B3A0D12 for ; Mon, 22 Jun 2020 06:37:22 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id g7so13010507oti.13 for ; Mon, 22 Jun 2020 06:37:22 -0700 (PDT) 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=I1s6/jfbqcw+oS21rXpZNxQA67umujFYugmOACn2Jug=; b=AQ/4khM58xa9v9wELfNEDDHsqIuf0Ka77LJNQL+y1YHQZrVYbD390kPBU6KgO24VM8 Ot2RMugNkevvxjYGf1r9/4P/FJOvdeS3JHu9yGRLiIF3m3Zlj2BaPuihhowmZkGfcjiV RHHeL15zL02/BKfxnyHaMQGBSV4nOXRQeljbHTwMGe4wBOyKDTDEPd4P28DaOXjaeazw CT1VHh8SOreDpoR90g7ANNCmmVH/lgAjcTOjBsRBWBrZgOYbRkaMAfEJFazj/FXOOox/ hnp4twgP2wwCCgvfvAx33kFXdztcL2KSid6oY3ntbrsameu4yEp0pxN64/frRHYvpvhw kJ3w== 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=I1s6/jfbqcw+oS21rXpZNxQA67umujFYugmOACn2Jug=; b=JzR1+Epwg0q+I8RJoeSxH6zTEkR61bbyntWWJWvOcDSw3czfsY0plXWzTf3tgmU4jV M5+72i3BTkEno/mOGJiom8G5PabuR31X0KCYTvRd3R8sAXq/7jq1tybIQNV0nfltiDyi WdJRnxk89a47Tnb+nmjMovVP6Znd/aNxVSttbH3qn8EXLZ6We5KXSSQbIgl9wt8iYmzM jbbFTCjiTdb24qFnvJqeAyeBf8Oiz86+o31CKbDOkZxgxxj2X0nMbLFgf9D4BtWjSQCi 2cIuWIZx76cXARiH2+zxocz92/y2TroB5WeKfg4pssFF3S1gzCn4nRpENdeaGRG55/IM O/Uw== X-Gm-Message-State: AOAM5337Sx+3Dls8NbMI4WWbFQpUk5XPHAKu47dn/qoQok+v3Y4xteWQ 1zS0JAXiJ/38NIaaq0erwzFWNYAjxArnjTTs3iQ= X-Google-Smtp-Source: ABdhPJyW2ARGPbMWT8nF5VOdPElFpg1WvJres7WXi4D41aPbsP8tWBbZBMOwGIYBAjKRGDgBxRmIOihGYdFz+0hJL44= X-Received: by 2002:a05:6830:837:: with SMTP id t23mr13397220ots.87.1592833041838; Mon, 22 Jun 2020 06:37:21 -0700 (PDT) MIME-Version: 1.0 References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> In-Reply-To: <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> From: Tom Jones Date: Mon, 22 Jun 2020 06:37:09 -0700 Message-ID: To: Denis Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000a537be05a8ac57c5" Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 22 Jun 2020 13:37:25 -0000 --000000000000a537be05a8ac57c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In a perfect world the AS is controlled by the user as resource owner or agent. In my designs the AS is on the user's phone. I like the term "Bound Token" better. It can contain many sub tokens as data or by reference. Of course other use cases are supported. thx ..Tom (mobile) On Mon, Jun 22, 2020, 12:55 AM Denis wrote: > Hello Justin, > > A few comments between the lines. > > One of the most important aspects to GNAP is going to be an ability to > address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do w= ithout significant > gymnastics. So with that, I wanted to bring back a use case discussion th= at > originally came up while we were talking about the possibility of multipl= e > access tokens, a few months back. I don=E2=80=99t know if this concept ha= s a > regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access to= kens=E2=80=9D until we > come up with something better =E2=80=94 assuming we decide this is worthw= hile. > > I don't understand what may mean "directed access tokens=E2=80=9D but I u= nderstand > what means "multiple access tokens". > When speaking of "multiple access tokens", these access tokens may come > from one or more ASs. > > In OAuth, the client=E2=80=99s supposed to always know where to send its = access > token, and that knowledge is completely outside the protocol. This makes = a > lot of sense for many (if not most) deployments, as OAuth is really there > to enable the API access that the client already knows about. > > But we=E2=80=99re now in a world where a client could be talking to a gen= eric API > that could be deployed at a number of different places, or a cloud > deployment that the AS wants to be able to dispatch the client to. > > As soon the AS is placed (again) at the centre of the model, the AS will > have the ability to act as "Big Brother". > OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP > should take care of them. > > In order to do this, the AS needs to be able to communicate to the client > not only the token information (and any related key and presentation > information), but also a set of *directions* about what that specific > token is good for. This needs to be information outside the token itself, > since I believe we want to keep OAuth 2=E2=80=99s feature of having the t= oken be > opaque to the client. Note: while we could map all of these to different > resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance= ) > on the request side, this isn=E2=80=99t enough to tell the client what to= do with > the token *if it doesn=E2=80=99t know already*. > > I know of two use cases already in the wild, where people are addressing > things using a mix of existing standards and some proprietary extensions = to > address things within their silos. I=E2=80=99ll try to summarize here, bu= t I know > the folks I=E2=80=99ve been talking to about this are also on the list so= hopefully > they can chime in with more detail or any corrections for something I=E2= =80=99ve > missed. > > (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2= =80=99t know where > it=E2=80=99s hosted. Everything is in a single security domain controlled= by the > AS, > > Speaking of "multiple access tokens" is in contradiction with single > security domain "controlled" by an AS. > A user may need to demonstrate some of his identity attributes granted > e.g. by his bank but may also > need to demonstrate one or more diplomas granted by one or more > universities. The bank cannot be > the "primary issuer" of a university diploma. It should not be either a > "secondary issuer", because > the bank does not "*need to know"* what are the diplomas of the user. > > but the AS needs to decide at runtime which specific instance of the API > to direct the client to. Since things are closely tied together, the clie= nt > just needs to effectively known an identifier for the RS, and this is > currently implemented as a URI. Once the client has that identifier, it > knows how to dispatch that token to that instance of the RS. > > There is no good reason why the AS should be involved in that step. > OAuth 2.0 is/was implicitly mandating a strong relationship between ASs > and RSs which makes it non scalable. > GNAP should be based on a simple trust relationship : a given RS trusts > some ASs for access tokens that contains some types of attributes. > An AS should not need to know in advance (or even at the time of an acces= s > token request) the RSs that are trusting it. > > A client could first talk to a "global service provider" which has the > knowledge of the different RSs affiliated to it. > > (2) The client knows what kind of thing it=E2=80=99s looking for, but doe= sn=E2=80=99t know > who to ask it from. > > Once again, the client could first talk to a "global service provider" > which has the knowledge of the different RSs affiliated to it. > > There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, an= d the AS needs to > dispatch to different resources depending on which user logged in (and > possibly what the user consented to). To make things more concrete, the > client needs to get driver=E2=80=99s license information, but doesn=E2=80= =99t know ahead of > time which of the many state/provincial bureaus to call to get that > information because it doesn=E2=80=99t know yet who the user is. > > When a user has a driving license, he knows its issuer. The user can then > provide some hint to the client. > > The AS will know who the user is once they log in and approve things, and > so it can direct the client to call the correct RS. Since this is a > relatively simple API with a pre-negotiated cross-domain trust, the AS > returns a URL that the client presents the token at. > > A single AS should not be aware of all the attributes a user has. > > > As far as I know, in both of these cases, the token is only good for that > API and not others =E2=80=94 but more on that later. > > A simple thing to do is just give back a URL with the access token, which > tells the client where to go. > > { > =E2=80=9Caccess_token=E2=80=9D: { > =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D, > =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo" > } > } > > This is good for some kinds of APIs, but it=E2=80=99s limiting because no= t all > APIs dispatch based on the URL. An AS might want to divvy up access token= s > to an API that=E2=80=99s keyed on headers, or verbs, or any number of thi= ngs. And > it doesn=E2=80=99t tell us immediately what to do about non-exact URL mat= ches. Can > the client add query parameters and still use the token? What about path > segments? I like that this simple approach addresses some common > deployments that we already see today (see above), it=E2=80=99s not unive= rsal. Do > we want or need a universal description language for directing where toke= ns > go? > > This also opens up a whole new set of security questions. If the AS can > now direct the client where to use the token, could a rogue AS convince a > legit client to use a stolen token at the wrong RS? And what if the clien= t > ignores the directions from the AS entirely? Could this open up new avenu= es > of attack? > > This is just the start, too. Things get even more complex if the client > can ask for multiple different kinds of resources at once. What if the AS > decides that the client needs a hyper-focused directed token for one part > of the API, but can use a general token for other stuff? Can it signal th= at > to the client? And if it can, does that mean that all clients need to be > prepared for that kind of thing? > > I firmly believe that whatever we build in GNAP, we need to optimize for > the overwhelmingly common use case of a client getting a single access > token to call APIs that it already knows about. Anything we add on top of > that really can=E2=80=99t get in the way of this, because if it does, the= re=E2=80=99s very > small chance that people will try to use this for everyday things. Keep t= he > simple things simple, and the complex things possible, after all. > > I=E2=80=99m really looking forward to hearing what the community thinks a= bout > these use cases, and hopefully the people I=E2=80=99ve chatted with offli= ne about > this can join the conversation and provide more light than I was able to. > > The two use cases which are considered above are: > > (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2= =80=99t know where > it=E2=80=99s hosted. > (2) The client knows what kind of thing it=E2=80=99s looking for, but doe= sn=E2=80=99t know > who to ask it from. > > That does not mean in any way that these two use cases should be solved b= y > placing the AS at the centre of the solution. > > Denis > > > =E2=80=94 Justin > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000a537be05a8ac57c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In a perfect world the AS is controlled by the user as re= source owner or agent. In my designs the AS is on the user's phone.
I like the term "Bound Token= " better. It can contain many sub tokens as data or by reference.

Of course other use cases ar= e supported.

th= x ..Tom (mobile)

On Mon, Jun 22, 2020, 12:55 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Hello Justin,

A few comments between the lines.

=20 One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can=E2=80=99t, or at least can= =E2=80=99t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don=E2=80=99t know if this concept has a regular term,= so I=E2=80=99m going to call it =E2=80=9Cdirected access tokens=E2=80=9D= until we come up with something better =E2=80=94 assuming we decide this is worthwhile= .

I don't understand what may mean "directed access tokens=E2= =80=9D but I understand what means "multiple access tokens".
When speaking of "multiple access tokens", these access tok= ens may come from one or more ASs.

In OAuth, the client=E2=80=99s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we=E2=80=99re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of directions=C2=A0about what that specific token is good for. This needs to be information outside the token itself, since I=C2=A0believe we want to keep OAuth 2=E2=80=99s feature of h= aving the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99= t enough to tell the client what to do with the token if it doesn=E2=80=99t know already.=C2=A0

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I=E2=80=99ll try to summarize here, but I know the folks I= =E2=80=99ve been talking to about this are also on the list so hopefully they can chime in with more detail or any corrections for something I=E2=80=99ve missed.=C2=A0

(1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in= a single security domain controlled by the AS,

Speaking of "multiple access tokens" is in contradiction w= ith single security domain "controlled" by an AS.
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be
the "primary issuer" of a university diploma. It should not= be either a "secondary issuer", because
the bank does not "need to know" what are the diplom= as of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved in that step.
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" w= hich has the knowledge of the different RSs affiliated to it.

(2) The client knows what kind of thing it=E2=80=99s looking for, but doesn=E2=80=99t know who to ask it from.

Once again, the client could first talk to a "global service provider" which has the knowledge of the different RSs affiliate= d to it.

There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by t= he AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver=E2=80=99s license information, but doesn=E2=80=99t know = ahead of time which of the many state/provincial bureaus to call to get that information because it doesn=E2=80=99t know yet who the user is.

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at.

=C2=A0A single AS should not be aware of all the attributes a user has.


As far as I know, in both of these cases, the token is only good for that API and not others =E2=80=94 but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go.=C2=A0

{
=E2=80=9Caccess_to= ken=E2=80=9D: {
=E2=80=9Cvalue=E2= =80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
=E2=80=9Cresource= _uri=E2=80=9D: =E2=80=9Chttps://example/foo"
}
}

This is good for some kinds of APIs, but it=E2=80=99s limiting because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that=E2=80=99s keyed= on headers, or verbs, or any number of things. And it doesn=E2=80=99t = tell us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it=E2=80= =99s not universal. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can=E2= =80=99t get in the way of this, because if it does, there=E2=80=99s very sm= all chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I=E2=80=99m really looking forward to hearing what the community thinks about these use cases, and hopefully the people I=E2=80=99ve chatted with offline about this can join the conversat= ion and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what resource it=E2=80=99s calling, but it do= esn=E2=80=99t know where it=E2=80=99s hosted.
(2) The client knows what kind of thing it=E2=80=99s looking for, b= ut doesn=E2=80=99t know who to ask it from.

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Denis


=C2=A0=E2=80=94 Justin


--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--000000000000a537be05a8ac57c5-- From nobody Tue Jun 23 10:51:17 2020 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 978DF3A0880 for ; Tue, 23 Jun 2020 10:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 jc5EpSTm56qk for ; Tue, 23 Jun 2020 10:51:14 -0700 (PDT) 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 CB17F3A07A6 for ; Tue, 23 Jun 2020 10:51:13 -0700 (PDT) Received: from [192.168.1.14] (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 05NHp9fT029860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jun 2020 13:51:09 -0400 From: Justin Richer Message-Id: <4BA2CBE6-3A30-4425-A890-46E02AD699E2@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_868DAAB7-171C-4079-B4D2-7BBEBC7DB8BA" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 23 Jun 2020 13:51:09 -0400 In-Reply-To: Cc: Denis , txauth@ietf.org To: Tom Jones References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 23 Jun 2020 17:51:17 -0000 --Apple-Mail=_868DAAB7-171C-4079-B4D2-7BBEBC7DB8BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think an on-device AS is an important use case, and we=E2=80=99ve seen = work in the DID and SIOP space that there are plenty of smart agents out = there that can help this. There=E2=80=99s a lot of interesting = investigation in the app2app space right now as well, and I think that = uncoupling the interaction method from the browser is a good step = towards supporting that =E2=80=94 but we should probably start a = separate thread on that topic.=20 Of course, a server-based AS is still a hugely important use case, so we = can=E2=80=99t ignore that while looking at different kinds of deployment = patterns as well.=20 =E2=80=94 Justin > On Jun 22, 2020, at 9:37 AM, Tom Jones = wrote: >=20 > In a perfect world the AS is controlled by the user as resource owner = or agent. In my designs the AS is on the user's phone. >=20 > I like the term "Bound Token" better. It can contain many sub tokens = as data or by reference. >=20 > Of course other use cases are supported. >=20 > thx ..Tom (mobile) >=20 > On Mon, Jun 22, 2020, 12:55 AM Denis > wrote: > Hello Justin, >=20 > A few comments between the lines. >=20 >> One of the most important aspects to GNAP is going to be an ability = to address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t = do without significant gymnastics. So with that, I wanted to bring back = a use case discussion that originally came up while we were talking = about the possibility of multiple access tokens, a few months back. I = don=E2=80=99t know if this concept has a regular term, so I=E2=80=99m = going to call it =E2=80=9Cdirected access tokens=E2=80=9D until we come = up with something better =E2=80=94 assuming we decide this is = worthwhile..=20 > I don't understand what may mean "directed access tokens=E2=80=9D but = I understand what means "multiple access tokens".=20 > When speaking of "multiple access tokens", these access tokens may = come from one or more ASs. >=20 >> In OAuth, the client=E2=80=99s supposed to always know where to send = its access token, and that knowledge is completely outside the protocol. = This makes a lot of sense for many (if not most) deployments, as OAuth = is really there to enable the API access that the client already knows = about. >>=20 >> But we=E2=80=99re now in a world where a client could be talking to a = generic API that could be deployed at a number of different places, or a = cloud deployment that the AS wants to be able to dispatch the client to. > As soon the AS is placed (again) at the centre of the model, the AS = will have the ability to act as "Big Brother". > OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP = should take care of them. >=20 >> In order to do this, the AS needs to be able to communicate to the = client not only the token information (and any related key and = presentation information), but also a set of directions about what that = specific token is good for. This needs to be information outside the = token itself, since I believe we want to keep OAuth 2=E2=80=99s feature = of having the token be opaque to the client. Note: while we could map = all of these to different resource requests (in XYZ parlance) or scopes = (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t = enough to tell the client what to do with the token if it doesn=E2=80=99t = know already.=20 >>=20 >> I know of two use cases already in the wild, where people are = addressing things using a mix of existing standards and some proprietary = extensions to address things within their silos. I=E2=80=99ll try to = summarize here, but I know the folks I=E2=80=99ve been talking to about = this are also on the list so hopefully they can chime in with more = detail or any corrections for something I=E2=80=99ve missed.=20 >>=20 >> (1) The client knows what resource it=E2=80=99s calling, but it = doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in a = single security domain controlled by the AS, > Speaking of "multiple access tokens" is in contradiction with single = security domain "controlled" by an AS.=20 > A user may need to demonstrate some of his identity attributes granted = e.g. by his bank but may also=20 > need to demonstrate one or more diplomas granted by one or more = universities. The bank cannot be=20 > the "primary issuer" of a university diploma. It should not be either = a "secondary issuer", because=20 > the bank does not "need to know" what are the diplomas of the user. >=20 >> but the AS needs to decide at runtime which specific instance of the = API to direct the client to. Since things are closely tied together, the = client just needs to effectively known an identifier for the RS, and = this is currently implemented as a URI. Once the client has that = identifier, it knows how to dispatch that token to that instance of the = RS. > There is no good reason why the AS should be involved in that step.=20 > OAuth 2.0 is/was implicitly mandating a strong relationship between = ASs and RSs which makes it non scalable. > GNAP should be based on a simple trust relationship : a given RS = trusts some ASs for access tokens that contains some types of = attributes. > An AS should not need to know in advance (or even at the time of an = access token request) the RSs that are trusting it. >=20 > A client could first talk to a "global service provider" which has the = knowledge of the different RSs affiliated to it.=20 >=20 >> (2) The client knows what kind of thing it=E2=80=99s looking for, but = doesn=E2=80=99t know who to ask it from. > Once again, the client could first talk to a "global service provider" = which has the knowledge of the different RSs affiliated to it. >=20 >> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the = AS, and the AS needs to dispatch to different resources depending on = which user logged in (and possibly what the user consented to). To make = things more concrete, the client needs to get driver=E2=80=99s license = information, but doesn=E2=80=99t know ahead of time which of the many = state/provincial bureaus to call to get that information because it = doesn=E2=80=99t know yet who the user is. > When a user has a driving license, he knows its issuer. The user can = then provide some hint to the client. >=20 >> The AS will know who the user is once they log in and approve things, = and so it can direct the client to call the correct RS. Since this is a = relatively simple API with a pre-negotiated cross-domain trust, the AS = returns a URL that the client presents the token at.=20 > A single AS should not be aware of all the attributes a user has.=20 >=20 >>=20 >> As far as I know, in both of these cases, the token is only good for = that API and not others =E2=80=94 but more on that later. >>=20 >> A simple thing to do is just give back a URL with the access token, = which tells the client where to go.=20 >>=20 >> { >> =E2=80=9Caccess_token=E2=80=9D: { >> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80= =9D, >> =E2=80=9Cresource_uri=E2=80=9D: = =E2=80=9Chttps://example/foo " >> } >> } >>=20 >> This is good for some kinds of APIs, but it=E2=80=99s limiting = because not all APIs dispatch based on the URL. An AS might want to = divvy up access tokens to an API that=E2=80=99s keyed on headers, or = verbs, or any number of things. And it doesn=E2=80=99t tell us = immediately what to do about non-exact URL matches. Can the client add = query parameters and still use the token? What about path segments? I = like that this simple approach addresses some common deployments that we = already see today (see above), it=E2=80=99s not universal. Do we want or = need a universal description language for directing where tokens go? >>=20 >> This also opens up a whole new set of security questions. If the AS = can now direct the client where to use the token, could a rogue AS = convince a legit client to use a stolen token at the wrong RS? And what = if the client ignores the directions from the AS entirely? Could this = open up new avenues of attack? >>=20 >> This is just the start, too. Things get even more complex if the = client can ask for multiple different kinds of resources at once. What = if the AS decides that the client needs a hyper-focused directed token = for one part of the API, but can use a general token for other stuff? = Can it signal that to the client? And if it can, does that mean that all = clients need to be prepared for that kind of thing? >>=20 >> I firmly believe that whatever we build in GNAP, we need to optimize = for the overwhelmingly common use case of a client getting a single = access token to call APIs that it already knows about. Anything we add = on top of that really can=E2=80=99t get in the way of this, because if = it does, there=E2=80=99s very small chance that people will try to use = this for everyday things. Keep the simple things simple, and the complex = things possible, after all. >>=20 >> I=E2=80=99m really looking forward to hearing what the community = thinks about these use cases, and hopefully the people I=E2=80=99ve = chatted with offline about this can join the conversation and provide = more light than I was able to. > The two use cases which are considered above are: >=20 > (1) The client knows what resource it=E2=80=99s calling, but it = doesn=E2=80=99t know where it=E2=80=99s hosted. > (2) The client knows what kind of thing it=E2=80=99s looking for, but = doesn=E2=80=99t know who to ask it from.=20 >=20 > That does not mean in any way that these two use cases should be = solved by placing the AS at the centre of the solution. >=20 > Denis >=20 >>=20 >> =E2=80=94 Justin >>=20 >>=20 >=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=_868DAAB7-171C-4079-B4D2-7BBEBC7DB8BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think an on-device AS is an important use case, and we=E2=80=99ve seen = work in the DID and SIOP space that there are plenty of smart agents out = there that can help this. There=E2=80=99s a lot of interesting = investigation in the app2app space right now as well, and I think that = uncoupling the interaction method from the browser is a good step = towards supporting that =E2=80=94 but we should probably start a = separate thread on that topic. 

Of course, a server-based AS is still a = hugely important use case, so we can=E2=80=99t ignore that while looking = at different kinds of deployment patterns as well. 

 =E2=80= =94 Justin

On Jun 22, 2020, at 9:37 AM, Tom Jones <thomasclinganjones@gmail.com> wrote:

In a perfect world the AS is = controlled by the user as resource owner or agent. In my designs the AS = is on the user's phone.

I like the term "Bound = Token" better. It can contain many sub tokens as data or by = reference.

Of course other use cases are supported.

thx ..Tom (mobile)

On Mon, Jun 22, 2020, 12:55 AM Denis <denis.ietf@free.fr> = wrote:
=20 =20 =20
Hello Justin,

A few comments between the lines.

=20 One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can=E2=80=99t, or at least = can=E2=80=99t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don=E2=80=99t know if this concept has a regular = term, so I=E2=80=99m going to call it =E2=80=9Cdirected access tokens=E2=80=9D= until we come up with something better =E2=80=94 assuming we decide this is = worthwhile..

I don't understand what may mean = "directed access tokens=E2=80=9D but I understand what means "multiple access tokens".
When speaking of "multiple access tokens", these access tokens may come from one or more ASs.

In OAuth, the client=E2=80=99s supposed to always = know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we=E2=80=99re now in a world where a client = could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.

As soon the AS is placed (again) at the = centre of the model, the AS will have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of directions about what that specific token = is good for. This needs to be information outside the token itself, since I believe we want to keep OAuth 2=E2=80=99s feature = of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99= t enough to tell the client what to do with the token if it doesn=E2=80=99t know already. 

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I=E2=80=99ll try to summarize here, but I know the folks = I=E2=80=99ve been talking to about this are also on the list so hopefully they can chime in with more detail or any corrections for something I=E2=80=99ve missed. 

(1) The client knows what resource it=E2=80=99s = calling, but it doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is = in a single security domain controlled by the AS,

Speaking of "multiple access tokens" is = in contradiction with single security domain "controlled" by an AS.
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be
the "primary issuer" of a university diploma. It should not be either a "secondary issuer", because
the bank does not "need to know" what are the = diplomas of the user.

but the AS needs to decide at runtime which = specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the = RS.

There is no good reason why the AS should = be involved in that step.
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service = provider" which has the knowledge of the different RSs affiliated to it.

(2) The client knows what kind of thing it=E2=80=99s= looking for, but doesn=E2=80=99t know who to ask it from.

Once again, the client could first talk = to a "global service provider" which has the knowledge of the different RSs affiliated to it.

There=E2=80=99s a cross-domain trust that=E2=80=99s = bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver=E2=80=99s license information, but doesn=E2=80=99t = know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn=E2=80=99t know yet who the user is. =

When a user has a driving license, he = knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at.

 A single AS should not be aware of = all the attributes a user has.


As far as I know, in both of these cases, the = token is only good for that API and not others =E2=80=94 but more on = that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to = go. 

= {
= =E2=80=9Caccess_token=E2=80=9D: {
= =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
= =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
= }
= }

This is good for some kinds of APIs, but it=E2=80=99= s limiting because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that=E2=80=99s = keyed on headers, or verbs, or any number of things. And it doesn=E2=80=99t= tell us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it=E2=80= =99s not universal. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, = we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really = can=E2=80=99t get in the way of this, because if it does, there=E2=80=99s very = small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I=E2=80=99m really looking forward to hearing what = the community thinks about these use cases, and hopefully the people I=E2=80=99ve chatted with offline about this can join the = conversation and provide more light than I was able to.

The two use cases which are considered = above are:

(1) The client knows what = resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s hosted.
(2) The client knows what kind of thing it=E2=80=99s looking = for, but doesn=E2=80=99t know who to ask it from.

That does not mean in any way that these = two use cases should be solved by placing the AS at the centre of the solution.

Denis


 =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=_868DAAB7-171C-4079-B4D2-7BBEBC7DB8BA-- From nobody Tue Jun 23 12:26:02 2020 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 9E44F3A093B for ; Tue, 23 Jun 2020 12:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 zMnA6b_RIqqe for ; Tue, 23 Jun 2020 12:25:57 -0700 (PDT) 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 A38CA3A094E for ; Tue, 23 Jun 2020 12:25:56 -0700 (PDT) Received: from [192.168.1.14] (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 05NJPqMC004780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jun 2020 15:25:52 -0400 From: Justin Richer Message-Id: <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_4E55E6D5-3E63-46CE-81EE-F291B656530C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 23 Jun 2020 15:25:52 -0400 In-Reply-To: <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> Cc: txauth@ietf.org To: Denis References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 23 Jun 2020 19:26:00 -0000 --Apple-Mail=_4E55E6D5-3E63-46CE-81EE-F291B656530C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Denis, thanks for the great comments. I think that your trust model is = pretty different from what I=E2=80=99d laid out initially, and while = it=E2=80=99s an interesting and important one, it is not what I meant by = =E2=80=9Cmultiple access tokens=E2=80=9D in my discussion below. I think = that might be the cause of some disconnect here, but that doesn=E2=80=99t = mean it=E2=80=99s out of reach for what the WG is after. When I refer to multiple access tokens, and what the charter calls out = as multiple access tokens, is the ability for the client to get several = access tokens to get different resources from one request. I personally = see this as an optimization of a specific set of use cases, some of = which I discussed in my original email. There are others, I=E2=80=99m = sure, but all the ones I=E2=80=99ve seen are around the client needing = to get several different kinds of access through an AS.=20 I think it=E2=80=99s going to be overwhelmingly common that a given RS = is going to trust exactly one AS that it knows about ahead of time. But = for RS=E2=80=99s that can trust multiple AS=E2=80=99s, then we should = have a model that can accommodate that as well. That=E2=80=99s why the = charter calls out methods for the AS and RS to communicate what the = token=E2=80=99s good for. I think the basis of those methods is going to = start with a common token model, and likely incorporate into things like = token formats and introspection-style token APIs.=20 =E2=80=94 Justin > On Jun 22, 2020, at 3:55 AM, Denis wrote: >=20 > Hello Justin, >=20 > A few comments between the lines. >=20 >> One of the most important aspects to GNAP is going to be an ability = to address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t = do without significant gymnastics. So with that, I wanted to bring back = a use case discussion that originally came up while we were talking = about the possibility of multiple access tokens, a few months back. I = don=E2=80=99t know if this concept has a regular term, so I=E2=80=99m = going to call it =E2=80=9Cdirected access tokens=E2=80=9D until we come = up with something better =E2=80=94 assuming we decide this is = worthwhile.=20 > I don't understand what may mean "directed access tokens=E2=80=9D but = I understand what means "multiple access tokens".=20 > When speaking of "multiple access tokens", these access tokens may = come from one or more ASs. >=20 >> In OAuth, the client=E2=80=99s supposed to always know where to send = its access token, and that knowledge is completely outside the protocol. = This makes a lot of sense for many (if not most) deployments, as OAuth = is really there to enable the API access that the client already knows = about. >>=20 >> But we=E2=80=99re now in a world where a client could be talking to a = generic API that could be deployed at a number of different places, or a = cloud deployment that the AS wants to be able to dispatch the client to.=20= > As soon the AS is placed (again) at the centre of the model, the AS = will have the ability to act as "Big Brother". > OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP = should take care of them. >=20 >> In order to do this, the AS needs to be able to communicate to the = client not only the token information (and any related key and = presentation information), but also a set of directions about what that = specific token is good for. This needs to be information outside the = token itself, since I believe we want to keep OAuth 2=E2=80=99s feature = of having the token be opaque to the client. Note: while we could map = all of these to different resource requests (in XYZ parlance) or scopes = (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t = enough to tell the client what to do with the token if it doesn=E2=80=99t = know already.=20 >>=20 >> I know of two use cases already in the wild, where people are = addressing things using a mix of existing standards and some proprietary = extensions to address things within their silos. I=E2=80=99ll try to = summarize here, but I know the folks I=E2=80=99ve been talking to about = this are also on the list so hopefully they can chime in with more = detail or any corrections for something I=E2=80=99ve missed.=20 >>=20 >> (1) The client knows what resource it=E2=80=99s calling, but it = doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in a = single security domain controlled by the AS,=20 > Speaking of "multiple access tokens" is in contradiction with single = security domain "controlled" by an AS.=20 > A user may need to demonstrate some of his identity attributes granted = e.g. by his bank but may also=20 > need to demonstrate one or more diplomas granted by one or more = universities. The bank cannot be=20 > the "primary issuer" of a university diploma. It should not be either = a "secondary issuer", because=20 > the bank does not "need to know" what are the diplomas of the user. >=20 >> but the AS needs to decide at runtime which specific instance of the = API to direct the client to. Since things are closely tied together, the = client just needs to effectively known an identifier for the RS, and = this is currently implemented as a URI. Once the client has that = identifier, it knows how to dispatch that token to that instance of the = RS. > There is no good reason why the AS should be involved in that step.=20 > OAuth 2.0 is/was implicitly mandating a strong relationship between = ASs and RSs which makes it non scalable. > GNAP should be based on a simple trust relationship : a given RS = trusts some ASs for access tokens that contains some types of = attributes. > An AS should not need to know in advance (or even at the time of an = access token request) the RSs that are trusting it. >=20 > A client could first talk to a "global service provider" which has the = knowledge of the different RSs affiliated to it.=20 >=20 >> (2) The client knows what kind of thing it=E2=80=99s looking for, but = doesn=E2=80=99t know who to ask it from.=20 > Once again, the client could first talk to a "global service provider" = which has the knowledge of the different RSs affiliated to it.=20 >=20 >> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the = AS, and the AS needs to dispatch to different resources depending on = which user logged in (and possibly what the user consented to). To make = things more concrete, the client needs to get driver=E2=80=99s license = information, but doesn=E2=80=99t know ahead of time which of the many = state/provincial bureaus to call to get that information because it = doesn=E2=80=99t know yet who the user is.=20 > When a user has a driving license, he knows its issuer. The user can = then provide some hint to the client. >=20 >> The AS will know who the user is once they log in and approve things, = and so it can direct the client to call the correct RS. Since this is a = relatively simple API with a pre-negotiated cross-domain trust, the AS = returns a URL that the client presents the token at.=20 > A single AS should not be aware of all the attributes a user has.=20 >=20 >>=20 >> As far as I know, in both of these cases, the token is only good for = that API and not others =E2=80=94 but more on that later. >>=20 >> A simple thing to do is just give back a URL with the access token, = which tells the client where to go.=20 >>=20 >> { >> =E2=80=9Caccess_token=E2=80=9D: { >> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80= =9D, >> =E2=80=9Cresource_uri=E2=80=9D: = =E2=80=9Chttps://example/foo " >> } >> } >>=20 >> This is good for some kinds of APIs, but it=E2=80=99s limiting = because not all APIs dispatch based on the URL. An AS might want to = divvy up access tokens to an API that=E2=80=99s keyed on headers, or = verbs, or any number of things. And it doesn=E2=80=99t tell us = immediately what to do about non-exact URL matches. Can the client add = query parameters and still use the token? What about path segments? I = like that this simple approach addresses some common deployments that we = already see today (see above), it=E2=80=99s not universal. Do we want or = need a universal description language for directing where tokens go? >>=20 >> This also opens up a whole new set of security questions. If the AS = can now direct the client where to use the token, could a rogue AS = convince a legit client to use a stolen token at the wrong RS? And what = if the client ignores the directions from the AS entirely? Could this = open up new avenues of attack? >>=20 >> This is just the start, too. Things get even more complex if the = client can ask for multiple different kinds of resources at once. What = if the AS decides that the client needs a hyper-focused directed token = for one part of the API, but can use a general token for other stuff? = Can it signal that to the client? And if it can, does that mean that all = clients need to be prepared for that kind of thing? >>=20 >> I firmly believe that whatever we build in GNAP, we need to optimize = for the overwhelmingly common use case of a client getting a single = access token to call APIs that it already knows about. Anything we add = on top of that really can=E2=80=99t get in the way of this, because if = it does, there=E2=80=99s very small chance that people will try to use = this for everyday things. Keep the simple things simple, and the complex = things possible, after all. >>=20 >> I=E2=80=99m really looking forward to hearing what the community = thinks about these use cases, and hopefully the people I=E2=80=99ve = chatted with offline about this can join the conversation and provide = more light than I was able to. > The two use cases which are considered above are: >=20 > (1) The client knows what resource it=E2=80=99s calling, but it = doesn=E2=80=99t know where it=E2=80=99s hosted. > (2) The client knows what kind of thing it=E2=80=99s looking for, but = doesn=E2=80=99t know who to ask it from.=20 >=20 > That does not mean in any way that these two use cases should be = solved by placing the AS at the centre of the solution. >=20 > Denis >=20 >>=20 >> =E2=80=94 Justin >>=20 >>=20 >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_4E55E6D5-3E63-46CE-81EE-F291B656530C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Denis, thanks for the great comments. I think that your trust = model is pretty different from what I=E2=80=99d laid out initially, and = while it=E2=80=99s an interesting and important one, it is not what I = meant by =E2=80=9Cmultiple access tokens=E2=80=9D in my discussion = below. I think that might be the cause of some disconnect here, but that = doesn=E2=80=99t mean it=E2=80=99s out of reach for what the WG is = after.

When I refer = to multiple access tokens, and what the charter calls out as multiple = access tokens, is the ability for the client to get several access = tokens to get different resources from one request. I personally see = this as an optimization of a specific set of use cases, some of which I = discussed in my original email. There are others, I=E2=80=99m sure, but = all the ones I=E2=80=99ve seen are around the client needing to get = several different kinds of access through an AS. 

I think it=E2=80=99s = going to be overwhelmingly common that a given RS is going to trust = exactly one AS that it knows about ahead of time. But for RS=E2=80=99s = that can trust multiple AS=E2=80=99s, then we should have a model that = can accommodate that as well. That=E2=80=99s why the charter calls out = methods for the AS and RS to communicate what the token=E2=80=99s good = for. I think the basis of those methods is going to start with a common = token model, and likely incorporate into things like token formats and = introspection-style token APIs. 

 =E2=80=94 Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> = wrote:

Hello Justin,

A few comments between the lines.

One of the most important aspects to = GNAP is going to be an ability to address things that OAuth 2 can=E2=80=99= t, or at least can=E2=80=99t do without significant gymnastics. So with = that, I wanted to bring back a use case discussion that originally came = up while we were talking about the possibility of multiple access = tokens, a few months back. I don=E2=80=99t know if this concept has a = regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access = tokens=E2=80=9D until we come up with something better =E2=80=94 = assuming we decide this is worthwhile. 

I don't understand what may mean = "directed access tokens=E2=80=9D but I understand what means "multiple = access tokens". 
When speaking of "multiple access tokens", these access = tokens may come from one or more ASs.

In OAuth, the = client=E2=80=99s supposed to always know where to send its access token, = and that knowledge is completely outside the protocol. This makes a lot = of sense for many (if not most) deployments, as OAuth is really there to = enable the API access that the client already knows about.

But we=E2=80=99re now in = a world where a client could be talking to a generic API that could be = deployed at a number of different places, or a cloud deployment that the = AS wants to be able to dispatch the client to. 

As = soon the AS is placed (again) at the centre of the model, the AS will = have the ability to act as "Big Brother".
OAuth 2.0 has = not taken care of privacy issues. On the contrary, GNAP should take care = of them.

In order to do this, = the AS needs to be able to communicate to the client not only the token = information (and any related key and presentation information), but also = a set of directions about what that specific token is good = for. This needs to be information outside the token itself, since = I believe we want to keep OAuth 2=E2=80=99s feature of having the = token be opaque to the client. Note: while we could map all of these to = different resource requests (in XYZ parlance) or scopes (in OAuth 2 = legacy parlance) on the request side, this isn=E2=80=99t enough to tell = the client what to do with the token if it = doesn=E2=80=99t know already. 

I know of two use cases already in the = wild, where people are addressing things using a mix of existing = standards and some proprietary extensions to address things within their = silos. I=E2=80=99ll try to summarize here, but I know the folks I=E2=80=99= ve been talking to about this are also on the list so hopefully they can = chime in with more detail or any corrections for something I=E2=80=99ve = missed. 

(1) The client knows what resource it=E2=80=99s calling, but = it doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in a = single security domain controlled by the AS, 

Speaking of "multiple access tokens" is in contradiction with = single security domain "controlled" by an AS. 
A user may = need to demonstrate some of his identity attributes granted e.g. by his = bank but may also 
need to demonstrate one or more diplomas granted by one or = more universities. The bank cannot be 
the "primary = issuer" of a university diploma. It should not be either a "secondary = issuer", because 
the bank does not "need to know" what are the diplomas of = the user.

but the AS needs to = decide at runtime which specific instance of the API to direct the = client to. Since things are closely tied together, the client just needs = to effectively known an identifier for the RS, and this is currently = implemented as a URI. Once the client has that identifier, it knows how = to dispatch that token to that instance of the RS.

There = is no good reason why the AS should be involved in that step. 
OAuth 2.0 = is/was implicitly mandating a strong relationship between ASs and RSs = which makes it non scalable.
GNAP should be based on a = simple trust relationship : a given RS trusts some ASs for access tokens = that contains some types of attributes.
An AS should not = need to know in advance (or even at the time of an access token request) = the RSs that are trusting it.

A client could first talk to a = "global service provider" which has the knowledge of the different RSs = affiliated to it. 

(2) The client knows = what kind of thing it=E2=80=99s looking for, but doesn=E2=80=99t know = who to ask it from. 

Once = again, the client could first talk to a "global service provider" which = has the knowledge of the different RSs affiliated to it. 

There=E2=80=99s a = cross-domain trust that=E2=80=99s bridged by the AS, and the AS needs to = dispatch to different resources depending on which user logged in (and = possibly what the user consented to). To make things more concrete, the = client needs to get driver=E2=80=99s license information, but doesn=E2=80=99= t know ahead of time which of the many state/provincial bureaus to call = to get that information because it doesn=E2=80=99t know yet who the user = is. 

When = a user has a driving license, he knows its issuer. The user can then = provide some hint to the client.

The AS will know who = the user is once they log in and approve things, and so it can direct = the client to call the correct RS. Since this is a relatively simple API = with a pre-negotiated cross-domain trust, the AS returns a URL that the = client presents the token at. 

 A single AS should not be aware = of all the attributes a user has. 


As far as I know, in both of these = cases, the token is only good for that API and not others =E2=80=94 but = more on that later.

A simple thing to do is just give back a URL with the access = token, which tells the client where to go. 

{
= =E2=80=9Caccess_token=E2=80=9D: {
= =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
= =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
= }
}

This is good for some kinds of APIs, = but it=E2=80=99s limiting because not all APIs dispatch based on the = URL. An AS might want to divvy up access tokens to an API that=E2=80=99s = keyed on headers, or verbs, or any number of things. And it doesn=E2=80=99= t tell us immediately what to do about non-exact URL matches. Can the = client add query parameters and still use the token? What about path = segments? I like that this simple approach addresses some common = deployments that we already see today (see above), it=E2=80=99s not = universal. Do we want or need a universal description language for = directing where tokens go?

This also opens up a whole new set of security questions. If = the AS can now direct the client where to use the token, could a rogue = AS convince a legit client to use a stolen token at the wrong RS? And = what if the client ignores the directions from the AS entirely? Could = this open up new avenues of attack?

This is just the start, too. Things get = even more complex if the client can ask for multiple different kinds of = resources at once. What if the AS decides that the client needs a = hyper-focused directed token for one part of the API, but can use a = general token for other stuff? Can it signal that to the client? And if = it can, does that mean that all clients need to be prepared for that = kind of thing?

I= firmly believe that whatever we build in GNAP, we need to optimize for = the overwhelmingly common use case of a client getting a single access = token to call APIs that it already knows about. Anything we add on top = of that really can=E2=80=99t get in the way of this, because if it does, = there=E2=80=99s very small chance that people will try to use this for = everyday things. Keep the simple things simple, and the complex things = possible, after all.

I=E2=80=99m really looking forward to hearing what the = community thinks about these use cases, and hopefully the people I=E2=80=99= ve chatted with offline about this can join the conversation and provide = more light than I was able to.

The two use cases which are = considered above are:

(1) The client knows = what resource it=E2=80=99s calling, but it doesn=E2=80=99t know where = it=E2=80=99s hosted.
(2) The client knows what kind of = thing it=E2=80=99s looking for, but doesn=E2=80=99t know who to ask it = from. 

That does not mean in any way that = these two use cases should be solved by placing the AS at the centre of = the solution.

Denis


 =E2=80=94 Justin


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

= --Apple-Mail=_4E55E6D5-3E63-46CE-81EE-F291B656530C-- From nobody Tue Jun 23 13:55:18 2020 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 C401D3A0A47 for ; Tue, 23 Jun 2020 13:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 KqIDaU_SECY9 for ; Tue, 23 Jun 2020 13:55:14 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 10F153A0A3F for ; Tue, 23 Jun 2020 13:55:14 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id 18so3441731otv.6 for ; Tue, 23 Jun 2020 13:55:14 -0700 (PDT) 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=J9yVkh/aU6BUYfnpt0eKfxlLD1146Q8fQdp1uxQ7Duk=; b=HO0lRdhyXl+AnK2Xo8UxeXRxFvQVdmZ7CUBhY08kUQNh0K+Tj9/o8cF/MF67FgRJ8e wCBCEG2TJBsHgnURf6OHLFEBCkbzkE92qORazc4UilgzJZRtcQMVPzFruOEO8B79VKl3 4Gz03VbRQq+VxM3QfE8R7sXenQv0JSfdlNAovKN5j3HM2ZVH6mfE4rMPhEt/NTxNqijY REONmO3E3yUF1LTDcyV1hku6Apar1Kg3b6yQ+zQ/a6rmsjUlSgsgVHqG+4JXQ7M2JjlB Om0UejvzxKZq6bMR53EH2afgx7r3JHLddDdmbfSCHEGZ+AZuN8qQ0Wi3SKEyUEz/YsIo er7A== 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=J9yVkh/aU6BUYfnpt0eKfxlLD1146Q8fQdp1uxQ7Duk=; b=A4W5L7zgOAiYdTyRFl7Alma8RE6rh03be2Jx8EjYJW/mRMSB+KUKzP2cC3cGgU5rG9 O6FyaHLF+GtlZPt1vEDH+e6DbccTy+gRBDWkW8D0EBxa+gVxN3Y59osKLQyOeAzJilWO rK6ZwFKi5gUdtD81WAwLmYtZBTFTAAIaCHbjbbnsAXMGEAHv7NJy6w8fJfijW7NycxCG yxhSZn0HKnXC1hZa1Cfz43p87+JHlEIKgCWiARKzIMKdvjNH15+HPEUlDyNonTEEX0Jk EU7WPCt1OmTbbethDMajCHdk0BXFiID6/9aEXStd0b4nOx4AIf8E1944ICYVh+e4YyYP yUDQ== X-Gm-Message-State: AOAM530S5JxE7UFFMjesHmVdTdVcCw3/JcmoMDEf0fWALjEoAlQ0SZQC 8TOD2vm18EdMEJqQviPV//Gses5DgETgpny+EmM= X-Google-Smtp-Source: ABdhPJx0pPdjP1hsgTPKJPqrn7Aepu+2U+pasQ1qUlV1Xuj4wVRuu+bUarG8XYLA/OXnvFsPXlLhXS4rm9jTeDYiWhE= X-Received: by 2002:a4a:8749:: with SMTP id a9mr20879228ooi.30.1592945713080; Tue, 23 Jun 2020 13:55:13 -0700 (PDT) MIME-Version: 1.0 References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <4BA2CBE6-3A30-4425-A890-46E02AD699E2@mit.edu> In-Reply-To: <4BA2CBE6-3A30-4425-A890-46E02AD699E2@mit.edu> From: Tom Jones Date: Tue, 23 Jun 2020 13:54:59 -0700 Message-ID: To: Justin Richer Cc: Denis , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000005fec3205a8c69303" Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 23 Jun 2020 20:55:17 -0000 --0000000000005fec3205a8c69303 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am getting tired of the whack-a-mole approach of JAR this and RAR that, what's next BAR, FAR, STAR ad infinitum? Can't we just define a bound token type as a high order spec and then just riff on it instead of a full standard for each and every iteration each with their own security and privacy considerations? If we don't the number of id/az tokens will expand in the same manner. Peace ..tom On Tue, Jun 23, 2020 at 10:51 AM Justin Richer wrote: > I think an on-device AS is an important use case, and we=E2=80=99ve seen = work in > the DID and SIOP space that there are plenty of smart agents out there th= at > can help this. There=E2=80=99s a lot of interesting investigation in the = app2app > space right now as well, and I think that uncoupling the interaction meth= od > from the browser is a good step towards supporting that =E2=80=94 but we = should > probably start a separate thread on that topic. > > Of course, a server-based AS is still a hugely important use case, so we > can=E2=80=99t ignore that while looking at different kinds of deployment = patterns > as well. > > =E2=80=94 Justin > > On Jun 22, 2020, at 9:37 AM, Tom Jones > wrote: > > In a perfect world the AS is controlled by the user as resource owner or > agent. In my designs the AS is on the user's phone. > > I like the term "Bound Token" better. It can contain many sub tokens as > data or by reference. > > Of course other use cases are supported. > > thx ..Tom (mobile) > > On Mon, Jun 22, 2020, 12:55 AM Denis wrote: > >> Hello Justin, >> >> A few comments between the lines. >> >> One of the most important aspects to GNAP is going to be an ability to >> address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do = without significant >> gymnastics. So with that, I wanted to bring back a use case discussion t= hat >> originally came up while we were talking about the possibility of multip= le >> access tokens, a few months back. I don=E2=80=99t know if this concept h= as a >> regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access t= okens=E2=80=9D until we >> come up with something better =E2=80=94 assuming we decide this is worth= while.. >> >> I don't understand what may mean "directed access tokens=E2=80=9D but I >> understand what means "multiple access tokens". >> When speaking of "multiple access tokens", these access tokens may come >> from one or more ASs. >> >> In OAuth, the client=E2=80=99s supposed to always know where to send its= access >> token, and that knowledge is completely outside the protocol. This makes= a >> lot of sense for many (if not most) deployments, as OAuth is really ther= e >> to enable the API access that the client already knows about. >> >> But we=E2=80=99re now in a world where a client could be talking to a ge= neric API >> that could be deployed at a number of different places, or a cloud >> deployment that the AS wants to be able to dispatch the client to. >> >> As soon the AS is placed (again) at the centre of the model, the AS will >> have the ability to act as "Big Brother". >> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP >> should take care of them. >> >> In order to do this, the AS needs to be able to communicate to the clien= t >> not only the token information (and any related key and presentation >> information), but also a set of *directions* about what that specific >> token is good for. This needs to be information outside the token itself= , >> since I believe we want to keep OAuth 2=E2=80=99s feature of having the = token be >> opaque to the client. Note: while we could map all of these to different >> resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlanc= e) >> on the request side, this isn=E2=80=99t enough to tell the client what t= o do with >> the token *if it doesn=E2=80=99t know already*. >> >> I know of two use cases already in the wild, where people are addressing >> things using a mix of existing standards and some proprietary extensions= to >> address things within their silos. I=E2=80=99ll try to summarize here, b= ut I know >> the folks I=E2=80=99ve been talking to about this are also on the list s= o hopefully >> they can chime in with more detail or any corrections for something I=E2= =80=99ve >> missed. >> >> (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2= =80=99t know >> where it=E2=80=99s hosted. Everything is in a single security domain con= trolled by >> the AS, >> >> Speaking of "multiple access tokens" is in contradiction with single >> security domain "controlled" by an AS. >> A user may need to demonstrate some of his identity attributes granted >> e.g. by his bank but may also >> need to demonstrate one or more diplomas granted by one or more >> universities. The bank cannot be >> the "primary issuer" of a university diploma. It should not be either a >> "secondary issuer", because >> the bank does not "*need to know"* what are the diplomas of the user. >> >> but the AS needs to decide at runtime which specific instance of the API >> to direct the client to. Since things are closely tied together, the cli= ent >> just needs to effectively known an identifier for the RS, and this is >> currently implemented as a URI. Once the client has that identifier, it >> knows how to dispatch that token to that instance of the RS. >> >> There is no good reason why the AS should be involved in that step. >> OAuth 2.0 is/was implicitly mandating a strong relationship between ASs >> and RSs which makes it non scalable. >> GNAP should be based on a simple trust relationship : a given RS trusts >> some ASs for access tokens that contains some types of attributes. >> An AS should not need to know in advance (or even at the time of an >> access token request) the RSs that are trusting it. >> >> A client could first talk to a "global service provider" which has the >> knowledge of the different RSs affiliated to it. >> >> (2) The client knows what kind of thing it=E2=80=99s looking for, but do= esn=E2=80=99t >> know who to ask it from. >> >> Once again, the client could first talk to a "global service provider" >> which has the knowledge of the different RSs affiliated to it. >> >> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, a= nd the AS needs >> to dispatch to different resources depending on which user logged in (an= d >> possibly what the user consented to). To make things more concrete, the >> client needs to get driver=E2=80=99s license information, but doesn=E2= =80=99t know ahead of >> time which of the many state/provincial bureaus to call to get that >> information because it doesn=E2=80=99t know yet who the user is. >> >> When a user has a driving license, he knows its issuer. The user can the= n >> provide some hint to the client. >> >> The AS will know who the user is once they log in and approve things, an= d >> so it can direct the client to call the correct RS. Since this is a >> relatively simple API with a pre-negotiated cross-domain trust, the AS >> returns a URL that the client presents the token at. >> >> A single AS should not be aware of all the attributes a user has. >> >> >> As far as I know, in both of these cases, the token is only good for tha= t >> API and not others =E2=80=94 but more on that later. >> >> A simple thing to do is just give back a URL with the access token, whic= h >> tells the client where to go. >> >> { >> =E2=80=9Caccess_token=E2=80=9D: { >> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D, >> =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo" >> } >> } >> >> This is good for some kinds of APIs, but it=E2=80=99s limiting because n= ot all >> APIs dispatch based on the URL. An AS might want to divvy up access toke= ns >> to an API that=E2=80=99s keyed on headers, or verbs, or any number of th= ings. And >> it doesn=E2=80=99t tell us immediately what to do about non-exact URL ma= tches. Can >> the client add query parameters and still use the token? What about path >> segments? I like that this simple approach addresses some common >> deployments that we already see today (see above), it=E2=80=99s not univ= ersal. Do >> we want or need a universal description language for directing where tok= ens >> go? >> >> This also opens up a whole new set of security questions. If the AS can >> now direct the client where to use the token, could a rogue AS convince = a >> legit client to use a stolen token at the wrong RS? And what if the clie= nt >> ignores the directions from the AS entirely? Could this open up new aven= ues >> of attack? >> >> This is just the start, too. Things get even more complex if the client >> can ask for multiple different kinds of resources at once. What if the A= S >> decides that the client needs a hyper-focused directed token for one par= t >> of the API, but can use a general token for other stuff? Can it signal t= hat >> to the client? And if it can, does that mean that all clients need to be >> prepared for that kind of thing? >> >> I firmly believe that whatever we build in GNAP, we need to optimize for >> the overwhelmingly common use case of a client getting a single access >> token to call APIs that it already knows about. Anything we add on top o= f >> that really can=E2=80=99t get in the way of this, because if it does, th= ere=E2=80=99s very >> small chance that people will try to use this for everyday things. Keep = the >> simple things simple, and the complex things possible, after all. >> >> I=E2=80=99m really looking forward to hearing what the community thinks = about >> these use cases, and hopefully the people I=E2=80=99ve chatted with offl= ine about >> this can join the conversation and provide more light than I was able to= . >> >> The two use cases which are considered above are: >> >> (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2= =80=99t know >> where it=E2=80=99s hosted. >> (2) The client knows what kind of thing it=E2=80=99s looking for, but do= esn=E2=80=99t >> know who to ask it from. >> >> That does not mean in any way that these two use cases should be solved >> by placing the AS at the centre of the solution. >> >> Denis >> >> >> =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 > > > --0000000000005fec3205a8c69303 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am getting tired of the whack-a-mole approach of JAR thi= s and RAR that, what's next BAR, FAR, STAR ad infinitum? Can't we j= ust define a bound token type as a high order spec and then just riff on it= instead of a full standard for each and every iteration each=C2=A0with the= ir own security and privacy considerations? If we don't the number of i= d/az tokens will expand in the same manner.
Peace ..tom


On Tue, Jun 23, 202= 0 at 10:51 AM Justin Richer <jricher@= mit.edu> wrote:
I think an on-device AS is= an important use case, and we=E2=80=99ve seen work in the DID and SIOP spa= ce that there are plenty of smart agents out there that can help this. Ther= e=E2=80=99s a lot of interesting investigation in the app2app space right n= ow as well, and I think that uncoupling the interaction method from the bro= wser is a good step towards supporting that =E2=80=94 but we should probabl= y start a separate thread on that topic.=C2=A0

Of course= , a server-based AS is still a hugely important use case, so we can=E2=80= =99t ignore that while looking at different kinds of deployment patterns as= well.=C2=A0

=C2=A0=E2=80=94 Justin

On Jun 22, 2020, at 9:37 AM, Tom Jones <thomasclinganj= ones@gmail.com> wrote:

In a perfect = world the AS is controlled by the user as resource owner or agent. In my de= signs the AS is on the user's phone.

I like the term "Bound Token" better. It can contain m= any sub tokens as data or by reference.

Of course other use cases are supported.

thx ..Tom (mobile)

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 22, 2020, 12:55 AM Denis &= lt;denis.ietf@free.= fr> wrote:
=20 One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can=E2=80=99t, or at least can= =E2=80=99t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don=E2=80=99t know if this concept has a regular term,= so I=E2=80=99m going to call it =E2=80=9Cdirected access tokens=E2=80=9D= until we come up with something better =E2=80=94 assuming we decide this is worthwhile= ..

I don't understand what may mean "directed acc= ess tokens=E2=80=9D but I understand what means "multiple access tokens".
When speaking of "multiple access tokens", these access tok= ens may come from one or more ASs.

In OAuth, the client=E2=80=99s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we=E2=80=99re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.

As soon the AS is placed (again) at the centre of the m= odel, the AS will have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of directions=C2=A0about what that specific token is good for. This needs to be information outside the token itself, since I=C2=A0believe we want to keep OAuth 2=E2=80=99s feature of h= aving the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99= t enough to tell the client what to do with the token if it doesn=E2=80=99t know already.=C2=A0

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I=E2=80=99ll try to summarize here, but I know the folks I= =E2=80=99ve been talking to about this are also on the list so hopefully they can chime in with more detail or any corrections for something I=E2=80=99ve missed.=C2=A0

(1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in= a single security domain controlled by the AS,

Speaking of "multiple access tokens" is in co= ntradiction with single security domain "controlled" by an AS.
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be
the "primary issuer" of a university diploma. It should not= be either a "secondary issuer", because
the bank does not "need to know" what are the diplom= as of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved i= n that step.
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider&quo= t; which has the knowledge of the different RSs affiliated to it.

(2) The client knows what kind of thing it=E2=80=99s looking for, but doesn=E2=80=99t know who to ask it from.

Once again, the client could first talk to a "glob= al service provider" which has the knowledge of the different RSs affiliate= d to it.

There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by t= he AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver=E2=80=99s license information, but doesn=E2=80=99t know = ahead of time which of the many state/provincial bureaus to call to get that information because it doesn=E2=80=99t know yet who the user is.

When a user has a driving license, he knows its issuer.= The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at.

=C2=A0A single AS should not be aware of all the attrib= utes a user has.


As far as I know, in both of these cases, the token is only good for that API and not others =E2=80=94 but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go.=C2=A0

{
=E2=80=9Caccess_to= ken=E2=80=9D: {
=E2=80=9Cvalue=E2= =80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
=E2=80=9Cresource= _uri=E2=80=9D: =E2=80=9Chttps://example/foo"
}
}

This is good for some kinds of APIs, but it=E2=80=99s limiting because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that=E2=80=99s keyed= on headers, or verbs, or any number of things. And it doesn=E2=80=99t = tell us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it=E2=80= =99s not universal. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can=E2= =80=99t get in the way of this, because if it does, there=E2=80=99s very sm= all chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I=E2=80=99m really looking forward to hearing what the community thinks about these use cases, and hopefully the people I=E2=80=99ve chatted with offline about this can join the conversat= ion and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what resource it=E2=80=99s calling,= but it doesn=E2=80=99t know where it=E2=80=99s hosted.
(2) The client knows what kind of thing it=E2=80=99s looking for, b= ut doesn=E2=80=99t know who to ask it from.

That does not mean in any way that these two use cases = should be solved by placing the AS at the centre of the solution.

Denis


=C2=A0=E2=80=94 Justin


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

--0000000000005fec3205a8c69303-- From nobody Tue Jun 23 14:11:36 2020 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 425223A0A66 for ; Tue, 23 Jun 2020 14:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 rQzYj_kcTHz8 for ; Tue, 23 Jun 2020 14:11:31 -0700 (PDT) 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 7EABE3A0901 for ; Tue, 23 Jun 2020 14:11:31 -0700 (PDT) Received: from [192.168.1.14] (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 05NLBR2V013056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jun 2020 17:11:27 -0400 From: Justin Richer Message-Id: <9DDBE649-5CFE-4A04-8AD3-995876B4DCB2@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_90657DFA-0E98-43FE-B39D-0A13B9F4EA04" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 23 Jun 2020 17:11:27 -0400 In-Reply-To: Cc: Denis , txauth@ietf.org To: Tom Jones References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <4BA2CBE6-3A30-4425-A890-46E02AD699E2@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 23 Jun 2020 21:11:34 -0000 --Apple-Mail=_90657DFA-0E98-43FE-B39D-0A13B9F4EA04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Well that=E2=80=99s one of the biggest reasons I wanted to start this WG = =E2=80=94 to take all the extensions to the OAuth model and pull them = together in a consistent way, instead of the ad-hoc duct-tape-over-time = method that=E2=80=99s evolved in the OAuth world. This is also why I = think it=E2=80=99s important to break from the OAuth 2 space in a few = key ways, so we don=E2=80=99t drag that mess with us. It=E2=80=99s my hope and goal that we can build a true next phase of = evolution here, and not just paint over the hacks of the past and call = it good.=20 =E2=80=94 Justin > On Jun 23, 2020, at 4:54 PM, Tom Jones = wrote: >=20 > I am getting tired of the whack-a-mole approach of JAR this and RAR = that, what's next BAR, FAR, STAR ad infinitum? Can't we just define a = bound token type as a high order spec and then just riff on it instead = of a full standard for each and every iteration each with their own = security and privacy considerations? If we don't the number of id/az = tokens will expand in the same manner. > Peace ..tom >=20 >=20 > On Tue, Jun 23, 2020 at 10:51 AM Justin Richer > wrote: > I think an on-device AS is an important use case, and we=E2=80=99ve = seen work in the DID and SIOP space that there are plenty of smart = agents out there that can help this. There=E2=80=99s a lot of = interesting investigation in the app2app space right now as well, and I = think that uncoupling the interaction method from the browser is a good = step towards supporting that =E2=80=94 but we should probably start a = separate thread on that topic.=20 >=20 > Of course, a server-based AS is still a hugely important use case, so = we can=E2=80=99t ignore that while looking at different kinds of = deployment patterns as well.=20 >=20 > =E2=80=94 Justin >=20 >> On Jun 22, 2020, at 9:37 AM, Tom Jones > wrote: >>=20 >> In a perfect world the AS is controlled by the user as resource owner = or agent. In my designs the AS is on the user's phone. >>=20 >> I like the term "Bound Token" better. It can contain many sub tokens = as data or by reference. >>=20 >> Of course other use cases are supported. >>=20 >> thx ..Tom (mobile) >>=20 >> On Mon, Jun 22, 2020, 12:55 AM Denis > wrote: >> Hello Justin, >>=20 >> A few comments between the lines. >>=20 >>> One of the most important aspects to GNAP is going to be an ability = to address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t = do without significant gymnastics. So with that, I wanted to bring back = a use case discussion that originally came up while we were talking = about the possibility of multiple access tokens, a few months back. I = don=E2=80=99t know if this concept has a regular term, so I=E2=80=99m = going to call it =E2=80=9Cdirected access tokens=E2=80=9D until we come = up with something better =E2=80=94 assuming we decide this is = worthwhile..=20 >> I don't understand what may mean "directed access tokens=E2=80=9D but = I understand what means "multiple access tokens".=20 >> When speaking of "multiple access tokens", these access tokens may = come from one or more ASs. >>=20 >>> In OAuth, the client=E2=80=99s supposed to always know where to send = its access token, and that knowledge is completely outside the protocol. = This makes a lot of sense for many (if not most) deployments, as OAuth = is really there to enable the API access that the client already knows = about. >>>=20 >>> But we=E2=80=99re now in a world where a client could be talking to = a generic API that could be deployed at a number of different places, or = a cloud deployment that the AS wants to be able to dispatch the client = to. >> As soon the AS is placed (again) at the centre of the model, the AS = will have the ability to act as "Big Brother". >> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP = should take care of them. >>=20 >>> In order to do this, the AS needs to be able to communicate to the = client not only the token information (and any related key and = presentation information), but also a set of directions about what that = specific token is good for. This needs to be information outside the = token itself, since I believe we want to keep OAuth 2=E2=80=99s feature = of having the token be opaque to the client. Note: while we could map = all of these to different resource requests (in XYZ parlance) or scopes = (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t = enough to tell the client what to do with the token if it doesn=E2=80=99t = know already.=20 >>>=20 >>> I know of two use cases already in the wild, where people are = addressing things using a mix of existing standards and some proprietary = extensions to address things within their silos. I=E2=80=99ll try to = summarize here, but I know the folks I=E2=80=99ve been talking to about = this are also on the list so hopefully they can chime in with more = detail or any corrections for something I=E2=80=99ve missed.=20 >>>=20 >>> (1) The client knows what resource it=E2=80=99s calling, but it = doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in a = single security domain controlled by the AS, >> Speaking of "multiple access tokens" is in contradiction with single = security domain "controlled" by an AS.=20 >> A user may need to demonstrate some of his identity attributes = granted e.g. by his bank but may also=20 >> need to demonstrate one or more diplomas granted by one or more = universities. The bank cannot be=20 >> the "primary issuer" of a university diploma. It should not be either = a "secondary issuer", because=20 >> the bank does not "need to know" what are the diplomas of the user. >>=20 >>> but the AS needs to decide at runtime which specific instance of the = API to direct the client to. Since things are closely tied together, the = client just needs to effectively known an identifier for the RS, and = this is currently implemented as a URI. Once the client has that = identifier, it knows how to dispatch that token to that instance of the = RS. >> There is no good reason why the AS should be involved in that step.=20= >> OAuth 2.0 is/was implicitly mandating a strong relationship between = ASs and RSs which makes it non scalable. >> GNAP should be based on a simple trust relationship : a given RS = trusts some ASs for access tokens that contains some types of = attributes. >> An AS should not need to know in advance (or even at the time of an = access token request) the RSs that are trusting it. >>=20 >> A client could first talk to a "global service provider" which has = the knowledge of the different RSs affiliated to it.=20 >>=20 >>> (2) The client knows what kind of thing it=E2=80=99s looking for, = but doesn=E2=80=99t know who to ask it from. >> Once again, the client could first talk to a "global service = provider" which has the knowledge of the different RSs affiliated to it. >>=20 >>> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the = AS, and the AS needs to dispatch to different resources depending on = which user logged in (and possibly what the user consented to). To make = things more concrete, the client needs to get driver=E2=80=99s license = information, but doesn=E2=80=99t know ahead of time which of the many = state/provincial bureaus to call to get that information because it = doesn=E2=80=99t know yet who the user is. >> When a user has a driving license, he knows its issuer. The user can = then provide some hint to the client. >>=20 >>> The AS will know who the user is once they log in and approve = things, and so it can direct the client to call the correct RS. Since = this is a relatively simple API with a pre-negotiated cross-domain = trust, the AS returns a URL that the client presents the token at.=20 >> A single AS should not be aware of all the attributes a user has.=20 >>=20 >>>=20 >>> As far as I know, in both of these cases, the token is only good for = that API and not others =E2=80=94 but more on that later. >>>=20 >>> A simple thing to do is just give back a URL with the access token, = which tells the client where to go.=20 >>>=20 >>> { >>> =E2=80=9Caccess_token=E2=80=9D: { >>> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80= =9D, >>> =E2=80=9Cresource_uri=E2=80=9D: = =E2=80=9Chttps://example/foo " >>> } >>> } >>>=20 >>> This is good for some kinds of APIs, but it=E2=80=99s limiting = because not all APIs dispatch based on the URL. An AS might want to = divvy up access tokens to an API that=E2=80=99s keyed on headers, or = verbs, or any number of things. And it doesn=E2=80=99t tell us = immediately what to do about non-exact URL matches. Can the client add = query parameters and still use the token? What about path segments? I = like that this simple approach addresses some common deployments that we = already see today (see above), it=E2=80=99s not universal. Do we want or = need a universal description language for directing where tokens go? >>>=20 >>> This also opens up a whole new set of security questions. If the AS = can now direct the client where to use the token, could a rogue AS = convince a legit client to use a stolen token at the wrong RS? And what = if the client ignores the directions from the AS entirely? Could this = open up new avenues of attack? >>>=20 >>> This is just the start, too. Things get even more complex if the = client can ask for multiple different kinds of resources at once. What = if the AS decides that the client needs a hyper-focused directed token = for one part of the API, but can use a general token for other stuff? = Can it signal that to the client? And if it can, does that mean that all = clients need to be prepared for that kind of thing? >>>=20 >>> I firmly believe that whatever we build in GNAP, we need to optimize = for the overwhelmingly common use case of a client getting a single = access token to call APIs that it already knows about. Anything we add = on top of that really can=E2=80=99t get in the way of this, because if = it does, there=E2=80=99s very small chance that people will try to use = this for everyday things. Keep the simple things simple, and the complex = things possible, after all. >>>=20 >>> I=E2=80=99m really looking forward to hearing what the community = thinks about these use cases, and hopefully the people I=E2=80=99ve = chatted with offline about this can join the conversation and provide = more light than I was able to. >> The two use cases which are considered above are: >>=20 >> (1) The client knows what resource it=E2=80=99s calling, but it = doesn=E2=80=99t know where it=E2=80=99s hosted. >> (2) The client knows what kind of thing it=E2=80=99s looking for, but = doesn=E2=80=99t know who to ask it from.=20 >>=20 >> That does not mean in any way that these two use cases should be = solved by placing the AS at the centre of the solution. >>=20 >> Denis >>=20 >>>=20 >>> =E2=80=94 Justin >>>=20 >>>=20 >>=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=_90657DFA-0E98-43FE-B39D-0A13B9F4EA04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Well = that=E2=80=99s one of the biggest reasons I wanted to start this WG =E2=80= =94 to take all the extensions to the OAuth model and pull them together = in a consistent way, instead of the ad-hoc duct-tape-over-time method = that=E2=80=99s evolved in the OAuth world. This is also why I think = it=E2=80=99s important to break from the OAuth 2 space in a few key = ways, so we don=E2=80=99t drag that mess with us.

It=E2=80=99s my hope and goal that we = can build a true next phase of evolution here, and not just paint over = the hacks of the past and call it good. 

 =E2=80=94 = Justin

On Jun 23, 2020, at 4:54 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

I am getting tired of the = whack-a-mole approach of JAR this and RAR that, what's next BAR, FAR, = STAR ad infinitum? Can't we just define a bound token type as a high = order spec and then just riff on it instead of a full standard for each = and every iteration each with their own security and privacy = considerations? If we don't the number of id/az tokens will expand in = the same manner.
Peace ..tom


On Tue, Jun 23, 2020 at 10:51 AM Justin Richer = <jricher@mit.edu> = wrote:
I think an on-device AS is an important use = case, and we=E2=80=99ve seen work in the DID and SIOP space that there = are plenty of smart agents out there that can help this. There=E2=80=99s = a lot of interesting investigation in the app2app space right now as = well, and I think that uncoupling the interaction method from the = browser is a good step towards supporting that =E2=80=94 but we should = probably start a separate thread on that topic. 

Of course, a server-based AS is still a = hugely important use case, so we can=E2=80=99t ignore that while looking = at different kinds of deployment patterns as well. 

 =E2=80= =94 Justin

On Jun 22, 2020, at 9:37 AM, = Tom Jones <thomasclinganjones@gmail.com> = wrote:

In= a perfect world the AS is controlled by the user as resource owner or = agent. In my designs the AS is on the user's phone.

I like the = term "Bound Token" better. It can contain many sub tokens as data or by = reference.

Of course other use cases are supported.

thx ..Tom = (mobile)

On Mon, Jun 22, 2020, 12:55 AM Denis = <denis.ietf@free.fr> wrote:
=20 =20 =20
Hello Justin,

A few comments between the lines.

=20 One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can=E2=80=99t, or at least = can=E2=80=99t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don=E2=80=99t know if this concept has a regular = term, so I=E2=80=99m going to call it =E2=80=9Cdirected access tokens=E2=80=9D= until we come up with something better =E2=80=94 assuming we decide this is = worthwhile..

I don't understand what may mean = "directed access tokens=E2=80=9D but I understand what means "multiple access tokens".
When speaking of "multiple access tokens", these access tokens may come from one or more ASs.

In OAuth, the client=E2=80=99s supposed to always = know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we=E2=80=99re now in a world where a client = could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.

As soon the AS is placed (again) at the = centre of the model, the AS will have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of directions about what that specific token = is good for. This needs to be information outside the token itself, since I believe we want to keep OAuth 2=E2=80=99s feature = of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99= t enough to tell the client what to do with the token if it doesn=E2=80=99t know already. 

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I=E2=80=99ll try to summarize here, but I know the folks = I=E2=80=99ve been talking to about this are also on the list so hopefully they can chime in with more detail or any corrections for something I=E2=80=99ve missed. 

(1) The client knows what resource it=E2=80=99s = calling, but it doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is = in a single security domain controlled by the AS,

Speaking of "multiple access tokens" is = in contradiction with single security domain "controlled" by an AS.
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be
the "primary issuer" of a university diploma. It should not be either a "secondary issuer", because
the bank does not "need to know" what are the = diplomas of the user.

but the AS needs to decide at runtime which = specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the = RS.

There is no good reason why the AS should = be involved in that step.
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service = provider" which has the knowledge of the different RSs affiliated to it.

(2) The client knows what kind of thing it=E2=80=99s= looking for, but doesn=E2=80=99t know who to ask it from.

Once again, the client could first talk = to a "global service provider" which has the knowledge of the different RSs affiliated to it.

There=E2=80=99s a cross-domain trust that=E2=80=99s = bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver=E2=80=99s license information, but doesn=E2=80=99t = know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn=E2=80=99t know yet who the user is. =

When a user has a driving license, he = knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at.

 A single AS should not be aware of = all the attributes a user has.


As far as I know, in both of these cases, the = token is only good for that API and not others =E2=80=94 but more on = that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to = go. 

= {
= =E2=80=9Caccess_token=E2=80=9D: {
= =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
= =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
= }
= }

This is good for some kinds of APIs, but it=E2=80=99= s limiting because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that=E2=80=99s = keyed on headers, or verbs, or any number of things. And it doesn=E2=80=99t= tell us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it=E2=80= =99s not universal. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, = we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really = can=E2=80=99t get in the way of this, because if it does, there=E2=80=99s very = small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I=E2=80=99m really looking forward to hearing what = the community thinks about these use cases, and hopefully the people I=E2=80=99ve chatted with offline about this can join the = conversation and provide more light than I was able to.

The two use cases which are considered = above are:

(1) The client knows what = resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s hosted.
(2) The client knows what kind of thing it=E2=80=99s looking = for, but doesn=E2=80=99t know who to ask it from.

That does not mean in any way that these = two use cases should be solved by placing the AS at the centre of the solution.

Denis


 =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=_90657DFA-0E98-43FE-B39D-0A13B9F4EA04-- From nobody Wed Jun 24 02:15:29 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 016433A0D06; Wed, 24 Jun 2020 02:15:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: gnap-chairs@ietf.org, txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <159299011836.10519.11264712678872270096@ietfa.amsl.com> Date: Wed, 24 Jun 2020 02:15:18 -0700 Archived-At: Subject: [Txauth] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-?= =?utf-8?q?ietf-gnap-00-00=3A_=28with_COMMENT=29?= X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 09:15:25 -0000 Éric Vyncke has entered the following ballot position for charter-ietf-gnap-00-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-gnap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some quick comments: - the charter itself is rather verbose, sometimes convoluted, and often directive (looking like the charter is about rubber stamping existing work) - nits please expand "AS" before first use - missing milestones dates ? - should this new WG work with others? From nobody Wed Jun 24 03:14:25 2020 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 176EF3A0D05 for ; Wed, 24 Jun 2020 03:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 2kMdgPHBI7ne for ; Wed, 24 Jun 2020 03:14:21 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr [80.12.242.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF6A3A0D04 for ; Wed, 24 Jun 2020 03:14:20 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d20 with ME id uyEF220084FMSmm03yEFNf; Wed, 24 Jun 2020 12:14:18 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 24 Jun 2020 12:14:18 +0200 X-ME-IP: 86.238.65.197 To: Justin Richer Cc: txauth@ietf.org References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> From: Denis Message-ID: Date: Wed, 24 Jun 2020 12:14:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> Content-Type: multipart/alternative; boundary="------------4A355BB991577811E6F62B20" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 24 Jun 2020 10:14:24 -0000 This is a multi-part message in MIME format. --------------4A355BB991577811E6F62B20 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Justin, I fear we are still far away from an agreement about what this BoF should do. Tom Jones is saying " I am getting tired of the whack-a-mole approach ..." I don't agree with you when you write: "I think it’s going to be overwhelmingly common that a given RS is going to trust exactly one AS that it knows about ahead of time". Such an architecture would have exactly the same limitations as OAuth 2.0. and would not be scalable. Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions. For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believe that we have an agreement at this time on what these trust relationships are. You are also using the following wording: "methods for the AS and RS to communicate what the token’s good for". With such a paradigm, it would be impossible to protect the user's privacy. A key question is : Will GNAP take care of the user's privacy or will GNAP *prevent *to take care of the user's privacy ? About "the ability for the client to get several access tokens to get different resources from one request" is indeed a complex case. No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s) the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations performed by its clients on various RSs. To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time at which the user's *consent and choice* happens (/consent and choice/ is the first privacy principle from ISO 29100). First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases. When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS. His "consent and choice" should then be obtained by the first RS and, when the user agrees, the client should then ask an access token to one of the ASs trusted by the second RS in order to perform the subsequent operation. Denis PS.  In an email sent on June 23 you wrote: " I think an on-device AS is an important use case".  I am sorry, but I don't understand.        However, I do understand what "a server-based AS" is. > Denis, thanks for the great comments. I think that your trust model is > pretty different from what I’d laid out initially, and while it’s an > interesting and important one, it is not what I meant by “multiple > access tokens” in my discussion below. I think that might be the cause > of some disconnect here, but that doesn’t mean it’s out of reach for > what the WG is after. > > When I refer to multiple access tokens, and what the charter calls out > as multiple access tokens, is the ability for the client to get > several access tokens to get different resources from one request. I > personally see this as an optimization of a specific set of use cases, > some of which I discussed in my original email. There are others, I’m > sure, but all the ones I’ve seen are around the client needing to get > several different kinds of access through an AS. > > I think it’s going to be overwhelmingly common that a given RS is > going to trust exactly one AS that it knows about ahead of time. But > for RS’s that can trust multiple AS’s, then we should have a model > that can accommodate that as well. That’s why the charter calls out > methods for the AS and RS to communicate what the token’s good for. I > think the basis of those methods is going to start with a common token > model, and likely incorporate into things like token formats and > introspection-style token APIs. > >  — Justin > >> On Jun 22, 2020, at 3:55 AM, Denis > > wrote: >> >> Hello Justin, >> >> A few comments between the lines. >> >>> One of the most important aspects to GNAP is going to be an ability >>> to address things that OAuth 2 can’t, or at least can’t do without >>> significant gymnastics. So with that, I wanted to bring back a use >>> case discussion that originally came up while we were talking about >>> the possibility of multiple access tokens, a few months back. I >>> don’t know if this concept has a regular term, so I’m going to call >>> it “directed access tokens” until we come up with something better — >>> assuming we decide this is worthwhile. >> >> I don't understand what may mean "directed access tokens” but I >> understand what means "multiple access tokens". >> When speaking of "multiple access tokens", these access tokens may >> come from one or more ASs. >> >>> In OAuth, the client’s supposed to always know where to send its >>> access token, and that knowledge is completely outside the protocol. >>> This makes a lot of sense for many (if not most) deployments, as >>> OAuth is really there to enable the API access that the client >>> already knows about. >>> >>> But we’re now in a world where a client could be talking to a >>> generic API that could be deployed at a number of different places, >>> or a cloud deployment that the AS wants to be able to dispatch the >>> client to. >> >> As soon the AS is placed (again) at the centre of the model, the AS >> will have the ability to act as "Big Brother". >> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP >> should take care of them. >> >>> In order to do this, the AS needs to be able to communicate to the >>> client not only the token information (and any related key and >>> presentation information), but also a set of/directions/ about what >>> that specific token is good for. This needs to be information >>> outside the token itself, since I believe we want to keep OAuth 2’s >>> feature of having the token be opaque to the client. Note: while we >>> could map all of these to different resource requests (in XYZ >>> parlance) or scopes (in OAuth 2 legacy parlance) on the request >>> side, this isn’t enough to tell the client what to do with the >>> token/if it doesn’t know already/. >>> >>> I know of two use cases already in the wild, where people are >>> addressing things using a mix of existing standards and some >>> proprietary extensions to address things within their silos. I’ll >>> try to summarize here, but I know the folks I’ve been talking to >>> about this are also on the list so hopefully they can chime in with >>> more detail or any corrections for something I’ve missed. >>> >>> (1) The client knows what resource it’s calling, but it doesn’t know >>> where it’s hosted. Everything is in a single security domain >>> controlled by the AS, >> >> Speaking of "multiple access tokens" is in contradiction with single >> security domain "controlled" by an AS. >> A user may need to demonstrate some of his identity attributes >> granted e.g. by his bank but may also >> need to demonstrate one or more diplomas granted by one or more >> universities. The bank cannot be >> the "primary issuer" of a university diploma. It should not be either >> a "secondary issuer", because >> the bank does not "/need to know"/what are the diplomas of the user. >> >>> but the AS needs to decide at runtime which specific instance of the >>> API to direct the client to. Since things are closely tied together, >>> the client just needs to effectively known an identifier for the RS, >>> and this is currently implemented as a URI. Once the client has that >>> identifier, it knows how to dispatch that token to that instance of >>> the RS. >> >> There is no good reason why the AS should be involved in that step. >> OAuth 2.0 is/was implicitly mandating a strong relationship between >> ASs and RSs which makes it non scalable. >> GNAP should be based on a simple trust relationship : a given RS >> trusts some ASs for access tokens that contains some types of attributes. >> An AS should not need to know in advance (or even at the time of an >> access token request) the RSs that are trusting it. >> >> A client could first talk to a "global service provider" which has >> the knowledge of the different RSs affiliated to it. >> >>> (2) The client knows what kind of thing it’s looking for, but >>> doesn’t know who to ask it from. >> >> Once again, the client could first talk to a "global service >> provider" which has the knowledge of the different RSs affiliated to it. >> >>> There’s a cross-domain trust that’s bridged by the AS, and the AS >>> needs to dispatch to different resources depending on which user >>> logged in (and possibly what the user consented to). To make things >>> more concrete, the client needs to get driver’s license information, >>> but doesn’t know ahead of time which of the many state/provincial >>> bureaus to call to get that information because it doesn’t know yet >>> who the user is. >> >> When a user has a driving license, he knows its issuer. The user can >> then provide some hint to the client. >> >>> The AS will know who the user is once they log in and approve >>> things, and so it can direct the client to call the correct RS. >>> Since this is a relatively simple API with a pre-negotiated >>> cross-domain trust, the AS returns a URL that the client presents >>> the token at. >> >>  A single AS should not be aware of all the attributes a user has. >> >>> >>> As far as I know, in both of these cases, the token is only good for >>> that API and not others — but more on that later. >>> >>> A simple thing to do is just give back a URL with the access token, >>> which tells the client where to go. >>> >>> { >>> “access_token”: { >>> “value”: “87yui843yfer”, >>> “resource_uri”: “https://example/foo" >>> } >>> } >>> >>> This is good for some kinds of APIs, but it’s limiting because not >>> all APIs dispatch based on the URL. An AS might want to divvy up >>> access tokens to an API that’s keyed on headers, or verbs, or any >>> number of things. And it doesn’t tell us immediately what to do >>> about non-exact URL matches. Can the client add query parameters and >>> still use the token? What about path segments? I like that this >>> simple approach addresses some common deployments that we already >>> see today (see above), it’s not universal. Do we want or need a >>> universal description language for directing where tokens go? >>> >>> This also opens up a whole new set of security questions. If the AS >>> can now direct the client where to use the token, could a rogue AS >>> convince a legit client to use a stolen token at the wrong RS? And >>> what if the client ignores the directions from the AS entirely? >>> Could this open up new avenues of attack? >>> >>> This is just the start, too. Things get even more complex if the >>> client can ask for multiple different kinds of resources at once. >>> What if the AS decides that the client needs a hyper-focused >>> directed token for one part of the API, but can use a general token >>> for other stuff? Can it signal that to the client? And if it can, >>> does that mean that all clients need to be prepared for that kind of >>> thing? >>> >>> I firmly believe that whatever we build in GNAP, we need to optimize >>> for the overwhelmingly common use case of a client getting a single >>> access token to call APIs that it already knows about. Anything we >>> add on top of that really can’t get in the way of this, because if >>> it does, there’s very small chance that people will try to use this >>> for everyday things. Keep the simple things simple, and the complex >>> things possible, after all. >>> >>> I’m really looking forward to hearing what the community thinks >>> about these use cases, and hopefully the people I’ve chatted with >>> offline about this can join the conversation and provide more light >>> than I was able to. >> >> The two use cases which are considered above are: >> >> (1) The client knows what resource it’s calling, but it doesn’t >> know where it’s hosted. >> (2) The client knows what kind of thing it’s looking for, but >> doesn’t know who to ask it from. >> >> That does not mean in any way that these two use cases should be >> solved by placing the AS at the centre of the solution. >> >> Denis >> >>> >>>  — Justin >>> >> >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > --------------4A355BB991577811E6F62B20 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Justin, I fear we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I am getting tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it’s going to be overwhelmingly common that a given RS is going to trust exactly one AS
that it knows about ahead of time". Such an architecture would have exactly the same limitations as OAuth 2.0. and would not be scalable.

Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions.
For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believe that we have an agreement at this time on what
these trust relationships are.

You are also using the following wording: "methods for the AS and RS to communicate what the token’s good for".
With such a paradigm, it would be impossible to protect the user's privacy.

A key question is : Will GNAP take care of the user's privacy or will GNAP prevent to take care of the user's privacy ?

About "the ability for the client to get several access tokens to get different resources from one request" is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform
on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).

First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases.

When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS.
His "consent and choice" should then be obtained by the first RS and, when the user agrees, the client should then ask an access token
to one of the ASs trusted by the second RS in order to perform the subsequent operation. 

Denis

PS.  In an email sent on June 23 you wrote: " I think an on-device AS is an important use case".  I am sorry, but I don't understand.
       However, I do understand what "a server-based AS" is.


Denis, thanks for the great comments. I think that your trust model is pretty different from what I’d laid out initially, and while it’s an interesting and important one, it is not what I meant by “multiple access tokens” in my discussion below. I think that might be the cause of some disconnect here, but that doesn’t mean it’s out of reach for what the WG is after.

When I refer to multiple access tokens, and what the charter calls out as multiple access tokens, is the ability for the client to get several access tokens to get different resources from one request. I personally see this as an optimization of a specific set of use cases, some of which I discussed in my original email. There are others, I’m sure, but all the ones I’ve seen are around the client needing to get several different kinds of access through an AS. 

I think it’s going to be overwhelmingly common that a given RS is going to trust exactly one AS that it knows about ahead of time. But for RS’s that can trust multiple AS’s, then we should have a model that can accommodate that as well. That’s why the charter calls out methods for the AS and RS to communicate what the token’s good for. I think the basis of those methods is going to start with a common token model, and likely incorporate into things like token formats and introspection-style token APIs. 

 — Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the lines.

One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can’t, or at least can’t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don’t know if this concept has a regular term, so I’m going to call it “directed access tokens” until we come up with something better — assuming we decide this is worthwhile. 

I don't understand what may mean "directed access tokens” but I understand what means "multiple access tokens". 
When speaking of "multiple access tokens", these access tokens may come from one or more ASs.

In OAuth, the client’s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we’re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to. 

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of directions about what that specific token is good for. This needs to be information outside the token itself, since I believe we want to keep OAuth 2’s feature of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn’t enough to tell the client what to do with the token if it doesn’t know already. 

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I’ll try to summarize here, but I know the folks I’ve been talking to about this are also on the list so hopefully they can chime in with more detail or any corrections for something I’ve missed. 

(1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted. Everything is in a single security domain controlled by the AS, 

Speaking of "multiple access tokens" is in contradiction with single security domain "controlled" by an AS. 
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also 
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be 
the "primary issuer" of a university diploma. It should not be either a "secondary issuer", because 
the bank does not "need to know" what are the diplomas of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved in that step. 
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it. 

(2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from. 

Once again, the client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it. 

There’s a cross-domain trust that’s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver’s license information, but doesn’t know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn’t know yet who the user is. 

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at. 

 A single AS should not be aware of all the attributes a user has. 


As far as I know, in both of these cases, the token is only good for that API and not others — but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go. 

{
“access_token”: {
“value”: “87yui843yfer”,
“resource_uri”: “https://example/foo"
}
}

This is good for some kinds of APIs, but it’s limiting because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that’s keyed on headers, or verbs, or any number of things. And it doesn’t tell us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it’s not universal. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can’t get in the way of this, because if it does, there’s very small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I’m really looking forward to hearing what the community thinks about these use cases, and hopefully the people I’ve chatted with offline about this can join the conversation and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted.
(2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from. 

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Denis


 — Justin


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


--------------4A355BB991577811E6F62B20-- From nobody Wed Jun 24 03:35:09 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8C23A0D1D; Wed, 24 Jun 2020 03:35:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: gnap-chairs@ietf.org, txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <159299490123.4655.17681570227900008557@ietfa.amsl.com> Date: Wed, 24 Jun 2020 03:35:01 -0700 Archived-At: Subject: [Txauth] Alvaro Retana's No Objection on charter-ietf-gnap-00-00: (with COMMENT) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 10:35:02 -0000 Alvaro Retana has entered the following ballot position for charter-ietf-gnap-00-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-gnap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "...the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible." Should there be explicit chartered work about it? It didn't seem to me that any of the proposed milestones covered migration, potential impact on existing operations, etc.. From nobody Wed Jun 24 07:26:43 2020 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 E9FFB3A0E3C; Wed, 24 Jun 2020 07:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjT8qERfNvRd; Wed, 24 Jun 2020 07:26:36 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 1A39E3A0E1A; Wed, 24 Jun 2020 07:26:32 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05OEQVrh007443; Wed, 24 Jun 2020 10:26:31 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 05OEQVrh007443 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1593008791; bh=QJKvYL++KCpMsc0eK/LQ8iGxrEJVfU5KgCeA9XK6efg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=BLMRxawphkbj9MNvu4mohdQneBgt80/nTJH/ta02oAUApl/CTYmCXAaZ/RH/KQPFh VLkHV+VxGTusFc4Daf2NFswufZkc9qSogS8o35eNvl65HKKpusCJY+iLwU68fPoS7N DkwKeVOlJYuTn0IUVg2jggjJBbknKAN93etSTD4Q= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05OEQUK5040685; Wed, 24 Jun 2020 10:26:30 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 24 Jun 2020 10:26:29 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 24 Jun 2020 10:26:29 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Wed, 24 Jun 2020 10:26:29 -0400 From: Roman Danyliw To: Alvaro Retana , The IESG CC: "gnap-chairs@ietf.org" , "txauth@ietf.org" Thread-Topic: Alvaro Retana's No Objection on charter-ietf-gnap-00-00: (with COMMENT) Thread-Index: AQHWShMmTM5B6mNIEkuEL8de6P4/pqjnzBlQ Date: Wed, 24 Jun 2020 14:26:28 +0000 Message-ID: <50da1118514241b686e8c66ce7aff9d3@cert.org> References: <159299490123.4655.17681570227900008557@ietfa.amsl.com> In-Reply-To: <159299490123.4655.17681570227900008557@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.179] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Alvaro Retana's No Objection on charter-ietf-gnap-00-00: (with COMMENT) 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, 24 Jun 2020 14:26:38 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWVzZyA8aWVzZy1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQWx2YXJvIFJldGFuYSB2aWEgRGF0YXRyYWNrZXIN Cj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDI0LCAyMDIwIDY6MzUgQU0NCj4gVG86IFRoZSBJRVNH IDxpZXNnQGlldGYub3JnPg0KPiBDYzogZ25hcC1jaGFpcnNAaWV0Zi5vcmc7IHR4YXV0aEBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBBbHZhcm8gUmV0YW5hJ3MgTm8gT2JqZWN0aW9uIG9uIGNoYXJ0ZXIt aWV0Zi1nbmFwLTAwLTAwOiAod2l0aA0KPiBDT01NRU5UKQ0KPiANCj4gQWx2YXJvIFJldGFuYSBo YXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gY2hhcnRlci1p ZXRmLWduYXAtMDAtMDA6IE5vIE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+ IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRv IGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+ IA0KPiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2Fu IGJlIGZvdW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0 ZXItaWV0Zi1nbmFwLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gDQo+ICAgICIuLi50aGUgZ3JvdXAgd2lsbCBhdHRlbXB0IHRvIHNp bXBsaWZ5IG1pZ3JhdGluZyBmcm9tIE9BdXRoIDIuMCBhbmQgT3BlbklEDQo+ICAgIENvbm5lY3Qg dG8gdGhlIG5ldyBwcm90b2NvbCB3aGVyZSBwb3NzaWJsZS4iDQo+IA0KPiBTaG91bGQgdGhlcmUg YmUgZXhwbGljaXQgY2hhcnRlcmVkIHdvcmsgYWJvdXQgaXQ/ICBJdCBkaWRuJ3Qgc2VlbSB0byBt ZSB0aGF0IGFueQ0KPiBvZiB0aGUgcHJvcG9zZWQgbWlsZXN0b25lcyBjb3ZlcmVkIG1pZ3JhdGlv biwgcG90ZW50aWFsIGltcGFjdCBvbiBleGlzdGluZw0KPiBvcGVyYXRpb25zLCBldGMuLg0KDQpH b29kIHBvaW50Lg0KDQpUaGUgY3VycmVudCB0aGlua2luZyBpcyB0aGF0IHRoaXMgd291bGQgYSBk ZXNpZ24tdGltZSBjb25zaWRlcmF0aW9uIGZvciB0aGUgZXhpc3RpbmcgbWlsZXN0b25lIGl0ZW1z LiAgSG93ZXZlciwgdGhhdCBkb2Vzbid0IGNvdmVyIGV4cGxpY2l0IG1pZ3JhdGlvbiBndWlkYW5j ZS4gIFZlcnNpb24gMDAtMDEgbm93IGhhczoNCg0KLSAoaWYgbmVlZGVkKSBHdWlkZWxpbmVzIG9u IG1pZ3JhdGlvbiBwYXRocywgaW1wbGVtZW50YXRpb24sIGFuZCBvcGVyYXRpb25zDQoNClJlZ2Fy ZHMsDQpSb21hbg0KDQoNCj4gDQoNCg== From nobody Wed Jun 24 07:26:52 2020 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 DA37C3A0E5B; Wed, 24 Jun 2020 07:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id um-mnclowFHh; Wed, 24 Jun 2020 07:26:41 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 664513A0E60; Wed, 24 Jun 2020 07:26:41 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05OEQdbt007450; Wed, 24 Jun 2020 10:26:39 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 05OEQdbt007450 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1593008799; bh=XxrjS3vlnlPLIF5lRnAQtLh352hCBgQYfyomBxihihY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=SJHAC2tGtvDTHvVKsP1ZPxtY62E8/M7B4FwI8KVz0fmu8Yt6dMCncb+qISp2mmYk7 Q4qZEhDnsFaRnAQxOCK/sa2LMSA2vz6xlkw2TL2IKUES5OeuDps8Tnd0PEV8GehzuE /u7MyO7wr2JBPjUuz0kWfwRvHBlPjPvsSUmwyUYk= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05OEQa3w011631; Wed, 24 Jun 2020 10:26:36 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Wed, 24 Jun 2020 10:26:36 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 24 Jun 2020 10:26:35 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Wed, 24 Jun 2020 10:26:35 -0400 From: Roman Danyliw To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "gnap-chairs@ietf.org" , "txauth@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGNoYXJ0ZXItaWV0Zi1n?= =?utf-8?Q?nap-00-00:_(with_COMMENT)?= Thread-Index: AQHWSggLn3Hj3WBWJUavi5XZVJkTxqjnxpIA Date: Wed, 24 Jun 2020 14:26:34 +0000 Message-ID: References: <159299011836.10519.11264712678872270096@ietfa.amsl.com> In-Reply-To: <159299011836.10519.11264712678872270096@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.179] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-?= =?utf-8?q?ietf-gnap-00-00=3A_=28with_COMMENT=29?= 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, 24 Jun 2020 14:26:47 -0000 SGkgRXJpYyENCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgTW9yZSBpbmxpbmUgLi4uDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWVzZyA8aWVzZy1ib3VuY2VzQGll dGYub3JnPiBPbiBCZWhhbGYgT2Ygw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlcg0KPiBTZW50 OiBXZWRuZXNkYXksIEp1bmUgMjQsIDIwMjAgNToxNSBBTQ0KPiBUbzogVGhlIElFU0cgPGllc2dA aWV0Zi5vcmc+DQo+IENjOiBnbmFwLWNoYWlyc0BpZXRmLm9yZzsgdHhhdXRoQGlldGYub3JnDQo+ IFN1YmplY3Q6IMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBjaGFydGVyLWlldGYtZ25h cC0wMC0wMDogKHdpdGgNCj4gQ09NTUVOVCkNCj4gDQo+IMOJcmljIFZ5bmNrZSBoYXMgZW50ZXJl ZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gY2hhcnRlci1pZXRmLWduYXAt MDAtMDA6IE5vIE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0 aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlz IGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IA0KPiBUaGUg ZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5k IGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1n bmFwLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gDQo+IFNvbWUgcXVpY2sgY29tbWVudHM6DQo+IC0gdGhlIGNoYXJ0ZXIgaXRzZWxm IGlzIHJhdGhlciB2ZXJib3NlLCBzb21ldGltZXMgY29udm9sdXRlZCwgYW5kIG9mdGVuIGRpcmVj dGl2ZQ0KPiAobG9va2luZyBsaWtlIHRoZSBjaGFydGVyIGlzIGFib3V0IHJ1YmJlciBzdGFtcGlu ZyBleGlzdGluZyB3b3JrKSANCg0KWWVzLCBpdCBpcyBsb25nLiAgVGhlc2Ugd29yZHMgd2VyZSBj YXJlZnVsbHkgY2hvc2VuIGFmdGVyIGEgZGVsaWJlcmF0ZSwgaXRlcmF0aXZlIHByb2Nlc3MgdG8g Z2FpbiBjb25zZW5zdXMuICBObyBleGlzdGluZyB3b3JrIGlzIGdldHRpbmcgcnViYmVyIHN0YW1w ZWQgLS0gcXVpdGUgdGhlIGNvbnRyYXJ5LCB0aGVyZSBhcmUgYXQgbGVhc3QgdHdvIGNvbXBldGlu ZyBwcm9wb3NhbHMgdG8gZm9ybSB0aGUgYmFzaXMgb2YgdGhlIHN0YXJ0aW5nIHBvaW50LiANCg0K Pi0gbml0cyBwbGVhc2UNCj4gZXhwYW5kICJBUyIgYmVmb3JlIGZpcnN0IHVzZSANCg0KRml4ZWQg aW4gdmVyc2lvbiAwMC0wMS4NCg0KPiAtIG1pc3NpbmcgbWlsZXN0b25lcyBkYXRlcyA/IA0KDQpH b29kIHBvaW50LiAgSSdtIHdvcmtpbmcgb24gZ2V0dGluZyB0aGVzZSBkb2N1bWVudGVkLg0KDQo+ IC0gc2hvdWxkIHRoaXMgbmV3IFdHDQo+IHdvcmsgd2l0aCBvdGhlcnM/DQoNClllcy4gIFRoZSAw MC0wMSB2ZXJzaW9uIG5vdyBjb250YWluczoNCg0KIlRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY29v cGVyYXRlIGFuZCBjb29yZGluYXRlIHdpdGggb3RoZXIgSUVURiBXR3Mgc3VjaCBhcw0KT0FVVEgs IGFuZCB3b3JrIHdpdGggb3JnYW5pemF0aW9ucyBpbiB0aGUgY29tbXVuaXR5LCBzdWNoIGFzIHRo ZSBPcGVuSUQsIA0KYXMgYXBwcm9wcmlhdGUuIg0K From nobody Wed Jun 24 07:34:19 2020 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 6C18E3A0DDE; Wed, 24 Jun 2020 07:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ZCpiQ/Io; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BW7NrrSH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J69fA8PokcUe; Wed, 24 Jun 2020 07:34:13 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB143A0DF7; Wed, 24 Jun 2020 07:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3380; q=dns/txt; s=iport; t=1593009247; x=1594218847; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xkf5xMHv8DGzyYA7NdQZKXm4/ApJVpyVLIWE1pyAvGQ=; b=ZCpiQ/IoM7dCFlZoagiOe3hClWHPTYNFMzcmdvQpuK8J/Gq6YEX6zzQp tiCX7pK9agpI6Vwvi6RIh6/sKIbBbpc1tnHP3yrgbw0zXbsfbxMVkvr7F 3c68aho77tpQIKxagV7Ex2IRbMJdb1T+nfcQ9FnJyd9ssk7v6w10O5Ucr 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AsITUnBbf0DvV3SNAVB24Up3/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaTD47W8e4CjPDZ4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS83zfUGUpWe9vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAQB/Y/Ne/5JdJa1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTkEAQELAYFRUQdvWC8shCSDRgONQphXgUKBEANVCwEBAQw?= =?us-ascii?q?BASMKAgQBAYRHAheBfgIkNwYOAgMBAQsBAQUBAQECAQYEbYVbDIVyAQEBAQM?= =?us-ascii?q?SEREMAQEqCgMBCwQCAQgOAwMBAQEDAiYCAgIwFQUDCAIEAQ0FFA6DBAGCSwM?= =?us-ascii?q?uAQ6regKBOYhhdoEygwEBAQWBRkGDBhiCDgMGgQ4qAYJmhV8ahAMagUE/gRE?= =?us-ascii?q?nHIJNPoJcAgMBgSYBEgEhgxQzgi2PIIMRkWyQTgqCWohEkGsDHYJxiSWSbYQ?= =?us-ascii?q?ajR+KF5Q0AgQCBAUCDgEBBYFpI2ZwcBVlAYI+UBcCDY4eg3GFFIVCdDcCBgE?= =?us-ascii?q?HAQEDCQF7kFwBAQ?= X-IronPort-AV: E=Sophos;i="5.75,275,1589241600"; d="scan'208";a="779400135" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2020 14:34:05 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 05OEY5cZ001149 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Jun 2020 14:34:05 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 24 Jun 2020 09:34:04 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 24 Jun 2020 09:34:04 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 24 Jun 2020 09:34:04 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XVP+6N/MzF3J1fjIMTNRY/tryPWWDKAXu028XhEDmkEaX+dJB0MUjvJi685scZPM46GHORfzjvDDwc7VYO1ype6irhM5GT3i4yUweuczUwzUkDcFxxSCfhqdj1eslYRrsWSOKI3FomJwzn6rBZvgU5t7UyFJQTYjs/GSvp9KEOqizUuCGnn05uSkxjOtYd7IDd+N88mjb1jD2oM0iJV8nFieIyxfQfPHYpBUCywPgv0YImUy5zY6PSu8Ma6Q875MdiL3TkUCjvdFJOHSUWfMsBJOhrkz4tqXUuIindNRK9dv6Gt8JxRIBOocdAh6ebK9nx2pw7pjGYlhi19Jzosibw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xkf5xMHv8DGzyYA7NdQZKXm4/ApJVpyVLIWE1pyAvGQ=; b=XGvYjb9mYzrzjo3u2ZmZxb+VC05rJM2ORuCO0e/xOzH+BX3su6M6mZrw/8Ec3zTtGq0/2Q6zbVr33/0iCRC255lG20WXwUBWN9F6q2+EHXSy8Zh5tb/NTo7UxTJ8d3DSftxF6sWtc7csAljYtheQ4d9MEXG7UYJFBoBvHT3l09FPnhBoTGavz3iN8WRrIDKdTa+1chZGgJe038o6a0kn+EYKCc7jNwW1FZ0dHUj+ap5dPLYvIIWDkDWJWz1WBefnedo8C0I34L3/CzLabrW20HbNQPu27lvPM8c0lv/j9l/xNbp9qGT9/LGCg9pfCIheYvSpRH6tCO1COJ+zdyC/qg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xkf5xMHv8DGzyYA7NdQZKXm4/ApJVpyVLIWE1pyAvGQ=; b=BW7NrrSHxYKWs8UwGDYes8cIjLwPcXc5PGjp/OdTeW3CINRXjT1AAGrdVFUWSbgxldDdj0Z3Ko7RtN7nugEfJ77ydTWWGEkn8QCw/J+RznjokfeBH3mhBvwnfJsypwmSgKvzOgxMoa+uE4XSMT/1oX92D6TLcy9hsjQ1YhjGtiE= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM6PR11MB2921.namprd11.prod.outlook.com (2603:10b6:5:70::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Wed, 24 Jun 2020 14:34:03 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::a14c:59b6:47b0:f630%7]) with mapi id 15.20.3109.027; Wed, 24 Jun 2020 14:34:03 +0000 From: "Eric Vyncke (evyncke)" To: Roman Danyliw , The IESG CC: "gnap-chairs@ietf.org" , "txauth@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGNoYXJ0ZXItaWV0Zi1n?= =?utf-8?Q?nap-00-00:_(with_COMMENT)?= Thread-Index: AQHWSggNCPRfHJaJ0kK6pfZqiw3rVKjn0twAgAAjnoA= Date: Wed, 24 Jun 2020 14:34:03 +0000 Message-ID: <031B5799-AAAB-4D8C-A08C-3D722599BE3D@cisco.com> References: <159299011836.10519.11264712678872270096@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 authentication-results: cert.org; dkim=none (message not signed) header.d=none;cert.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:483:2b44:93a4:74ad] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5f17cb9c-4633-4ec6-29ba-08d8184ba4b0 x-ms-traffictypediagnostic: DM6PR11MB2921: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0444EB1997 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: q/Id7f6/R0W2xBUH72oRo9RCyc4tmeCE/nFCweimhr5fhpaSg3LNWYUcbk3uhOjiiZGXNbZLxJf12OkLj3D9uZS5siltC6zMND1hmjKbOd2ccSm+FWGNr7EVWilaIf4RO5DcqwCWGIxr4fLujQdvSdyuR2Apxzr0lIy0B/8XWUF8RjTw3DY8kGmmlG8ymPC3c+XjoLDSEYPQCm0N92yfjycRLEDPQdLmrsZTNyg2k031CnH7CU53oqDm6mEf+sgP5ajigr+cSHaME4iOeQF2yyFk5umbzXhnWGlR1vcTOhwlO1Dxq00coWRqW07rPposlKpze84EhkpK08adYeZVrt4nZIlErDVuXW0bbH1A+T9M02YRYrFLr3PRkyVjd82DRdXZue3gFPAz2ur/1AHySg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1753.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(366004)(346002)(376002)(396003)(2616005)(966005)(224303003)(33656002)(6486002)(186003)(54906003)(316002)(110136005)(91956017)(64756008)(66476007)(66446008)(66556008)(66946007)(2906002)(76116006)(6506007)(53546011)(4326008)(5660300002)(6512007)(83380400001)(478600001)(71200400001)(36756003)(86362001)(8936002)(66574015); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PboShEBx5sQhrC1hd1VT1jwXKev7kBlGWMKhlRBgjAz3oN7DIP3Ij4A2rCKmdKdjDDFKakHl6nMTJ3GI7bvo6wDITjLZ9hk+fbxOL+Cmcc8rQj4DZmlj9R3HZN/EA/J7SoWsvZtgWSdozd1LMYsNl52JenFgq20RuBFcvP98FjSo10TP2T7U6JyQtP52drf/xPjHf/5JJFHH/9i2MYyLt4oI/Brl1M6YmX5eVZXY2p9tAqt7hKsQLJ9/QeZnIOLk1JoLqYG5hl4QkZxWh98iDC/vqXpP4Nauo+79Wh1gf+n+fFSrAPZ7NUrJ/GxLizHmEDkCOP/c+b4XHShdC+ld75rRzsjoBHAk6FIKbMueEM2fj9RML+DjJxSJDpHW6J8pauuXGbjrllsqoypi+K3DQuOXgWOJ0cMOlvucUZ8BFcH2kvePpeHfWrrsVWFaIKK7JtBUVCfBWak5KBC6rBQRbrrfAUpk6QZJqmuJ7wZYFkkFXwONPzqrvDhRcLS6++ININyZ507/R3+YfB7K9a9CeUALq8KOtpR7NfbW7G6IMiM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <08284D69AB345145AAB672EA28350EA9@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR11MB1753.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f17cb9c-4633-4ec6-29ba-08d8184ba4b0 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2020 14:34:03.6867 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uRrqHeb8H28LCB7IZUKtfkTkpcau9F4LugcvLTxUr0dGNC5ojzlX+oqiBevoE47jS4lG/4LlJZ77FWGpm9JPxg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2921 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Txauth] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-?= =?utf-8?q?ietf-gnap-00-00=3A_=28with_COMMENT=29?= 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, 24 Jun 2020 14:34:16 -0000 Um9tYW4NCg0KVGhhbmsgeW91IGZvciByZXBseWluZyB0byBteSBxdWVzdGlvbnM6IGV2ZXJ5dGhp bmcgaXMgY2xlYXIgbm93IGZvciBtZS4NCg0KLcOpcmljDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+DQpEYXRlOiBXZWRu ZXNkYXksIDI0IEp1bmUgMjAyMCBhdCAxNjoyNg0KVG86IEVyaWMgVnluY2tlIDxldnluY2tlQGNp c2NvLmNvbT4sIFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6ICJnbmFwLWNoYWlyc0BpZXRm Lm9yZyIgPGduYXAtY2hhaXJzQGlldGYub3JnPiwgInR4YXV0aEBpZXRmLm9yZyIgPHR4YXV0aEBp ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gY2hh cnRlci1pZXRmLWduYXAtMDAtMDA6ICh3aXRoIENPTU1FTlQpDQoNCiAgICBIaSBFcmljIQ0KDQog ICAgVGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgTW9yZSBpbmxpbmUgLi4uDQoNCiAgICA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPiBGcm9tOiBpZXNnIDxpZXNnLWJvdW5jZXNAaWV0 Zi5vcmc+IE9uIEJlaGFsZiBPZiDDiXJpYyBWeW5ja2UgdmlhIERhdGF0cmFja2VyDQogICAgPiBT ZW50OiBXZWRuZXNkYXksIEp1bmUgMjQsIDIwMjAgNToxNSBBTQ0KICAgID4gVG86IFRoZSBJRVNH IDxpZXNnQGlldGYub3JnPg0KICAgID4gQ2M6IGduYXAtY2hhaXJzQGlldGYub3JnOyB0eGF1dGhA aWV0Zi5vcmcNCiAgICA+IFN1YmplY3Q6IMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBj aGFydGVyLWlldGYtZ25hcC0wMC0wMDogKHdpdGgNCiAgICA+IENPTU1FTlQpDQogICAgPiANCiAg ICA+IMOJcmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlv biBmb3INCiAgICA+IGNoYXJ0ZXItaWV0Zi1nbmFwLTAwLTAwOiBObyBPYmplY3Rpb24NCiAgICA+ IA0KICAgID4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGlu dGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQogICAgPiBhZGRyZXNzZXMgaW5jbHVkZWQgaW4g dGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkN CiAgICA+IHBhcmFncmFwaCwgaG93ZXZlci4pDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAg PiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJl IGZvdW5kIGhlcmU6DQogICAgPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFy dGVyLWlldGYtZ25hcC8NCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCiAgICA+IENPTU1FTlQ6DQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiANCiAgICA+IFNv bWUgcXVpY2sgY29tbWVudHM6DQogICAgPiAtIHRoZSBjaGFydGVyIGl0c2VsZiBpcyByYXRoZXIg dmVyYm9zZSwgc29tZXRpbWVzIGNvbnZvbHV0ZWQsIGFuZCBvZnRlbiBkaXJlY3RpdmUNCiAgICA+ IChsb29raW5nIGxpa2UgdGhlIGNoYXJ0ZXIgaXMgYWJvdXQgcnViYmVyIHN0YW1waW5nIGV4aXN0 aW5nIHdvcmspIA0KDQogICAgWWVzLCBpdCBpcyBsb25nLiAgVGhlc2Ugd29yZHMgd2VyZSBjYXJl ZnVsbHkgY2hvc2VuIGFmdGVyIGEgZGVsaWJlcmF0ZSwgaXRlcmF0aXZlIHByb2Nlc3MgdG8gZ2Fp biBjb25zZW5zdXMuICBObyBleGlzdGluZyB3b3JrIGlzIGdldHRpbmcgcnViYmVyIHN0YW1wZWQg LS0gcXVpdGUgdGhlIGNvbnRyYXJ5LCB0aGVyZSBhcmUgYXQgbGVhc3QgdHdvIGNvbXBldGluZyBw cm9wb3NhbHMgdG8gZm9ybSB0aGUgYmFzaXMgb2YgdGhlIHN0YXJ0aW5nIHBvaW50LiANCg0KICAg ID4tIG5pdHMgcGxlYXNlDQogICAgPiBleHBhbmQgIkFTIiBiZWZvcmUgZmlyc3QgdXNlIA0KDQog ICAgRml4ZWQgaW4gdmVyc2lvbiAwMC0wMS4NCg0KICAgID4gLSBtaXNzaW5nIG1pbGVzdG9uZXMg ZGF0ZXMgPyANCg0KICAgIEdvb2QgcG9pbnQuICBJJ20gd29ya2luZyBvbiBnZXR0aW5nIHRoZXNl IGRvY3VtZW50ZWQuDQoNCiAgICA+IC0gc2hvdWxkIHRoaXMgbmV3IFdHDQogICAgPiB3b3JrIHdp dGggb3RoZXJzPw0KDQogICAgWWVzLiAgVGhlIDAwLTAxIHZlcnNpb24gbm93IGNvbnRhaW5zOg0K DQogICAgIlRoZSB3b3JraW5nIGdyb3VwIHdpbGwgY29vcGVyYXRlIGFuZCBjb29yZGluYXRlIHdp dGggb3RoZXIgSUVURiBXR3Mgc3VjaCBhcw0KICAgIE9BVVRILCBhbmQgd29yayB3aXRoIG9yZ2Fu aXphdGlvbnMgaW4gdGhlIGNvbW11bml0eSwgc3VjaCBhcyB0aGUgT3BlbklELCANCiAgICBhcyBh cHByb3ByaWF0ZS4iDQoNCg== From nobody Wed Jun 24 08:15:28 2020 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 A262B3A0F16; Wed, 24 Jun 2020 08:15:26 -0700 (PDT) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 ZGrnq1cHiF7Y; Wed, 24 Jun 2020 08:15:24 -0700 (PDT) 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 7CCC73A0F12; Wed, 24 Jun 2020 08:15:24 -0700 (PDT) Received: from [192.168.1.14] (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 05OFFKiE017888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jun 2020 11:15:21 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Justin Richer In-Reply-To: <031B5799-AAAB-4D8C-A08C-3D722599BE3D@cisco.com> Date: Wed, 24 Jun 2020 11:15:20 -0400 Cc: "rdd@cert.org" , The IESG , "gnap-chairs@ietf.org" , "txauth@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <87E344AC-AFBD-4E9D-9933-754A474C8A58@mit.edu> References: <159299011836.10519.11264712678872270096@ietfa.amsl.com> <031B5799-AAAB-4D8C-A08C-3D722599BE3D@cisco.com> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-?= =?utf-8?q?ietf-gnap-00-00=3A_=28with_COMMENT=29?= 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, 24 Jun 2020 15:15:27 -0000 Good clarifications, thank you for the feedback!=20 One nit, for Roman: that should probably be =E2=80=9Cthe OpenID = Foundation=E2=80=9D. I would personally also add =E2=80=9Cthe Kantara = Initiative=E2=80=9D to the list, as that is the home of the User Managed = Access (UMA) work that is also directly influencing this. So a proposed = rewording: "The working group will cooperate and coordinate with other IETF WGs = such as OAUTH, and work with organizations in the community, such as the = OpenID Foundation and the Kantara Initiative, as appropriate." There are of course others, like W3C and DIF who are doing identity and = authenticator work that would plug into GNAP, but it is probably = overkill to list everyone, right?=20 All that said, this is a minor note. Even listing just =E2=80=9Cthe = OpenID Foundation=E2=80=9D without Kantara would be fine with me. =E2=80=94 Justin > On Jun 24, 2020, at 10:34 AM, Eric Vyncke (evyncke) = wrote: >=20 > Roman >=20 > Thank you for replying to my questions: everything is clear now for = me. >=20 > -=C3=A9ric >=20 > =EF=BB=BF-----Original Message----- > From: Roman Danyliw > Date: Wednesday, 24 June 2020 at 16:26 > To: Eric Vyncke , The IESG > Cc: "gnap-chairs@ietf.org" , "txauth@ietf.org" = > Subject: RE: =C3=89ric Vyncke's No Objection on = charter-ietf-gnap-00-00: (with COMMENT) >=20 > Hi Eric! >=20 > Thanks for the review. More inline ... >=20 >> -----Original Message----- >> From: iesg On Behalf Of =C3=89ric Vyncke via = Datatracker >> Sent: Wednesday, June 24, 2020 5:15 AM >> To: The IESG >> Cc: gnap-chairs@ietf.org; txauth@ietf.org >> Subject: =C3=89ric Vyncke's No Objection on charter-ietf-gnap-00-00: = (with >> COMMENT) >>=20 >> =C3=89ric Vyncke has entered the following ballot position for >> charter-ietf-gnap-00-00: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all = email >> addresses included in the To and CC lines. (Feel free to cut this = introductory >> paragraph, however.) >>=20 >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-gnap/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Some quick comments: >> - the charter itself is rather verbose, sometimes convoluted, and = often directive >> (looking like the charter is about rubber stamping existing work)=20 >=20 > Yes, it is long. These words were carefully chosen after a = deliberate, iterative process to gain consensus. No existing work is = getting rubber stamped -- quite the contrary, there are at least two = competing proposals to form the basis of the starting point.=20 >=20 >> - nits please >> expand "AS" before first use=20 >=20 > Fixed in version 00-01. >=20 >> - missing milestones dates ?=20 >=20 > Good point. I'm working on getting these documented. >=20 >> - should this new WG >> work with others? >=20 > Yes. The 00-01 version now contains: >=20 > "The working group will cooperate and coordinate with other IETF = WGs such as > OAUTH, and work with organizations in the community, such as the = OpenID,=20 > as appropriate." >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth From nobody Wed Jun 24 09:45:59 2020 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 02A3A3A10A2 for ; Wed, 24 Jun 2020 09:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 6ynz5qq_DaNY for ; Wed, 24 Jun 2020 09:45:55 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) by ietfa.amsl.com (Postfix) with ESMTP id ACE113A108F for ; Wed, 24 Jun 2020 09:45:54 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d52 with ME id v4eM2200D4FMSmm034eMvw; Wed, 24 Jun 2020 18:38:24 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 24 Jun 2020 18:38:24 +0200 X-ME-IP: 86.238.65.197 To: "Eric Vyncke (evyncke)" , Roman Danyliw , The IESG Cc: "gnap-chairs@ietf.org" , "txauth@ietf.org" References: <159299011836.10519.11264712678872270096@ietfa.amsl.com> <031B5799-AAAB-4D8C-A08C-3D722599BE3D@cisco.com> From: Denis Message-ID: <4185e819-21ef-3a03-535f-2acc99542b3f@free.fr> Date: Wed, 24 Jun 2020 18:38:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <031B5799-AAAB-4D8C-A08C-3D722599BE3D@cisco.com> Content-Type: multipart/alternative; boundary="------------1464F2AAB72CB7D5CCEA8492" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_charter-?= =?utf-8?q?ietf-gnap-00-00=3A_=28with_COMMENT=29?= 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, 24 Jun 2020 16:45:57 -0000 This is a multi-part message in MIME format. --------------1464F2AAB72CB7D5CCEA8492 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Eric, I reply as a member of this BoF. You are perfectly right when you write: "The charter itself is rather verbose, sometimes convoluted, and often directive (looking like the charter is about rubber stamping existing work)". The charter is far too long and not understandable (at least to me). I also got the impression that its goal is to rubber stamp two existing proposals. The charter is missing to explain the trust relationships and the privacy properties that will form the basis of the model and the major architecture differences (if any) with OAuth 2.0. I have some difficulties to understand how the replies you got are now making "everything clear for you", since there is no proposal to make the charter shorter (and clearer). Denis > Roman > > Thank you for replying to my questions: everything is clear now for me. > > -éric > > -----Original Message----- > From: Roman Danyliw > Date: Wednesday, 24 June 2020 at 16:26 > To: Eric Vyncke , The IESG > Cc: "gnap-chairs@ietf.org" , "txauth@ietf.org" > Subject: RE: Éric Vyncke's No Objection on charter-ietf-gnap-00-00: (with COMMENT) > > Hi Eric! > > Thanks for the review. More inline ... > > > -----Original Message----- > > From: iesg On Behalf Of Éric Vyncke via Datatracker > > Sent: Wednesday, June 24, 2020 5:15 AM > > To: The IESG > > Cc: gnap-chairs@ietf.org; txauth@ietf.org > > Subject: Éric Vyncke's No Objection on charter-ietf-gnap-00-00: (with > > COMMENT) > > > > Éric Vyncke has entered the following ballot position for > > charter-ietf-gnap-00-00: No Objection > > > > When responding, please keep the subject line intact and reply to all email > > addresses included in the To and CC lines. (Feel free to cut this introductory > > paragraph, however.) > > > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-gnap/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Some quick comments: > > - the charter itself is rather verbose, sometimes convoluted, and often directive > > (looking like the charter is about rubber stamping existing work) > > Yes, it is long. These words were carefully chosen after a deliberate, iterative process to gain consensus. No existing work is getting rubber stamped -- quite the contrary, there are at least two competing proposals to form the basis of the starting point. > > >- nits please > > expand "AS" before first use > > Fixed in version 00-01. > > > - missing milestones dates ? > > Good point. I'm working on getting these documented. > > > - should this new WG > > work with others? > > Yes. The 00-01 version now contains: > > "The working group will cooperate and coordinate with other IETF WGs such as > OAUTH, and work with organizations in the community, such as the OpenID, > as appropriate." > --------------1464F2AAB72CB7D5CCEA8492 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hello Eric,

I reply as a member of this BoF. You are perfectly right when you write:
"The charter itself is rather verbose, sometimes convoluted, and often directive (looking like the charter is about rubber stamping existing work)".
The charter is far too long and not understandable (at least to me). I also got the impression that its goal is to rubber stamp two existing proposals.

The charter is missing to explain the trust relationships and the privacy properties that will form the basis of the model and the major architecture differences
(if any) with OAuth 2.0.

I have some difficulties to understand how the replies you got are now making "everything clear for you", since there is no proposal to make the charter shorter (and clearer).

Denis

Roman

Thank you for replying to my questions: everything is clear now for me.

-éric

-----Original Message-----
From: Roman Danyliw <rdd@cert.org>
Date: Wednesday, 24 June 2020 at 16:26
To: Eric Vyncke <evyncke@cisco.com>, The IESG <iesg@ietf.org>
Cc: "gnap-chairs@ietf.org" <gnap-chairs@ietf.org>, "txauth@ietf.org" <txauth@ietf.org>
Subject: RE: Éric Vyncke's No Objection on charter-ietf-gnap-00-00: (with COMMENT)

    Hi Eric!

    Thanks for the review.  More inline ...

    > -----Original Message-----
    > From: iesg <iesg-bounces@ietf.org> On Behalf Of Éric Vyncke via Datatracker
    > Sent: Wednesday, June 24, 2020 5:15 AM
    > To: The IESG <iesg@ietf.org>
    > Cc: gnap-chairs@ietf.org; txauth@ietf.org
    > Subject: Éric Vyncke's No Objection on charter-ietf-gnap-00-00: (with
    > COMMENT)
    > 
    > Éric Vyncke has entered the following ballot position for
    > charter-ietf-gnap-00-00: No Objection
    > 
    > When responding, please keep the subject line intact and reply to all email
    > addresses included in the To and CC lines. (Feel free to cut this introductory
    > paragraph, however.)
    > 
    > 
    > 
    > The document, along with other ballot positions, can be found here:
    > https://datatracker.ietf.org/doc/charter-ietf-gnap/
    > 
    > 
    > 
    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------
    > 
    > Some quick comments:
    > - the charter itself is rather verbose, sometimes convoluted, and often directive
    > (looking like the charter is about rubber stamping existing work) 

    Yes, it is long.  These words were carefully chosen after a deliberate, iterative process to gain consensus.  No existing work is getting rubber stamped -- quite the contrary, there are at least two competing proposals to form the basis of the starting point. 

    >- nits please
    > expand "AS" before first use 

    Fixed in version 00-01.

    > - missing milestones dates ? 

    Good point.  I'm working on getting these documented.

    > - should this new WG
    > work with others?

    Yes.  The 00-01 version now contains:

    "The working group will cooperate and coordinate with other IETF WGs such as
    OAUTH, and work with organizations in the community, such as the OpenID, 
    as appropriate."


--------------1464F2AAB72CB7D5CCEA8492-- From nobody Wed Jun 24 11:11:23 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 178183A10A7; Wed, 24 Jun 2020 11:11:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: gnap-chairs@ietf.org, txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <159302228054.20699.8970656798339535215@ietfa.amsl.com> Date: Wed, 24 Jun 2020 11:11:21 -0700 Archived-At: Subject: [Txauth] Barry Leiba's No Objection on charter-ietf-gnap-00-01: (with COMMENT) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 18:11:21 -0000 Barry Leiba has entered the following ballot position for charter-ietf-gnap-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-gnap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- > (in contrast > with OAuth 2.0 which is initiated by the client redirecting the user’s > browser) Editorial nit: This needs a comma after “OAuth 2.0”. > The client and Authorization Server (AS) will involve a user to make > an authorization decision as necessary through interaction mechanisms > indicated by the protocol. This sentence seems very clumsy and unclear. The primary thing that bothers me is “mechanisms indicated by the protocol”: can we rephrase that to make it clearThe primary thing that bothers me is “mechanisms indicated by the protocol”: can we rephrase that to make it clearer what we’re talking about, perhaps by splitting the sentence, explaining what this means first, and then putting the rest of the sentence after it? Maybe something like this: NEW The protocol will include interaction mechanisms that . The client and Authorization Server (AS) will use those mechanisms to involve a user, as necessary, to make authorization decisions. END > - Support for directed, audience-restricted access tokens What does “audience-restricted” mean? Maybe this would be better phrased as, “Support for directed access tokens that restrict ” ? > - Optimized inclusion of additional information through the > delegation process (including identifiers and identity assertions) Editorial nit: the parenthetical is misplaced: NEW - Optimized inclusion of additional information (including identifiers and identity assertions) through the delegation process END > The group is chartered to develop mechanisms for conveying identity information > within the protocol including identifiers […] and assertions > […] > The group is > not chartered to develop new formats for identifiers or assertions It would be good to add “existing” after “including”, for emphasis. From nobody Wed Jun 24 20:20:26 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C92793A00C3; Wed, 24 Jun 2020 20:20:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: gnap-chairs@ietf.org, txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159305522436.11733.15198171728373227965@ietfa.amsl.com> Date: Wed, 24 Jun 2020 20:20:24 -0700 Archived-At: Subject: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 03:20:25 -0000 Benjamin Kaduk has entered the following ballot position for charter-ietf-gnap-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-gnap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This group is chartered to develop a fine-grained delegation protocol for authorization and API access, as well as requesting and providing user identifiers and claims. nit: this appears to parse as "providing user claims", and I'm not sure what that means. The protocol will decouple the interaction channels, such as the end user’s browser [...] "interaction channels" might be a term of art that needs clarification? The client and Authorization Server (AS) will involve a user to make an authorization decision as necessary through interaction mechanisms indicated by the protocol. >From a privacy perspective, will all of the information to be made available from the AS to the RS be visible to the user as they make this authorization decision? The group will define interoperability for this protocol between different parties, including - client and authorization server; - client and resource server; and - authorization server and resource server. [obligatory note that just because we define an AS/RS channel doesn't mean it will be required to use one at runtime, given the potential for self-contained tokens?] Additionally, the delegation process will allow for: [...] Do all of these need to be fully fleshed out in the main protocol spec, or could some of them be defered to future extensions? Some of them feel much more "core" than others, to me. - Support for directed, audience-restricted access tokens I think we need to clarify what "directed" is intended to mean here (if it's not just a synonym for "audience-restricted" in which case it should just be removed). - A variety of client applications, including Web, mobile, single-page, and interaction-constrained applications side note: this one feels like it would be easier to phrase as "the WG will seek to minimize assumptions about the form of client applications, allowing for [...]" - Mechanisms for conveying user, software, organization, and other pieces of information used in authorization decisions nit: the "pieces of information" is in a weird place. What are "user pieces of information"? (Also, this is a somewhat interesting place to put an extension point, though I concede that there will eventually be need for some kind of extension here .. it just seems like we should try to make use of this extension point a rare event.) - Optimized inclusion of additional information through the delegation process (including identifiers and identity assertions) This seems pretty open-ended and prone to risky things. E.g., even just a setup with multiple identifiers quickly becomes complicated in terms of being able to make precise statements about what specifically is being proven, whether there is a guaranteed relationship between the two (or more) identities in question, etc.; and this point seems even more open-ended than just that. Additionally, the group will provide mechanisms for management of the protocol lifecycle including: [...] - Mechanisms for the AS and RS to communicate the access granted by an access token Maybe I'm just confused, but isn't "the access granted by an access token" exactly the set of authorizations conveyed by that token, i.e., the core point of the protocol? I'm not sure what kind "protocol lifecycle management" this item is intending to indicate. This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be developed in the OAuth Working Group, including functionality back-ported from the protocol developed here to OAuth 2.0. Perhaps s/developed in/directed to/ -- we don't need this WG's charter to make statements that are more appropriate in the OAuth WG's charter. The group is chartered to develop mechanisms for conveying identity information within the protocol including identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available. This last bit is a decently sized loophole. If we leave it out that would force a recharter for picking up a new format, which might not be so bad. The working group will cooperate and coordinate with other IETF WGs such as OAUTH, and work with organizations in the community, such as the OpenID, as appropriate. nit: "organizations in the community" is an unusual phrase; I think "external organizations" is probably more common. From nobody Thu Jun 25 04:14:47 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FC83A0929; Thu, 25 Jun 2020 04:14:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: gnap-chairs@ietf.org, txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <159308368124.6770.7183059063906486945@ietfa.amsl.com> Date: Thu, 25 Jun 2020 04:14:41 -0700 Archived-At: Subject: [Txauth] Robert Wilton's No Objection on charter-ietf-gnap-00-01: (with COMMENT) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2020 11:14:42 -0000 Robert Wilton has entered the following ballot position for charter-ietf-gnap-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-gnap/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Should it be HTTP/2 and HTTP/3 instead of HTTP2 and HTTP3? From nobody Thu Jun 25 06:36:45 2020 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 31ED73A0B9B; Thu, 25 Jun 2020 06:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1KNEO_CY5bC; Thu, 25 Jun 2020 06:36:33 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 D93353A0B91; Thu, 25 Jun 2020 06:36:32 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05PDaUet005364; Thu, 25 Jun 2020 09:36:30 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 05PDaUet005364 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1593092191; bh=E8nK0a+JVv7q6MjsyRRQyIN5KHsuNE4hqzFKQ2aShLg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Fbqf3HBaDpRGlVKvArQZTki6II9MBu62CKCByZMXK5pREnd6uJojKUu8RAsbRJw/2 mAr0/25lyS1EVSUOzAIfW9XDr/DdAjdvsEn2qErQxeNhwI7miJ1IBO+zHa+EsK4gH6 m6ao6l5pXGPlOHHJgeBW/NdJOQjejS997IPXPwPQ= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05PDaSTJ004629; Thu, 25 Jun 2020 09:36:28 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 25 Jun 2020 09:36:27 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 25 Jun 2020 09:36:27 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Thu, 25 Jun 2020 09:36:27 -0400 From: Roman Danyliw To: Barry Leiba , The IESG CC: "gnap-chairs@ietf.org" , "txauth@ietf.org" Thread-Topic: Barry Leiba's No Objection on charter-ietf-gnap-00-01: (with COMMENT) Thread-Index: AQHWSlLjWdG1mBhDmkiU0o1qb0lODKjpTqig Date: Thu, 25 Jun 2020 13:36:26 +0000 Message-ID: References: <159302228054.20699.8970656798339535215@ietfa.amsl.com> In-Reply-To: <159302228054.20699.8970656798339535215@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.201.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Barry Leiba's No Objection on charter-ietf-gnap-00-01: (with COMMENT) 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, 25 Jun 2020 13:36:39 -0000 SGkgQmFycnksDQoNCkEgZmV3IHF1aWNrIHJlc3BvbnNlcy9lZGl0cyBiZWZvcmUgdGhlIHRlbGVj aGF0Lg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGllc2cgPGllc2ct Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJhcnJ5IExlaWJhIHZpYSBEYXRhdHJhY2tl cg0KPiBTZW50OiBXZWRuZXNkYXksIEp1bmUgMjQsIDIwMjAgMjoxMSBQTQ0KPiBUbzogVGhlIElF U0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBnbmFwLWNoYWlyc0BpZXRmLm9yZzsgdHhhdXRoQGll dGYub3JnDQo+IFN1YmplY3Q6IEJhcnJ5IExlaWJhJ3MgTm8gT2JqZWN0aW9uIG9uIGNoYXJ0ZXIt aWV0Zi1nbmFwLTAwLTAxOiAod2l0aA0KPiBDT01NRU5UKQ0KPiANCj4gQmFycnkgTGVpYmEgaGFz IGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGNoYXJ0ZXItaWV0 Zi1nbmFwLTAwLTAxOiBObyBPYmplY3Rpb24NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNl IGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbA0KPiBh ZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBj dXQgdGhpcyBpbnRyb2R1Y3RvcnkNCj4gcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiAN Cj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBi ZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVy LWlldGYtZ25hcC8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IA0KPiA+IChpbiBjb250cmFzdA0KPiA+IHdpdGggT0F1dGggMi4wIHdo aWNoIGlzIGluaXRpYXRlZCBieSB0aGUgY2xpZW50IHJlZGlyZWN0aW5nIHRoZSB1c2Vy4oCZcw0K PiA+IGJyb3dzZXIpDQo+IA0KPiBFZGl0b3JpYWwgbml0OiBUaGlzIG5lZWRzIGEgY29tbWEgYWZ0 ZXIg4oCcT0F1dGggMi4w4oCdLg0KDQpGaXhlZC4NCg0KPiA+IFRoZSBjbGllbnQgYW5kIEF1dGhv cml6YXRpb24gU2VydmVyIChBUykgd2lsbCBpbnZvbHZlIGEgdXNlciB0byBtYWtlDQo+ID4gYW4g YXV0aG9yaXphdGlvbiBkZWNpc2lvbiBhcyBuZWNlc3NhcnkgdGhyb3VnaCBpbnRlcmFjdGlvbiBt ZWNoYW5pc21zDQo+ID4gaW5kaWNhdGVkIGJ5IHRoZSBwcm90b2NvbC4NCj4gDQo+IFRoaXMgc2Vu dGVuY2Ugc2VlbXMgdmVyeSBjbHVtc3kgYW5kIHVuY2xlYXIuICBUaGUgcHJpbWFyeSB0aGluZyB0 aGF0IGJvdGhlcnMNCj4gbWUgaXMg4oCcbWVjaGFuaXNtcyBpbmRpY2F0ZWQgYnkgdGhlIHByb3Rv Y29s4oCdOiBjYW4gd2UgcmVwaHJhc2UgdGhhdCB0byBtYWtlIGl0DQo+IGNsZWFyVGhlIHByaW1h cnkgdGhpbmcgdGhhdCBib3RoZXJzIG1lIGlzIOKAnG1lY2hhbmlzbXMgaW5kaWNhdGVkIGJ5IHRo ZQ0KPiBwcm90b2NvbOKAnTogY2FuIHdlIHJlcGhyYXNlIHRoYXQgdG8gbWFrZSBpdCBjbGVhcmVy IHdoYXQgd2XigJlyZSB0YWxraW5nIGFib3V0LA0KPiBwZXJoYXBzIGJ5IHNwbGl0dGluZyB0aGUg c2VudGVuY2UsIGV4cGxhaW5pbmcgd2hhdCB0aGlzIG1lYW5zIGZpcnN0LCBhbmQgdGhlbg0KPiBw dXR0aW5nIHRoZSByZXN0IG9mIHRoZSBzZW50ZW5jZSBhZnRlciBpdD8gIE1heWJlIHNvbWV0aGlu ZyBsaWtlIHRoaXM6DQo+IA0KPiBORVcNCj4gVGhlIHByb3RvY29sIHdpbGwgaW5jbHVkZSBpbnRl cmFjdGlvbiBtZWNoYW5pc21zIHRoYXQgPHNvbWUgYnJpZWYNCj4gZXhwbGFuYXRpb24+Lg0KPiAg VGhlIGNsaWVudCBhbmQgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgKEFTKSB3aWxsIHVzZSB0aG9zZSBt ZWNoYW5pc21zIHRvIGludm9sdmUNCj4gYSB1c2VyLCBhcyBuZWNlc3NhcnksIHRvIG1ha2UgYXV0 aG9yaXphdGlvbiBkZWNpc2lvbnMuIEVORA0KDQpUb2RvLg0KDQo+ID4gLSBTdXBwb3J0IGZvciBk aXJlY3RlZCwgYXVkaWVuY2UtcmVzdHJpY3RlZCBhY2Nlc3MgdG9rZW5zDQo+IA0KPiBXaGF0IGRv ZXMg4oCcYXVkaWVuY2UtcmVzdHJpY3RlZOKAnSBtZWFuPyAgTWF5YmUgdGhpcyB3b3VsZCBiZSBi ZXR0ZXIgcGhyYXNlZA0KPiBhcywg4oCcU3VwcG9ydCBmb3IgZGlyZWN0ZWQgYWNjZXNzIHRva2Vu cyB0aGF0IHJlc3RyaWN0IDxleHBsYW5hdGlvbj7igJ0gPw0KDQpJJ2QgcHJlZmVyIHdlIG5vdCBj aGFuZ2UgdGhpcyB0ZXh0IHRvbyBtdWNoLiAgIkF1ZGllbmNlIHJlc3RyaWN0ZWQiIGlzIGEgdGVy bSBvZiBhcnQgaW4gdGhpcyBzcGFjZS4gIFNlZSBTZWN0aW9uIDQuOC4xLjMgb2YgZHJhZnQtaWV0 Zi1vYXV0aC1zZWN1cml0eS10b3BpY3MsIGRyYWZ0LWlldGYtb2F1dGgtcmVzb3VyY2UtaW5kaWNh dG9ycyBhbmQgZHJhZnQtaWV0Zi1vYXV0aC1yYXIuDQoNCj4gPiAtIE9wdGltaXplZCBpbmNsdXNp b24gb2YgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiB0aHJvdWdoIHRoZSBkZWxlZ2F0aW9uDQo+ID4g cHJvY2VzcyAoaW5jbHVkaW5nIGlkZW50aWZpZXJzIGFuZCBpZGVudGl0eSBhc3NlcnRpb25zKQ0K PiANCj4gRWRpdG9yaWFsIG5pdDogdGhlIHBhcmVudGhldGljYWwgaXMgbWlzcGxhY2VkOg0KPiAN Cj4gTkVXDQo+IC0gT3B0aW1pemVkIGluY2x1c2lvbiBvZiBhZGRpdGlvbmFsIGluZm9ybWF0aW9u IChpbmNsdWRpbmcgaWRlbnRpZmllcnMgYW5kDQo+IGlkZW50aXR5IGFzc2VydGlvbnMpIHRocm91 Z2ggdGhlIGRlbGVnYXRpb24gcHJvY2VzcyBFTkQNCg0KRml4ZWQuDQoNCj4gPiBUaGUgZ3JvdXAg aXMgY2hhcnRlcmVkIHRvIGRldmVsb3AgbWVjaGFuaXNtcyBmb3IgY29udmV5aW5nIGlkZW50aXR5 DQo+IGluZm9ybWF0aW9uID4gd2l0aGluIHRoZSBwcm90b2NvbCBpbmNsdWRpbmcgaWRlbnRpZmll cnMgW+KApl0gYW5kIGFzc2VydGlvbnMgPiBb4oCmXQ0KPiA+IFRoZSBncm91cCBpcyA+IG5vdCBj aGFydGVyZWQgdG8gZGV2ZWxvcCBuZXcgZm9ybWF0cyBmb3IgaWRlbnRpZmllcnMgb3INCj4gYXNz ZXJ0aW9ucw0KPiANCj4gSXQgd291bGQgYmUgZ29vZCB0byBhZGQg4oCcZXhpc3RpbmfigJ0gYWZ0 ZXIg4oCcaW5jbHVkaW5n4oCdLCBmb3IgZW1waGFzaXMuDQoNCkZpeGVkLg0KDQpSZWdhcmRzLA0K Um9tYW4NCg0K From nobody Thu Jun 25 06:36:55 2020 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 CE2B33A0A56; Thu, 25 Jun 2020 06:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkyEwD9hop3R; Thu, 25 Jun 2020 06:36:41 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC073A0A3A; Thu, 25 Jun 2020 06:36:41 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05PDaeMS030969; Thu, 25 Jun 2020 09:36:40 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 05PDaeMS030969 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1593092200; bh=XVzvnpxbD46AvuJotuVOCd6KefW3fVmxgpUH4DQz6ws=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=LNHbsdXjeBpApUN4ad8HicWQm4lgZE0aYxyapGIk6o22nQFF2Fb5kxqbXzBAPk59W VEj2N/U0DVd9VFbKq/akKq/FzFTY65MN5GwsPwtl95o3njme2EzmLOMud+zKATVzPF +xF6LmNB3bBdTLgTUJ5dpRCUX+zyXYKfQC5d+euo= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05PDad5E011413; Thu, 25 Jun 2020 09:36:39 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 25 Jun 2020 09:36:39 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 25 Jun 2020 09:36:38 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Thu, 25 Jun 2020 09:36:38 -0400 From: Roman Danyliw To: Benjamin Kaduk , The IESG CC: "gnap-chairs@ietf.org" , "txauth@ietf.org" Thread-Topic: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT) Thread-Index: AQHWSp+mfNB0WcCRrESVJnDDV24D0KjpTf1g Date: Thu, 25 Jun 2020 13:36:36 +0000 Message-ID: References: <159305522436.11733.15198171728373227965@ietfa.amsl.com> In-Reply-To: <159305522436.11733.15198171728373227965@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.201.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT) 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, 25 Jun 2020 13:36:53 -0000 SGkgQmVuIQ0KDQpBIGZldyBxdWljaywgYnV0IGluY29tcGxldGUsIHJlc3BvbnNlcy9lZGl0cyBi ZWZvcmUgdGhlIHRlbGVjaGF0Lg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBCZW5qYW1p biBLYWR1ayB2aWENCj4gRGF0YXRyYWNrZXINCj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDI0LCAy MDIwIDExOjIwIFBNDQo+IFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IGduYXAt Y2hhaXJzQGlldGYub3JnOyB0eGF1dGhAaWV0Zi5vcmcNCj4gU3ViamVjdDogW1R4YXV0aF0gQmVu amFtaW4gS2FkdWsncyBObyBPYmplY3Rpb24gb24gY2hhcnRlci1pZXRmLWduYXAtMDAtMDE6DQo+ ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBCZW5qYW1pbiBLYWR1ayBoYXMgZW50ZXJlZCB0aGUgZm9s bG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gY2hhcnRlci1pZXRmLWduYXAtMDAtMDE6IE5v IE9iamVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVj dCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRl ZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVj dG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IA0KPiBUaGUgZG9jdW1lbnQs IGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1nbmFwLw0KPiAN Cj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g DQo+ICAgVGhpcyBncm91cCBpcyBjaGFydGVyZWQgdG8gZGV2ZWxvcCBhIGZpbmUtZ3JhaW5lZCBk ZWxlZ2F0aW9uIHByb3RvY29sDQo+ICAgZm9yIGF1dGhvcml6YXRpb24gYW5kIEFQSSBhY2Nlc3Ms IGFzIHdlbGwgYXMgcmVxdWVzdGluZyBhbmQgcHJvdmlkaW5nDQo+ICAgdXNlciBpZGVudGlmaWVy cyBhbmQgY2xhaW1zLg0KPiANCj4gbml0OiB0aGlzIGFwcGVhcnMgdG8gcGFyc2UgYXMgInByb3Zp ZGluZyB1c2VyIGNsYWltcyIsIGFuZCBJJ20gbm90IHN1cmUgd2hhdCB0aGF0DQo+IG1lYW5zLg0K DQpUT0RPDQoNCj4gICBUaGUgcHJvdG9jb2wgd2lsbCBkZWNvdXBsZSB0aGUgaW50ZXJhY3Rpb24g Y2hhbm5lbHMsIHN1Y2ggYXMgdGhlIGVuZA0KPiAgIHVzZXLigJlzIGJyb3dzZXIgWy4uLl0NCj4g DQo+ICJpbnRlcmFjdGlvbiBjaGFubmVscyIgbWlnaHQgYmUgYSB0ZXJtIG9mIGFydCB0aGF0IG5l ZWRzIGNsYXJpZmljYXRpb24/DQoNClRPRE8NCg0KPiAgIFRoZSBjbGllbnQgYW5kIEF1dGhvcml6 YXRpb24gU2VydmVyIChBUykgd2lsbCBpbnZvbHZlIGEgdXNlciB0byBtYWtlDQo+ICAgYW4gYXV0 aG9yaXphdGlvbiBkZWNpc2lvbiBhcyBuZWNlc3NhcnkgdGhyb3VnaCBpbnRlcmFjdGlvbiBtZWNo YW5pc21zDQo+ICAgaW5kaWNhdGVkIGJ5IHRoZSBwcm90b2NvbC4NCj4gDQo+ID5Gcm9tIGEgcHJp dmFjeSBwZXJzcGVjdGl2ZSwgd2lsbCBhbGwgb2YgdGhlIGluZm9ybWF0aW9uIHRvIGJlIG1hZGUN Cj4gYXZhaWxhYmxlIGZyb20gdGhlIEFTIHRvIHRoZSBSUyBiZSB2aXNpYmxlIHRvIHRoZSB1c2Vy IGFzIHRoZXkgbWFrZSB0aGlzDQo+IGF1dGhvcml6YXRpb24gZGVjaXNpb24/DQoNClRPRE8NCg0K PiAgIFRoZSBncm91cCB3aWxsIGRlZmluZSBpbnRlcm9wZXJhYmlsaXR5IGZvciB0aGlzIHByb3Rv Y29sIGJldHdlZW4gZGlmZmVyZW50DQo+ICAgcGFydGllcywgaW5jbHVkaW5nDQo+ICAgIC0gY2xp ZW50IGFuZCBhdXRob3JpemF0aW9uIHNlcnZlcjsNCj4gICAgLSBjbGllbnQgYW5kIHJlc291cmNl IHNlcnZlcjsgYW5kDQo+ICAgIC0gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHJlc291cmNlIHNl cnZlci4NCj4gDQo+IFtvYmxpZ2F0b3J5IG5vdGUgdGhhdCBqdXN0IGJlY2F1c2Ugd2UgZGVmaW5l IGFuIEFTL1JTIGNoYW5uZWwgZG9lc24ndCBtZWFuIGl0DQo+IHdpbGwgYmUgcmVxdWlyZWQgdG8g dXNlIG9uZSBhdCBydW50aW1lLCBnaXZlbiB0aGUgcG90ZW50aWFsIGZvciBzZWxmLWNvbnRhaW5l ZA0KPiB0b2tlbnM/XQ0KDQpBcmUgeW91IHRoaW5raW5nIHRoYXQgY2xhcmlmaWNhdGlvbiB3b3Vs ZCBiZSBleHBsaWNpdGx5IHN0YXRlZD8NCg0KPiAgIEFkZGl0aW9uYWxseSwgdGhlIGRlbGVnYXRp b24gcHJvY2VzcyB3aWxsIGFsbG93IGZvcjoNCj4gICBbLi4uXQ0KPiANCj4gRG8gYWxsIG9mIHRo ZXNlIG5lZWQgdG8gYmUgZnVsbHkgZmxlc2hlZCBvdXQgaW4gdGhlIG1haW4gcHJvdG9jb2wgc3Bl Yywgb3IgY291bGQNCj4gc29tZSBvZiB0aGVtIGJlIGRlZmVyZWQgdG8gZnV0dXJlIGV4dGVuc2lv bnM/ICBTb21lIG9mIHRoZW0gZmVlbCBtdWNoIG1vcmUNCj4gImNvcmUiIHRoYW4gb3RoZXJzLCB0 byBtZS4NCg0KRmFpci4gIElNTywgdGhlIFdHIG5lZWRzIHRvIGhhdmUgYSBkaXNjdXNzaW9uIGFi b3V0IGhvdyB0byBhcHByb3ByaWF0ZWx5IGRlY29tcG9zZSB0aGVzZSBjYXBhYmlsaXRpZXMsIG9u Y2UgdGhlcmUgaXMgYW4gdW5kZXJzdG9vZCBzY29wZS4gIEknbSBub3Qgc3VyZSB3ZSBuZWVkIHRv IGRlY2lkZSBub3cgd2hhdCBjYXBhYmlsaXRpZXMgYXJlIGluIHRoZSAiY29yZSIgdnMuIGZvbGxv dy1vbiBleHRlbnNpb25zLg0KDQo+ICAgLSBTdXBwb3J0IGZvciBkaXJlY3RlZCwgYXVkaWVuY2Ut cmVzdHJpY3RlZCBhY2Nlc3MgdG9rZW5zDQo+IA0KPiBJIHRoaW5rIHdlIG5lZWQgdG8gY2xhcmlm eSB3aGF0ICJkaXJlY3RlZCIgaXMgaW50ZW5kZWQgdG8gbWVhbiBoZXJlIChpZiBpdCdzIG5vdA0K PiBqdXN0IGEgc3lub255bSBmb3IgImF1ZGllbmNlLXJlc3RyaWN0ZWQiIGluIHdoaWNoIGNhc2Ug aXQgc2hvdWxkIGp1c3QgYmUNCj4gcmVtb3ZlZCkuDQoNClRPRE8NCg0KPiAgIC0gQSB2YXJpZXR5 IG9mIGNsaWVudCBhcHBsaWNhdGlvbnMsIGluY2x1ZGluZyBXZWIsIG1vYmlsZSwNCj4gICAgIHNp bmdsZS1wYWdlLCBhbmQgaW50ZXJhY3Rpb24tY29uc3RyYWluZWQgYXBwbGljYXRpb25zDQo+DQo+ IHNpZGUgbm90ZTogdGhpcyBvbmUgZmVlbHMgbGlrZSBpdCB3b3VsZCBiZSBlYXNpZXIgdG8gcGhy YXNlIGFzICJ0aGUgV0cgd2lsbCBzZWVrDQo+IHRvIG1pbmltaXplIGFzc3VtcHRpb25zIGFib3V0 IHRoZSBmb3JtIG9mIGNsaWVudCBhcHBsaWNhdGlvbnMsIGFsbG93aW5nIGZvcg0KPiBbLi4uXSIN Cg0KVE9ETw0KIA0KPiAgIC0gTWVjaGFuaXNtcyBmb3IgY29udmV5aW5nIHVzZXIsIHNvZnR3YXJl LCBvcmdhbml6YXRpb24sIGFuZCBvdGhlcg0KPiAgICAgcGllY2VzIG9mIGluZm9ybWF0aW9uIHVz ZWQgaW4gYXV0aG9yaXphdGlvbiBkZWNpc2lvbnMNCj4gDQo+IG5pdDogdGhlICJwaWVjZXMgb2Yg aW5mb3JtYXRpb24iIGlzIGluIGEgd2VpcmQgcGxhY2UuICBXaGF0IGFyZSAidXNlciBwaWVjZXMg b2YNCj4gaW5mb3JtYXRpb24iPw0KDQpFZGl0b3JpYWxseSwgdGhlIHJlYWQgc2hvdWxkIGJlICJ1 c2VyIFtpbmZvcm1hdGlvbl0sIHNvZnR3YXJlIFtpbmZvcm1hdGlvbl0sIGV0Yy4iLg0KDQpSZW1v dmVkICJwaWVjZXMgb2YiLg0KDQo+IChBbHNvLCB0aGlzIGlzIGEgc29tZXdoYXQgaW50ZXJlc3Rp bmcgcGxhY2UgdG8gcHV0IGFuIGV4dGVuc2lvbiBwb2ludCwgdGhvdWdoIEkNCj4gY29uY2VkZSB0 aGF0IHRoZXJlIHdpbGwgZXZlbnR1YWxseSBiZSBuZWVkIGZvciBzb21lIGtpbmQgb2YgZXh0ZW5z aW9uIGhlcmUgLi4gaXQNCj4ganVzdCBzZWVtcyBsaWtlIHdlIHNob3VsZCB0cnkgdG8gbWFrZSB1 c2Ugb2YgdGhpcyBleHRlbnNpb24gcG9pbnQgYSByYXJlIGV2ZW50LikNCj4gDQo+ICAgLSBPcHRp bWl6ZWQgaW5jbHVzaW9uIG9mIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdGhyb3VnaCB0aGUNCj4g ICBkZWxlZ2F0aW9uIHByb2Nlc3MgKGluY2x1ZGluZyBpZGVudGlmaWVycyBhbmQgaWRlbnRpdHkg YXNzZXJ0aW9ucykNCj4gDQo+IFRoaXMgc2VlbXMgcHJldHR5IG9wZW4tZW5kZWQgYW5kIHByb25l IHRvIHJpc2t5IHRoaW5ncy4gIEUuZy4sIGV2ZW4ganVzdCBhIHNldHVwDQo+IHdpdGggbXVsdGlw bGUgaWRlbnRpZmllcnMgcXVpY2tseSBiZWNvbWVzIGNvbXBsaWNhdGVkIGluIHRlcm1zIG9mIGJl aW5nIGFibGUgdG8NCj4gbWFrZSBwcmVjaXNlIHN0YXRlbWVudHMgYWJvdXQgd2hhdCBzcGVjaWZp Y2FsbHkgaXMgYmVpbmcgcHJvdmVuLCB3aGV0aGVyIHRoZXJlDQo+IGlzIGEgZ3VhcmFudGVlZCBy ZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgdHdvIChvciBtb3JlKSBpZGVudGl0aWVzIGluIHF1ZXN0 aW9uLA0KPiBldGMuOyBhbmQgdGhpcyBwb2ludCBzZWVtcyBldmVuIG1vcmUgb3Blbi1lbmRlZCB0 aGFuIGp1c3QgdGhhdC4NCg0KU28gdGhlIHRoaW5raW5nIGlzIHRvIHNjb3BlIGRvd24gd2hhdCB0 aGF0ICJhZGRpdGlvbmFsIGluZm9ybWF0aW9uIiBtaWdodCBiZT8NCg0KPiAgIEFkZGl0aW9uYWxs eSwgdGhlIGdyb3VwIHdpbGwgcHJvdmlkZSBtZWNoYW5pc21zIGZvciBtYW5hZ2VtZW50IG9mIHRo ZQ0KPiAgIHByb3RvY29sIGxpZmVjeWNsZSBpbmNsdWRpbmc6DQo+ICAgWy4uLl0NCj4gICAtIE1l Y2hhbmlzbXMgZm9yIHRoZSBBUyBhbmQgUlMgdG8gY29tbXVuaWNhdGUgdGhlIGFjY2VzcyBncmFu dGVkIGJ5IGFuDQo+ICAgICBhY2Nlc3MgdG9rZW4NCj4gDQo+IE1heWJlIEknbSBqdXN0IGNvbmZ1 c2VkLCBidXQgaXNuJ3QgInRoZSBhY2Nlc3MgZ3JhbnRlZCBieSBhbiBhY2Nlc3MgdG9rZW4iDQo+ IGV4YWN0bHkgdGhlIHNldCBvZiBhdXRob3JpemF0aW9ucyBjb252ZXllZCBieSB0aGF0IHRva2Vu LCBpLmUuLCB0aGUgY29yZSBwb2ludCBvZg0KPiB0aGUgcHJvdG9jb2w/ICBJJ20gbm90IHN1cmUg d2hhdCBraW5kICJwcm90b2NvbCBsaWZlY3ljbGUgbWFuYWdlbWVudCIgdGhpcw0KPiBpdGVtIGlz IGludGVuZGluZyB0byBpbmRpY2F0ZS4NCg0KVE9ETw0KDQo+ICAgVGhpcyBncm91cCBpcyBub3Qg Y2hhcnRlcmVkIHRvIGRldmVsb3AgZXh0ZW5zaW9ucyB0byBPQXV0aCAyLjAsIGFuZCBhcw0KPiAg IHN1Y2ggd2lsbCBmb2N1cyBvbiBuZXcgdGVjaG5vbG9naWNhbCBzb2x1dGlvbnMgbm90IG5lY2Vz c2FyaWx5DQo+ICAgY29tcGF0aWJsZSB3aXRoIE9BdXRoIDIuMC4gRnVuY3Rpb25hbGl0eSB0aGF0 IGJ1aWxkcyBkaXJlY3RseSBvbiBPQXV0aA0KPiAgIDIuMCB3aWxsIGJlIGRldmVsb3BlZCBpbiB0 aGUgT0F1dGggV29ya2luZyBHcm91cCwgaW5jbHVkaW5nDQo+ICAgZnVuY3Rpb25hbGl0eSBiYWNr LXBvcnRlZCBmcm9tIHRoZSBwcm90b2NvbCBkZXZlbG9wZWQgaGVyZSB0byBPQXV0aCAyLjAuDQo+ IA0KPiBQZXJoYXBzIHMvZGV2ZWxvcGVkIGluL2RpcmVjdGVkIHRvLyAtLSB3ZSBkb24ndCBuZWVk IHRoaXMgV0cncyBjaGFydGVyIHRvIG1ha2UNCj4gc3RhdGVtZW50cyB0aGF0IGFyZSBtb3JlIGFw cHJvcHJpYXRlIGluIHRoZSBPQXV0aCBXRydzIGNoYXJ0ZXIuDQoNCkZpeGVkLg0KDQo+ICAgVGhl IGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byBkZXZlbG9wIG1lY2hhbmlzbXMgZm9yIGNvbnZleWluZyBp ZGVudGl0eQ0KPiAgIGluZm9ybWF0aW9uIHdpdGhpbiB0aGUgcHJvdG9jb2wgaW5jbHVkaW5nIGlk ZW50aWZpZXJzIChzdWNoIGFzIGVtYWlsDQo+ICAgYWRkcmVzc2VzLCBwaG9uZSBudW1iZXJzLCB1 c2VybmFtZXMsIGFuZCBzdWJqZWN0IGlkZW50aWZpZXJzKSBhbmQNCj4gICBhc3NlcnRpb25zIChz dWNoIGFzIE9wZW5JRCBDb25uZWN0IElEIFRva2VucywgU0FNTCBBc3NlcnRpb25zLCBhbmQNCj4g ICBWZXJpZmlhYmxlIENyZWRlbnRpYWxzKS4gVGhlIGdyb3VwIGlzIG5vdCBjaGFydGVyZWQgdG8g ZGV2ZWxvcCBuZXcNCj4gICBmb3JtYXRzIGZvciBpZGVudGlmaWVycyBvciBhc3NlcnRpb25zLCBu b3IgaXMgdGhlIGdyb3VwIGNoYXJ0ZXJlZCB0bw0KPiAgIGRldmVsb3Agc2NoZW1hcyBmb3IgdXNl ciBpbmZvcm1hdGlvbiwgcHJvZmlsZXMsIG9yIG90aGVyIGlkZW50aXR5DQo+ICAgYXR0cmlidXRl cywgdW5sZXNzIGEgdmlhYmxlIGV4aXN0aW5nIGZvcm1hdCBpcyBub3QgYXZhaWxhYmxlLg0KPiAN Cj4gVGhpcyBsYXN0IGJpdCBpcyBhIGRlY2VudGx5IHNpemVkIGxvb3Bob2xlLiAgSWYgd2UgbGVh dmUgaXQgb3V0IHRoYXQgd291bGQgZm9yY2UgYQ0KPiByZWNoYXJ0ZXIgZm9yIHBpY2tpbmcgdXAg YSBuZXcgZm9ybWF0LCB3aGljaCBtaWdodCBub3QgYmUgc28gYmFkLg0KDQpJbiB0aGUgY29uc2Vu c3VzIGJ1aWxkaW5nIHRvIHByb2R1Y2UgdGhpcyB0ZXh0LCBpdCBzZWVtZWQgaGVscGZ1bCB0byBi ZSBjbGVhciBvbiB3aGF0J3MgaW4gYW5kIG91dC4NCg0KVG8gYmUgY2xlYXIsIGlzIHlvdXIgY29u Y2VybiB0aGF0IHRoZSB0ZXh0ICIuLi4gdW5sZXNzIGEgdmlhYmxlIGV4aXN0aW5nIGZvcm1hdCBp cyBub3QgYXZhaWxhYmxlIiBpcyB0aGUgbG9vcGhvbGU/DQoNCj4gICBUaGUgd29ya2luZyBncm91 cCB3aWxsIGNvb3BlcmF0ZSBhbmQgY29vcmRpbmF0ZSB3aXRoIG90aGVyIElFVEYgV0dzIHN1Y2gN Cj4gICBhcyBPQVVUSCwgYW5kIHdvcmsgd2l0aCBvcmdhbml6YXRpb25zIGluIHRoZSBjb21tdW5p dHksIHN1Y2ggYXMgdGhlDQo+ICAgT3BlbklELCBhcyBhcHByb3ByaWF0ZS4NCj4gDQo+IG5pdDog Im9yZ2FuaXphdGlvbnMgaW4gdGhlIGNvbW11bml0eSIgaXMgYW4gdW51c3VhbCBwaHJhc2U7IEkg dGhpbmsgImV4dGVybmFsDQo+IG9yZ2FuaXphdGlvbnMiIGlzIHByb2JhYmx5IG1vcmUgY29tbW9u Lg0KDQpGaXhlZC4gIChXYXMgY3V0LWFuZC1wYXN0ZWQgZnJvbSB0aGUgUkFUUyBjaGFydGVyKQ0K DQpSZWdhcmRzLA0KUm9tYW4NCg== From nobody Thu Jun 25 06:38:24 2020 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 605CD3A0A35; Thu, 25 Jun 2020 06:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjfo6ewTG-ax; Thu, 25 Jun 2020 06:38:18 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B9D3A0A39; Thu, 25 Jun 2020 06:38:17 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05PDcFtB031229; Thu, 25 Jun 2020 09:38:15 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 05PDcFtB031229 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1593092295; bh=MtWotB5lug7plKihQTUvFeRu8kAYd5NV/igQFG5+1mA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=kQVGVC9jC6VxtM6Oz5k9Gg526IwLkejiy3ifpGkG31HiPVJ9I/aVe1+Iuehv1nOR0 6J7+KkDK13dS2SVnDXvHPfe9QGFLxa/SuyCR0hIxzXg4/aMAAsWkoqeLOPO9H6shuE oVhKyKO5m9X4DETonB70Jgeerdxh4sDVZmfoqNZQ= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05PDcEgX011810; Thu, 25 Jun 2020 09:38:14 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 25 Jun 2020 09:38:14 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 25 Jun 2020 09:38:14 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Thu, 25 Jun 2020 09:38:14 -0400 From: Roman Danyliw To: Robert Wilton , The IESG CC: "gnap-chairs@ietf.org" , "txauth@ietf.org" Thread-Topic: Robert Wilton's No Objection on charter-ietf-gnap-00-01: (with COMMENT) Thread-Index: AQHWSuHfq81eiNtR606KdJ212bsb96jpVbVg Date: Thu, 25 Jun 2020 13:38:13 +0000 Message-ID: <1398bd7587f54af691ca5dac20064c25@cert.org> References: <159308368124.6770.7183059063906486945@ietfa.amsl.com> In-Reply-To: <159308368124.6770.7183059063906486945@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.201.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Robert Wilton's No Objection on charter-ietf-gnap-00-01: (with COMMENT) 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, 25 Jun 2020 13:38:20 -0000 SGkhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWVzZyA8aWVzZy1i b3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUm9iZXJ0IFdpbHRvbiB2aWEgRGF0YXRyYWNr ZXINCj4gU2VudDogVGh1cnNkYXksIEp1bmUgMjUsIDIwMjAgNzoxNSBBTQ0KPiBUbzogVGhlIElF U0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBnbmFwLWNoYWlyc0BpZXRmLm9yZzsgdHhhdXRoQGll dGYub3JnDQo+IFN1YmplY3Q6IFJvYmVydCBXaWx0b24ncyBObyBPYmplY3Rpb24gb24gY2hhcnRl ci1pZXRmLWduYXAtMDAtMDE6ICh3aXRoDQo+IENPTU1FTlQpDQo+IA0KPiBSb2JlcnQgV2lsdG9u IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBjaGFydGVy LWlldGYtZ25hcC0wMC0wMTogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBs ZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwN Cj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUg dG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiAN Cj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBj YW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hh cnRlci1pZXRmLWduYXAvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gU2hvdWxkIGl0IGJlIEhUVFAvMiBhbmQgSFRUUC8zIGlu c3RlYWQgb2YgSFRUUDIgYW5kIEhUVFAzPw0KDQpHb29kIGNhdGNoLiAgRml4ZWQgaW4gMDAtMDIu DQoNClJlZ2FyZHMsDQpSb21hbg0KDQoNCg0K From nobody Thu Jun 25 12:07:04 2020 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 639373A0FD4; Thu, 25 Jun 2020 12:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 Aopb5VbJaq4f; Thu, 25 Jun 2020 12:06:57 -0700 (PDT) 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 166153A0FD3; Thu, 25 Jun 2020 12:06:56 -0700 (PDT) Received: from [192.168.1.14] (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 05PJ6rbn000532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jun 2020 15:06:53 -0400 From: Justin Richer Message-Id: <486B1729-AC7B-4A34-9592-B8E23AFAC2D9@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_79F68266-1C92-4BB4-9BF1-F9503BC17435" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 25 Jun 2020 15:06:52 -0400 In-Reply-To: Cc: Barry Leiba , The IESG , "gnap-chairs@ietf.org" , "txauth@ietf.org" To: "rdd@cert.org" References: <159302228054.20699.8970656798339535215@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Barry Leiba's No Objection on charter-ietf-gnap-00-01: (with COMMENT) 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, 25 Jun 2020 19:06:59 -0000 --Apple-Mail=_79F68266-1C92-4BB4-9BF1-F9503BC17435 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Barry, thanks for the comments; Some thoughts on the =E2=80=9CTODO=E2=80= =9D below. >=20 >>> The client and Authorization Server (AS) will involve a user to make >>> an authorization decision as necessary through interaction = mechanisms >>> indicated by the protocol. >>=20 >> This sentence seems very clumsy and unclear. The primary thing that = bothers >> me is =E2=80=9Cmechanisms indicated by the protocol=E2=80=9D: can we = rephrase that to make it >> clearThe primary thing that bothers me is =E2=80=9Cmechanisms = indicated by the >> protocol=E2=80=9D: can we rephrase that to make it clearer what = we=E2=80=99re talking about, >> perhaps by splitting the sentence, explaining what this means first, = and then >> putting the rest of the sentence after it? Maybe something like = this: >>=20 >> NEW >> The protocol will include interaction mechanisms that > explanation>. >> The client and Authorization Server (AS) will use those mechanisms to = involve >> a user, as necessary, to make authorization decisions. END >=20 > Todo. >=20 The idea here is that the interaction methods are part of the = negotiation between the client and AS. So we could say something like = this that should address what you=E2=80=99re after: The protocol will include a means of specifying how the user can = potentially be involved in an interactive fashion during the delegation = process. The client and Authorization Server (AS) will use these = interaction mechanisms to involve the user, as necessary, to make = authorization decisions. The wording still feels a little shaky to me, but is this going in the = right direction? Thanks, =E2=80=94 Justin --Apple-Mail=_79F68266-1C92-4BB4-9BF1-F9503BC17435 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Barry, thanks for the comments; Some thoughts on the =E2=80=9CTODO=E2=80=9D= below.


The client and = Authorization Server (AS) will involve a user to make
an = authorization decision as necessary through interaction mechanisms
indicated by the protocol.

This sentence seems very clumsy and unclear.  The = primary thing that bothers
me is =E2=80=9Cmechanisms = indicated by the protocol=E2=80=9D: can we rephrase that to make it
clearThe primary thing that bothers me is =E2=80=9Cmechanisms = indicated by the
protocol=E2=80=9D: can we rephrase that = to make it clearer what we=E2=80=99re talking about,
perhaps= by splitting the sentence, explaining what this means first, and = then
putting the rest of the sentence after it? =  Maybe something like this:

NEW
The protocol will include interaction mechanisms that = <some brief
explanation>.
The client = and Authorization Server (AS) will use those mechanisms to involve
a user, as necessary, to make authorization decisions. END

Todo.


The idea here is that the interaction methods are = part of the negotiation between the client and AS. So we could say = something like this that should address what you=E2=80=99re = after:

The protocol will = include a means of specifying how the user can potentially be involved = in an interactive fashion during the delegation process. The client and = Authorization Server (AS) will use these interaction mechanisms to = involve the user, as necessary, to make authorization = decisions.

The wording = still feels a little shaky to me, but is this going in the right = direction?

Thanks,
 =E2= =80=94 Justin

= --Apple-Mail=_79F68266-1C92-4BB4-9BF1-F9503BC17435-- From nobody Thu Jun 25 12:09:46 2020 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 11AA03A0FE1; Thu, 25 Jun 2020 12:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 MQhASaaps1rM; Thu, 25 Jun 2020 12:09:38 -0700 (PDT) Received: from mail-il1-f175.google.com (mail-il1-f175.google.com [209.85.166.175]) (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 8D6CE3A0E0D; Thu, 25 Jun 2020 12:09:38 -0700 (PDT) Received: by mail-il1-f175.google.com with SMTP id l9so6342294ilq.12; Thu, 25 Jun 2020 12:09:38 -0700 (PDT) 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=973vsS/x6/yG4/Smg5p+B+fgdPGF7oul4bzP7Sg8jzg=; b=gWuzfoI2jBG3l8wfSCPZZtx4clGg0ScdEgrRMOe0Av3Uv7OVvsKQ96LwzTOXsi/6wB 5Uwblus/dPMNcStXIUf8VKAb+eLP0wKdyS1sSgxc1gvK88cdoqWamDbDQxsCy+dHQyi6 vutTGotfj0ET0Mss5PKMBTkZ5Wi8n2Vw3g0Lp0jwVahYTE1niLFa6fkO0FAYt2k8b8yW /SST5AUYh96HCsj88rAOUl6WV28Q66MfAhUG1a5trJ41XDxR7kTZyInNJCJ2DZeK3kmA iEaNniJ+/rrdDJ3YuzsKuiNudyDmaRpnvEpKgHlbjjaq7qUS/HseI17dp9Vt3W62Ve9T F2bQ== X-Gm-Message-State: AOAM530ZhkDQ4MDiF6H1c5k9mliiyXcCcuJKAoVJNDYPVjOOWtR7jBwp DGMw3+YI+dIyljfcTVcbqOcF7XSTnW2nVUsD02Y= X-Google-Smtp-Source: ABdhPJxFRU5/jrzEzHDggQl47x7oLSNj6i7NiI0eikAnUYjvG0AvVN6LW2LWydXkIDD3yl780hTCC5T48iKrfcu49wQ= X-Received: by 2002:a92:d807:: with SMTP id y7mr3897178ilm.187.1593112177648; Thu, 25 Jun 2020 12:09:37 -0700 (PDT) MIME-Version: 1.0 References: <159302228054.20699.8970656798339535215@ietfa.amsl.com> <486B1729-AC7B-4A34-9592-B8E23AFAC2D9@mit.edu> In-Reply-To: <486B1729-AC7B-4A34-9592-B8E23AFAC2D9@mit.edu> From: Barry Leiba Date: Thu, 25 Jun 2020 15:09:26 -0400 Message-ID: To: Justin Richer Cc: "rdd@cert.org" , The IESG , "gnap-chairs@ietf.org" , "txauth@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Txauth] Barry Leiba's No Objection on charter-ietf-gnap-00-01: (with COMMENT) 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, 25 Jun 2020 19:09:40 -0000 Thanks, Justin... yes, the text you suggest seems much clearer to me, and I'd like to see that in the charter. Barry On Thu, Jun 25, 2020 at 3:07 PM Justin Richer wrote: > > Hi Barry, thanks for the comments; Some thoughts on the =E2=80=9CTODO=E2= =80=9D below. > > > The client and Authorization Server (AS) will involve a user to make > an authorization decision as necessary through interaction mechanisms > indicated by the protocol. > > > This sentence seems very clumsy and unclear. The primary thing that both= ers > me is =E2=80=9Cmechanisms indicated by the protocol=E2=80=9D: can we reph= rase that to make it > clearThe primary thing that bothers me is =E2=80=9Cmechanisms indicated b= y the > protocol=E2=80=9D: can we rephrase that to make it clearer what we=E2=80= =99re talking about, > perhaps by splitting the sentence, explaining what this means first, and = then > putting the rest of the sentence after it? Maybe something like this: > > NEW > The protocol will include interaction mechanisms that explanation>. > The client and Authorization Server (AS) will use those mechanisms to inv= olve > a user, as necessary, to make authorization decisions. END > > > Todo. > > > The idea here is that the interaction methods are part of the negotiation= between the client and AS. So we could say something like this that should= address what you=E2=80=99re after: > > The protocol will include a means of specifying how the user can potentia= lly be involved in an interactive fashion during the delegation process. Th= e client and Authorization Server (AS) will use these interaction mechanism= s to involve the user, as necessary, to make authorization decisions. > > > The wording still feels a little shaky to me, but is this going in the ri= ght direction? > > Thanks, > =E2=80=94 Justin > From nobody Thu Jun 25 12:29:55 2020 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 919B33A0FEC; Thu, 25 Jun 2020 12:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD1keunrTjak; Thu, 25 Jun 2020 12:29:48 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5D13A1039; Thu, 25 Jun 2020 12:29:29 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05PJTRVh002285; Thu, 25 Jun 2020 15:29:27 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 05PJTRVh002285 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1593113367; bh=3YEwNNQrWH9dS0A+1KD6L+ZAsomsDYZO6NqP4Ln4EIs=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=WQZAmoMznDtoDz8LDw3TSQxjYn55tMeYHGawjxrxl7j26HbcaQ9bcevLSWODqhvkQ KO5Rk4Vo2jMUGRfoOe5Egax7I5wlvj1lWuGvy8DZxTOWuliVCRvbfR6KA+btK/HzSL twHBy+eBe3aoO6b+a+vLOovxr7BarenlCjClD7YE= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 05PJTQn2010900; Thu, 25 Jun 2020 15:29:26 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 25 Jun 2020 15:29:26 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 25 Jun 2020 15:29:26 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Thu, 25 Jun 2020 15:29:26 -0400 From: Roman Danyliw To: Barry Leiba , Justin Richer CC: "txauth@ietf.org" , The IESG , "gnap-chairs@ietf.org" Thread-Topic: [Txauth] Barry Leiba's No Objection on charter-ietf-gnap-00-01: (with COMMENT) Thread-Index: AQHWSlLjWdG1mBhDmkiU0o1qb0lODKjpTqiggACnUgCAAAC3AP//wabg Date: Thu, 25 Jun 2020 19:29:24 +0000 Message-ID: References: <159302228054.20699.8970656798339535215@ietfa.amsl.com> <486B1729-AC7B-4A34-9592-B8E23AFAC2D9@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.201.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Txauth] Barry Leiba's No Objection on charter-ietf-gnap-00-01: (with COMMENT) 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, 25 Jun 2020 19:29:50 -0000 SGkgSnVzdGluL0JhcnJ5OiBUaGFua3MuIEkndmUgdXBkYXRlZCB0aGUgY2hhcnRlciB0ZXh0IHdp dGggdGhpcyBlZGl0LiAgDQoNCkJhcnJ5OiBJIGJlbGlldmUgdGhpcyBhZGRyZXNzZXMgYWxsIG9m IHlvdXIgZmVlZGJhY2suDQoNClJlZ2FyZHMsDQpSb21hbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGllc2cgPGllc2ctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxm IE9mIEJhcnJ5IExlaWJhDQo+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDI1LCAyMDIwIDM6MDkgUE0N Cj4gVG86IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4NCj4gQ2M6IFJvbWFuIERhbnls aXcgPHJkZEBjZXJ0Lm9yZz47IHR4YXV0aEBpZXRmLm9yZzsgVGhlIElFU0cNCj4gPGllc2dAaWV0 Zi5vcmc+OyBnbmFwLWNoYWlyc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW1R4YXV0aF0gQmFy cnkgTGVpYmEncyBObyBPYmplY3Rpb24gb24gY2hhcnRlci1pZXRmLWduYXAtMDAtMDE6DQo+ICh3 aXRoIENPTU1FTlQpDQo+IA0KPiBUaGFua3MsIEp1c3Rpbi4uLiB5ZXMsIHRoZSB0ZXh0IHlvdSBz dWdnZXN0IHNlZW1zIG11Y2ggY2xlYXJlciB0byBtZSwgYW5kIEknZCBsaWtlDQo+IHRvIHNlZSB0 aGF0IGluIHRoZSBjaGFydGVyLg0KPiANCj4gQmFycnkNCj4gDQo+IE9uIFRodSwgSnVuIDI1LCAy MDIwIGF0IDM6MDcgUE0gSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PiB3cm90ZToNCj4g Pg0KPiA+IEhpIEJhcnJ5LCB0aGFua3MgZm9yIHRoZSBjb21tZW50czsgU29tZSB0aG91Z2h0cyBv biB0aGUg4oCcVE9ET+KAnSBiZWxvdy4NCj4gPg0KPiA+DQo+ID4gVGhlIGNsaWVudCBhbmQgQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgKEFTKSB3aWxsIGludm9sdmUgYSB1c2VyIHRvIG1ha2UNCj4gPiBh biBhdXRob3JpemF0aW9uIGRlY2lzaW9uIGFzIG5lY2Vzc2FyeSB0aHJvdWdoIGludGVyYWN0aW9u IG1lY2hhbmlzbXMNCj4gPiBpbmRpY2F0ZWQgYnkgdGhlIHByb3RvY29sLg0KPiA+DQo+ID4NCj4g PiBUaGlzIHNlbnRlbmNlIHNlZW1zIHZlcnkgY2x1bXN5IGFuZCB1bmNsZWFyLiAgVGhlIHByaW1h cnkgdGhpbmcgdGhhdA0KPiA+IGJvdGhlcnMgbWUgaXMg4oCcbWVjaGFuaXNtcyBpbmRpY2F0ZWQg YnkgdGhlIHByb3RvY29s4oCdOiBjYW4gd2UgcmVwaHJhc2UNCj4gPiB0aGF0IHRvIG1ha2UgaXQg Y2xlYXJUaGUgcHJpbWFyeSB0aGluZyB0aGF0IGJvdGhlcnMgbWUgaXMg4oCcbWVjaGFuaXNtcw0K PiA+IGluZGljYXRlZCBieSB0aGUNCj4gPiBwcm90b2NvbOKAnTogY2FuIHdlIHJlcGhyYXNlIHRo YXQgdG8gbWFrZSBpdCBjbGVhcmVyIHdoYXQgd2XigJlyZSB0YWxraW5nDQo+ID4gYWJvdXQsIHBl cmhhcHMgYnkgc3BsaXR0aW5nIHRoZSBzZW50ZW5jZSwgZXhwbGFpbmluZyB3aGF0IHRoaXMgbWVh bnMNCj4gPiBmaXJzdCwgYW5kIHRoZW4gcHV0dGluZyB0aGUgcmVzdCBvZiB0aGUgc2VudGVuY2Ug YWZ0ZXIgaXQ/ICBNYXliZSBzb21ldGhpbmcNCj4gbGlrZSB0aGlzOg0KPiA+DQo+ID4gTkVXDQo+ ID4gVGhlIHByb3RvY29sIHdpbGwgaW5jbHVkZSBpbnRlcmFjdGlvbiBtZWNoYW5pc21zIHRoYXQg PHNvbWUgYnJpZWYNCj4gPiBleHBsYW5hdGlvbj4uDQo+ID4gVGhlIGNsaWVudCBhbmQgQXV0aG9y aXphdGlvbiBTZXJ2ZXIgKEFTKSB3aWxsIHVzZSB0aG9zZSBtZWNoYW5pc21zIHRvDQo+ID4gaW52 b2x2ZSBhIHVzZXIsIGFzIG5lY2Vzc2FyeSwgdG8gbWFrZSBhdXRob3JpemF0aW9uIGRlY2lzaW9u cy4gRU5EDQo+ID4NCj4gPg0KPiA+IFRvZG8uDQo+ID4NCj4gPg0KPiA+IFRoZSBpZGVhIGhlcmUg aXMgdGhhdCB0aGUgaW50ZXJhY3Rpb24gbWV0aG9kcyBhcmUgcGFydCBvZiB0aGUgbmVnb3RpYXRp b24NCj4gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCBBUy4gU28gd2UgY291bGQgc2F5IHNvbWV0aGlu ZyBsaWtlIHRoaXMgdGhhdCBzaG91bGQNCj4gYWRkcmVzcyB3aGF0IHlvdeKAmXJlIGFmdGVyOg0K PiA+DQo+ID4gVGhlIHByb3RvY29sIHdpbGwgaW5jbHVkZSBhIG1lYW5zIG9mIHNwZWNpZnlpbmcg aG93IHRoZSB1c2VyIGNhbiBwb3RlbnRpYWxseQ0KPiBiZSBpbnZvbHZlZCBpbiBhbiBpbnRlcmFj dGl2ZSBmYXNoaW9uIGR1cmluZyB0aGUgZGVsZWdhdGlvbiBwcm9jZXNzLiBUaGUgY2xpZW50DQo+ IGFuZCBBdXRob3JpemF0aW9uIFNlcnZlciAoQVMpIHdpbGwgdXNlIHRoZXNlIGludGVyYWN0aW9u IG1lY2hhbmlzbXMgdG8gaW52b2x2ZQ0KPiB0aGUgdXNlciwgYXMgbmVjZXNzYXJ5LCB0byBtYWtl IGF1dGhvcml6YXRpb24gZGVjaXNpb25zLg0KPiA+DQo+ID4NCj4gPiBUaGUgd29yZGluZyBzdGls bCBmZWVscyBhIGxpdHRsZSBzaGFreSB0byBtZSwgYnV0IGlzIHRoaXMgZ29pbmcgaW4gdGhlIHJp Z2h0DQo+IGRpcmVjdGlvbj8NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiAg4oCUIEp1c3Rpbg0KPiA+ DQoNCg== From nobody Thu Jun 25 12:30:05 2020 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 BA5A03A0FE8; Thu, 25 Jun 2020 12:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 CS0GAE9rakjb; Thu, 25 Jun 2020 12:29:48 -0700 (PDT) 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 E24FB3A0FE5; Thu, 25 Jun 2020 12:29:40 -0700 (PDT) Received: from [192.168.1.14] (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 05PJTbvM009679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jun 2020 15:29:37 -0400 From: Justin Richer Message-Id: <559FF73B-38D4-4D49-8827-0958613912C0@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_745BD704-4E32-4884-AF18-5C8CF581D5AC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Thu, 25 Jun 2020 15:29:36 -0400 In-Reply-To: Cc: Benjamin Kaduk , The IESG , "gnap-chairs@ietf.org" , "txauth@ietf.org" To: "rdd@cert.org" References: <159305522436.11733.15198171728373227965@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT) 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, 25 Jun 2020 19:29:51 -0000 --Apple-Mail=_745BD704-4E32-4884-AF18-5C8CF581D5AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben, Thanks for the thorough read through, as always. Some of my own thoughts the TODO items inline below. >>=20 >> This group is chartered to develop a fine-grained delegation = protocol >> for authorization and API access, as well as requesting and = providing >> user identifiers and claims. >>=20 >> nit: this appears to parse as "providing user claims", and I'm not = sure what that >> means. >=20 > TODO Yes, the is intended to parse as =E2=80=9Cproviding user claims=E2=80=9D. = The idea here is that the client should be able to send claims that it = has to the AS that will identify the user in a fashion that the AS can = verify. In these cases, the AS can make a policy decision without = directly involving the user for interaction. This is largely a gap in = the OAuth 2 world, though the Resource Owner Password grant and the = Assertions grant kind go in this direction, but there=E2=80=99s a desire = in the community for a general mechanism for doing this. To be clear, = GNAP is going to defer the details of these kinds of assertions to other = specifications, like W3C=E2=80=99s Verifiable Credentials.=20 >=20 >> The protocol will decouple the interaction channels, such as the end >> user=E2=80=99s browser [...] >>=20 >> "interaction channels" might be a term of art that needs = clarification? >=20 > TODO I don=E2=80=99t think it=E2=80=99s a specific term of art. I think we = really meant =E2=80=9Cdifferent ways to interact with the user=E2=80=9D. = One of OAuth 2=E2=80=99s limitations is that it, for the most part, = assumes the user=E2=80=99s in a browser, and the core of the protocol is = built around that. One of the goals of GNAP is to get away from that as = a base assumption. >=20 >> The client and Authorization Server (AS) will involve a user to make >> an authorization decision as necessary through interaction = mechanisms >> indicated by the protocol. >>=20 >>> =46rom a privacy perspective, will all of the information to be made >> available from the AS to the RS be visible to the user as they make = this >> authorization decision? >=20 > TODO Ultimately I don=E2=80=99t think we can fully specify the AS behavior = here, but this is a good pillar for privacy considerations. >=20 >> The group will define interoperability for this protocol between = different >> parties, including >> - client and authorization server; >> - client and resource server; and >> - authorization server and resource server. >>=20 >> [obligatory note that just because we define an AS/RS channel doesn't = mean it >> will be required to use one at runtime, given the potential for = self-contained >> tokens?] >=20 > Are you thinking that clarification would be explicitly stated? Note that a self-contained token is one of the communication channels = that the group had in mind for AS/RS. We tried to write the requirements = in such a way as to allow for self-contained messages, service-based = stuff (like introspection), or even all-in-one-box solutions that = don=E2=80=99t need =E2=80=9Ccommunication=E2=80=9D apart from both = reading the same database. This is an architectural pillar borrowed from = OAuth 2. >=20 >> - Support for directed, audience-restricted access tokens >>=20 >> I think we need to clarify what "directed" is intended to mean here = (if it's not >> just a synonym for "audience-restricted" in which case it should just = be >> removed). >=20 > TODO This one is my fault =E2=80=94 the concept we=E2=80=99re talking about = here is one where the AS can effectively tell the client where and how = it should use the token. There are a couple different WG participants = who have expressed explicit interest in this, and I=E2=80=99ve started a = thread on that topic recently: = https://mailarchive.ietf.org/arch/msg/txauth/eP162P235OU0_JksY515FgmHFj0/ >=20 >> - A variety of client applications, including Web, mobile, >> single-page, and interaction-constrained applications >>=20 >> side note: this one feels like it would be easier to phrase as "the = WG will seek >> to minimize assumptions about the form of client applications, = allowing for >> [...]" >=20 > TODO That seems reasonable to me, and it goes hand-in-hand with the changes = to interaction mentioned above.=20 >> Additionally, the group will provide mechanisms for management of = the >> protocol lifecycle including: >> [...] >> - Mechanisms for the AS and RS to communicate the access granted by = an >> access token >>=20 >> Maybe I'm just confused, but isn't "the access granted by an access = token" >> exactly the set of authorizations conveyed by that token, i.e., the = core point of >> the protocol? I'm not sure what kind "protocol lifecycle management" = this >> item is intending to indicate. >=20 > TODO This ties into what=E2=80=99s above: the idea is to have a standard = model for what an access token represents, and this says we=E2=80=99re = going to standardize ways for the AS and RS to communicate that. This = could be inside the token, through an introspection style service, or = some other thing we haven=E2=80=99t figured out yet. But the thing is, = all of these mechanisms should be communicating the same set of = information. This is something the OAuth WG didn=E2=80=99t address, and = so we ended up with some disparity in the handful of de-facto access = token data models there. The goal was to avoid that. =E2=80=94 Justin= --Apple-Mail=_745BD704-4E32-4884-AF18-5C8CF581D5AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ben,

Thanks for the = thorough read through, as always.

Some of my own thoughts the TODO items = inline below.


 This group is chartered to develop a fine-grained = delegation protocol
 for authorization and API = access, as well as requesting and providing
 user = identifiers and claims.

nit: this appears = to parse as "providing user claims", and I'm not sure what that
means.

TODO

Yes, the is intended to parse as =E2=80=9Cproviding = user claims=E2=80=9D. The idea here is that the client should be able to = send claims that it has to the AS that will identify the user in a = fashion that the AS can verify. In these cases, the AS can make a policy = decision without directly involving the user for interaction. This is = largely a gap in the OAuth 2 world, though the Resource Owner Password = grant and the Assertions grant kind go in this direction, but there=E2=80=99= s a desire in the community for a general mechanism for doing this. To = be clear, GNAP is going to defer the details of these kinds of = assertions to other specifications, like W3C=E2=80=99s Verifiable = Credentials. 



 The protocol will decouple the interaction channels, = such as the end
 user=E2=80=99s browser [...]

"interaction channels" might be a term of art = that needs clarification?

TODO

I don=E2=80=99= t think it=E2=80=99s a specific term of art. I think we really meant = =E2=80=9Cdifferent ways to interact with the user=E2=80=9D. One of OAuth = 2=E2=80=99s limitations is that it, for the most part, assumes the = user=E2=80=99s in a browser, and the core of the protocol is built = around that. One of the goals of GNAP is to get away from that as a base = assumption.


 The client and Authorization Server (AS) will involve a = user to make
 an authorization decision as necessary = through interaction mechanisms
 indicated by the = protocol.

=46rom a privacy perspective, will all of the information to = be made
available from the AS to the RS be = visible to the user as they make this
authorization = decision?

TODO

Ultimately I don=E2=80=99t think we can fully = specify the AS behavior here, but this is a good pillar for privacy = considerations.


 The group will define = interoperability for this protocol between different
 parties, including
  - client = and authorization server;
  - client and = resource server; and
  - authorization server = and resource server.

[obligatory note that = just because we define an AS/RS channel doesn't mean it
will= be required to use one at runtime, given the potential for = self-contained
tokens?]

Are you thinking that = clarification would be explicitly stated?

Note that a self-contained token is one of the = communication channels that the group had in mind for AS/RS. We tried to = write the requirements in such a way as to allow for self-contained = messages, service-based stuff (like introspection), or even = all-in-one-box solutions that don=E2=80=99t need =E2=80=9Ccommunication=E2= =80=9D apart from both reading the same database. This is an = architectural pillar borrowed from OAuth 2.


 -= Support for directed, audience-restricted access tokens
I think we need to clarify what "directed" is intended to = mean here (if it's not
just a synonym for = "audience-restricted" in which case it should just be
removed).

TODO

This one is my fault =E2=80=94 the concept we=E2=80=99= re talking about here is one where the AS can effectively tell the = client where and how it should use the token. There are a couple = different WG participants who have expressed explicit interest in this, = and I=E2=80=99ve started a thread on that topic recently:



 - A variety of client = applications, including Web, mobile,
   single-page, and interaction-constrained = applications

side note: this one feels like = it would be easier to phrase as "the WG will seek
to = minimize assumptions about the form of client applications, allowing = for
[...]"

TODO

That seems = reasonable to me, and it goes hand-in-hand with the changes to = interaction mentioned above. 

 Additionally, the group will = provide mechanisms for management of the
 protocol = lifecycle including:
 [...]
 - = Mechanisms for the AS and RS to communicate the access granted by an
   access token

Maybe I'm just confused, but isn't "the access granted by an = access token"
exactly the set of authorizations conveyed = by that token, i.e., the core point of
the protocol? =  I'm not sure what kind "protocol lifecycle management" this
item is intending to indicate.

TODO

This ties = into what=E2=80=99s above: the idea is to have a standard model for what = an access token represents, and this says we=E2=80=99re going to = standardize ways for the AS and RS to communicate that. This could be = inside the token, through an introspection style service, or some other = thing we haven=E2=80=99t figured out yet. But the thing is, all of these = mechanisms should be communicating the same set of information. This is = something the OAuth WG didn=E2=80=99t address, and so we ended up with = some disparity in the handful of de-facto access token data models = there. The goal was to avoid that.

 =E2=80=94 = Justin
= --Apple-Mail=_745BD704-4E32-4884-AF18-5C8CF581D5AC-- From nobody Thu Jun 25 18:08:13 2020 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 A49943A10B8 for ; Thu, 25 Jun 2020 18:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mattr-global.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 4A5hbQ0WzNjd for ; Thu, 25 Jun 2020 18:08:08 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 2A6793A10B7 for ; Thu, 25 Jun 2020 18:08:08 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id k18so7413736qke.4 for ; Thu, 25 Jun 2020 18:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattr-global.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z4LF+S3YXqt8eQKDZIL1X+qvu/8VffdBJfZjOWXj70w=; b=xplEVQZYwexATv0wNwDBbDNywMxiuSn+dwWCrM3XnUlw9Cr4KT/1ugzsQR7n6O07gP 9bSHqNqvUV1FJUf5bMls7u6yhr5AqcGDUNBvnpAMFjb1DzsYCqH04VgUvUUxtgdprW1b 8J6OBj17xd6kjXwGAUWcob0bmusrX6irPGAZBMjQiHmlrgUhCQXq+8IneU6pI7ffpBvn PoTw9qKBerCsrhwDJy/nabSA/wBfCxDQqkL5MKpOy9elu93YrwHJeNIBUZt2MsdplJwN JRsXppUT6Ygqhm7Yk0CfprauaHRpXwpmEBJjfUOoe3ZlZLRb5QvuoAOt6bipEEHekbPW pm3A== 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=z4LF+S3YXqt8eQKDZIL1X+qvu/8VffdBJfZjOWXj70w=; b=Mk42mHOBhjVpkVofmwG3U48aslrjsleAEm1eMQKaUpGxoyNXgwGgS/92GBnQTL1UqJ fBxADvO+W/GoJVgHGCdOhtpr52+mjAX4G50AR05dyQiEMnilNqxUOwPBePKHW6Pnqref anG05+47ECuxtqrocSS+kY2zo0uBhD00g3TClf50xLaRJjvaWNElQExC90elhJOCpH9X 5hKneQTxMbPnP0iijvp7oSLucm+i9tN8m8O+4b6Iiz1HNc1obnRhhZZQL9yZ641f9B4E GlKDsW/dgjP353rnxHeIUPzxI+nTGocpiGIKLBxzgQcyTO4Vu0GOlGrSOJzrwAmKzw4U Zg0w== X-Gm-Message-State: AOAM532VHVWSaMmXnU6tA6A2+DIXSl//XvLnBNEAoeYkW5m4utvZA7tM KIMg8fZtRCpIS7NdcdMxoIsq42apX/Va7NYe7MVDoZtU37KpN9tZ924CggHmLWWIlbdNr0ZVvmG xHNyNDvtbEPqWJU5hWQ== X-Google-Smtp-Source: ABdhPJzQ6lV01lCtfAEfJoSSR8BXLq4ucAIUIMOMSPmVyvHknHFLjS+d53mdHklcljgCKMyA7g8w52ryNq7SRHLfB3s= X-Received: by 2002:a37:9d8a:: with SMTP id g132mr477388qke.149.1593133687033; Thu, 25 Jun 2020 18:08:07 -0700 (PDT) MIME-Version: 1.0 References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> In-Reply-To: From: Tobias Looker Date: Fri, 26 Jun 2020 13:07:56 +1200 Message-ID: To: Denis Cc: Justin Richer , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000007ee79805a8f2570a" Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 26 Jun 2020 01:08:12 -0000 --0000000000007ee79805a8f2570a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I find this feature interesting and think it could be an important pattern going forward to enable an AS to be able to describe the utility of a token to the client, however as already pointed out in the thread I think there is some potential hidden complexity that would need to be ironed out such that it does not make the simple things complicated. Justin, do you see this feature as something the client has to explicitly request, i.e "please give me access and instructions on how to use my access" or rather that the AS would just return this information in conjunction with the access token if it had it available? > This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing? Would a potential default be that if a client did for any reason not support processing the additional information returned with the access_token, just to ignore it? I think in the spirit of keeping the simple things simple, this potentially makes sense? > here are some worked out samples of this: https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ Peace ..tom As one of the authors of those mentioned drafts, I am interested in discussing that, but perhaps on a seperate thread? As at least the bound assertion spec is primarily concerned with binding mechanisms for the artifacts produced from an authorization flow (specifically identity claims), whereas I think directed access tokens is just more generally talking about whether GNAP should support an AS conveying how to use an access_token it produces during a flow with a client. Thanks, [image: Mattr website] *Tobias Looker* Mattr +64 (0) 27 378 0461 tobias.looker@mattr.global [image: Mattr website] [image: Mattr on LinkedIn] [image: Mattr on Twitter] [image: Mattr on Github] This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. On Wed, Jun 24, 2020 at 10:14 PM Denis wrote: > Justin, I fear we are still far away from an agreement about what this Bo= F > should do. > > Tom Jones is saying " I am getting tired of the whack-a-mole approach ...= " > > I don't agree with you when you write: "I think it=E2=80=99s going to be > overwhelmingly common that a given RS is going to trust exactly one AS > that it knows about ahead of time". Such an architecture would have > exactly the same limitations as OAuth 2.0. and would not be scalable. > > Before we start, we should have a clear view of the whole picture rather > than starting from one scenario and expanding it in many different > directions. > For building an architecture, a pre-requirement is to define ALL the trus= t > relationships. I don't believe that we have an agreement at this time on > what > these trust relationships are. > > You are also using the following wording: "methods for the AS and RS to > communicate what the token=E2=80=99s good for". > With such a paradigm, it would be impossible to protect the user's > privacy. > > A key question is : Will GNAP take care of the user's privacy or will GNA= P *prevent > *to take care of the user's privacy ? > > About "the ability for the client to get several access tokens to get > different resources from one request" is indeed a complex case. > > No one (including ASs) is able to predict in advance which access tokens > will be needed, since they depend upon the kind of operation(s) > the client will be willing to perform. For privacy reasons, ASs should be > kept ignorant of all the operations that a client is going to perform > on one or more resource servers. I believe that every effort should be > made to avoid the AS to be in a position to be able to trace the operatio= ns > performed by its clients on various RSs. > > To handle the complex case you envision, the full workflow of operations > needs to be considered with a detailed focus on the time > at which the user's *consent and choice* happens (*consent and choice* is > the first privacy principle from ISO 29100). > > First of all, an access token could be targeted to a service rather than > to a server. This would already solve many cases. > > When a RS needs to call another RS (which does not support the same > service) then the client should be informed by the first RS. > His "consent and choice" should then be obtained by the first RS and, whe= n > the user agrees, the client should then ask an access token > to one of the ASs trusted by the second RS in order to perform the > subsequent operation. > > Denis > > PS. In an email sent on June 23 you wrote: " I think an on-device AS is > an important use case". I am sorry, but I don't understand. > However, I do understand what "a server-based AS" is. > > > Denis, thanks for the great comments. I think that your trust model is > pretty different from what I=E2=80=99d laid out initially, and while it= =E2=80=99s an > interesting and important one, it is not what I meant by =E2=80=9Cmultipl= e access > tokens=E2=80=9D in my discussion below. I think that might be the cause o= f some > disconnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of reach = for what the WG is > after. > > When I refer to multiple access tokens, and what the charter calls out as > multiple access tokens, is the ability for the client to get several acce= ss > tokens to get different resources from one request. I personally see this > as an optimization of a specific set of use cases, some of which I > discussed in my original email. There are others, I=E2=80=99m sure, but a= ll the > ones I=E2=80=99ve seen are around the client needing to get several diffe= rent kinds > of access through an AS. > > I think it=E2=80=99s going to be overwhelmingly common that a given RS is= going to > trust exactly one AS that it knows about ahead of time. But for RS=E2=80= =99s that > can trust multiple AS=E2=80=99s, then we should have a model that can acc= ommodate > that as well. That=E2=80=99s why the charter calls out methods for the AS= and RS to > communicate what the token=E2=80=99s good for. I think the basis of those= methods > is going to start with a common token model, and likely incorporate into > things like token formats and introspection-style token APIs. > > =E2=80=94 Justin > > On Jun 22, 2020, at 3:55 AM, Denis wrote: > > Hello Justin, > > A few comments between the lines. > > One of the most important aspects to GNAP is going to be an ability to > address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do w= ithout significant > gymnastics. So with that, I wanted to bring back a use case discussion th= at > originally came up while we were talking about the possibility of multipl= e > access tokens, a few months back. I don=E2=80=99t know if this concept ha= s a > regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access to= kens=E2=80=9D until we > come up with something better =E2=80=94 assuming we decide this is worthw= hile. > > I don't understand what may mean "directed access tokens=E2=80=9D but I u= nderstand > what means "multiple access tokens". > When speaking of "multiple access tokens", these access tokens may come > from one or more ASs. > > In OAuth, the client=E2=80=99s supposed to always know where to send its = access > token, and that knowledge is completely outside the protocol. This makes = a > lot of sense for many (if not most) deployments, as OAuth is really there > to enable the API access that the client already knows about. > > But we=E2=80=99re now in a world where a client could be talking to a gen= eric API > that could be deployed at a number of different places, or a cloud > deployment that the AS wants to be able to dispatch the client to. > > As soon the AS is placed (again) at the centre of the model, the AS will > have the ability to act as "Big Brother". > OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP > should take care of them. > > In order to do this, the AS needs to be able to communicate to the client > not only the token information (and any related key and presentation > information), but also a set of *directions* about what that specific > token is good for. This needs to be information outside the token itself, > since I believe we want to keep OAuth 2=E2=80=99s feature of having the t= oken be > opaque to the client. Note: while we could map all of these to different > resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance= ) > on the request side, this isn=E2=80=99t enough to tell the client what to= do with > the token *if it doesn=E2=80=99t know already*. > > I know of two use cases already in the wild, where people are addressing > things using a mix of existing standards and some proprietary extensions = to > address things within their silos. I=E2=80=99ll try to summarize here, bu= t I know > the folks I=E2=80=99ve been talking to about this are also on the list so= hopefully > they can chime in with more detail or any corrections for something I=E2= =80=99ve > missed. > > (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2= =80=99t know where > it=E2=80=99s hosted. Everything is in a single security domain controlled= by the AS, > > > Speaking of "multiple access tokens" is in contradiction with single > security domain "controlled" by an AS. > A user may need to demonstrate some of his identity attributes granted > e.g. by his bank but may also > need to demonstrate one or more diplomas granted by one or more > universities. The bank cannot be > the "primary issuer" of a university diploma. It should not be either a > "secondary issuer", because > the bank does not "*need to know"* what are the diplomas of the user. > > but the AS needs to decide at runtime which specific instance of the API > to direct the client to. Since things are closely tied together, the clie= nt > just needs to effectively known an identifier for the RS, and this is > currently implemented as a URI. Once the client has that identifier, it > knows how to dispatch that token to that instance of the RS. > > There is no good reason why the AS should be involved in that step. > OAuth 2.0 is/was implicitly mandating a strong relationship between ASs > and RSs which makes it non scalable. > GNAP should be based on a simple trust relationship : a given RS trusts > some ASs for access tokens that contains some types of attributes. > An AS should not need to know in advance (or even at the time of an acces= s > token request) the RSs that are trusting it. > > A client could first talk to a "global service provider" which has the > knowledge of the different RSs affiliated to it. > > (2) The client knows what kind of thing it=E2=80=99s looking for, but doe= sn=E2=80=99t know > who to ask it from. > > Once again, the client could first talk to a "global service provider" > which has the knowledge of the different RSs affiliated to it. > > There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, an= d the AS needs to > dispatch to different resources depending on which user logged in (and > possibly what the user consented to). To make things more concrete, the > client needs to get driver=E2=80=99s license information, but doesn=E2=80= =99t know ahead of > time which of the many state/provincial bureaus to call to get that > information because it doesn=E2=80=99t know yet who the user is. > > When a user has a driving license, he knows its issuer. The user can then > provide some hint to the client. > > The AS will know who the user is once they log in and approve things, and > so it can direct the client to call the correct RS. Since this is a > relatively simple API with a pre-negotiated cross-domain trust, the AS > returns a URL that the client presents the token at. > > A single AS should not be aware of all the attributes a user has. > > > As far as I know, in both of these cases, the token is only good for that > API and not others =E2=80=94 but more on that later. > > A simple thing to do is just give back a URL with the access token, which > tells the client where to go. > > { > =E2=80=9Caccess_token=E2=80=9D: { > =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D, > =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo" > } > } > > This is good for some kinds of APIs, but it=E2=80=99s limiting because no= t all > APIs dispatch based on the URL. An AS might want to divvy up access token= s > to an API that=E2=80=99s keyed on headers, or verbs, or any number of thi= ngs. And > it doesn=E2=80=99t tell us immediately what to do about non-exact URL mat= ches. Can > the client add query parameters and still use the token? What about path > segments? I like that this simple approach addresses some common > deployments that we already see today (see above), it=E2=80=99s not unive= rsal. Do > we want or need a universal description language for directing where toke= ns > go? > > This also opens up a whole new set of security questions. If the AS can > now direct the client where to use the token, could a rogue AS convince a > legit client to use a stolen token at the wrong RS? And what if the clien= t > ignores the directions from the AS entirely? Could this open up new avenu= es > of attack? > > This is just the start, too. Things get even more complex if the client > can ask for multiple different kinds of resources at once. What if the AS > decides that the client needs a hyper-focused directed token for one part > of the API, but can use a general token for other stuff? Can it signal th= at > to the client? And if it can, does that mean that all clients need to be > prepared for that kind of thing? > > I firmly believe that whatever we build in GNAP, we need to optimize for > the overwhelmingly common use case of a client getting a single access > token to call APIs that it already knows about. Anything we add on top of > that really can=E2=80=99t get in the way of this, because if it does, the= re=E2=80=99s very > small chance that people will try to use this for everyday things. Keep t= he > simple things simple, and the complex things possible, after all. > > I=E2=80=99m really looking forward to hearing what the community thinks a= bout > these use cases, and hopefully the people I=E2=80=99ve chatted with offli= ne about > this can join the conversation and provide more light than I was able to. > > The two use cases which are considered above are: > > (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2= =80=99t know where > it=E2=80=99s hosted. > (2) The client knows what kind of thing it=E2=80=99s looking for, but doe= sn=E2=80=99t know > who to ask it from. > > That does not mean in any way that these two use cases should be solved b= y > placing the AS at the centre of the solution. > > Denis > > > =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 This communication, including any attachments, is confidential. If you are= =20 not the intended recipient, you should not read it - please contact me=20 immediately, destroy it, and do not copy or use any part of this=20 communication or disclose anything about it. Thank you. Please note that=20 this communication does not designate an information system for the=20 purposes of the Electronic Transactions Act 2002. --0000000000007ee79805a8f2570a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --00000000000047e7a305a92fe0cb-- From nobody Mon Jun 29 00:06:49 2020 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 A6AFB3A094C for ; Mon, 29 Jun 2020 00:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 rFDJY31PVhNn for ; Mon, 29 Jun 2020 00:06:41 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43AC3A094B for ; Mon, 29 Jun 2020 00:06:40 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d28 with ME id wv6e220064FMSmm03v6eZ3; Mon, 29 Jun 2020 09:06:39 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 29 Jun 2020 09:06:39 +0200 X-ME-IP: 86.238.65.197 To: Dick Hardt Cc: iesg@ietf.org, txauth@ietf.org References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> From: Denis Message-ID: Date: Mon, 29 Jun 2020 09:06:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5E37C09292532BAE9A4AE654" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 29 Jun 2020 07:06:44 -0000 This is a multi-part message in MIME format. --------------5E37C09292532BAE9A4AE654 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Dick, > Denis, thanks for sharing your thoughts, some clarifications on your > statements inserted: > > On Fri, Jun 26, 2020 at 9:42 AM Denis > wrote: > > > *New proposed charter* > > > > > Resource servers inform their clients about which access token > formats are acceptable and depending upon the king of operation > that is requested, which kind of attributes are needed and > from which ASs that my be obtained. > > While at times this may be appropriate, at other times disclosing the > attributes the RS requires is not needed by the client. > For example, an enterprise client accessing a resource does not need > to know which groups a user belongs to, > but the RS may require that to determine if the user running the > client has access. As soon as there is a desire to implement privacy by default, the client should not provide more attributes than strictly necessary. Even after three readings of your example, I failed to understand it. > > A major difference with OAuth 2.0 is that there is no > bilateral trust relationship between an authorization server > and a resource server: > for a given category of attributes, a resource server may > trust one or more authorization servers. Another major > difference with OAuth 2.0. > is that the content of an attributes token is meant to be > accessible to the client. > > This is not how OAuth 2.0 works. See slides 7 and 8 from my original > IETF presentation on what became OAuth 2.0 > > https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation I looked at the two slides. Unfortunately slide 7 has just one arrow with the word "trust". This is insufficient to understand what is meant unless being present at the presentation. Does it mean that the PR (RS) trusts one AS or that it may trust multiple ASs ? Unfortunately slide 8 has just one arrow between the PR and the AS which is red-crossed but no text at all. This is insufficient to understand what is meant unless being present at the presentation. Does it mean that the PR and the AS never communicate directly ? Does it mean that they have no relationships at all, besides the one way trust relationship mentioned in slide 7 ? So it hard to say whether these two slides are indeed meaning that there is no bilateral relationship between an authorization server and a resource server. On June 12, Nat Sakimura recently answered to an email with the following topic: Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request)) My arguments were:      The original model for OAuth was making the assumption that the AS and the RS had a strong bilateral relationship. *A key question is whether such strong relationship will be maintained for ever *or      whether it will be allowed to perform some evolutions of this relationship.      In order to respect the privacy of the users, there is the need to encompass other scenarios. One of these scenarios is that the AS and the RS      do not need any longer to have such a strong relationship. In terms of trust relationships, a RS simply needs to trust the access tokens issued by an AS.      The AS does have any more a "need to know" of all the RSs that are accepting its access tokens. This would be a major simplification of the current global architecture. Nat's position was: "My take is that the basic assumption of OAuth 2.0 Framework is that there is a strong relationship between AS and RS. I feel that it is quite unrealistic that an RS would trust the access token issued by an AS that it has no strong relationship with". There are indeed different positions on this topic. > > The AS may not even know who the RS (or PR in the slides) is. > > > > > I got rid of the word "delegation": the client does not delegate > anything to an authorization server. If it would, this would mean > that the authorization server > would be able to act as the client and could know everything that > the client will do, which comes into contradiction with the user's > privacy. > > > The above is not true. > The Resource Owner is delegating access control to the AS in > authorization use cases. The OAuth 2.0 model does not mandate any more the presence of a Resource Owner. > > The client is may be delegating user authentication to the AS in > identity claim use cases. Delegating user authentication to the AS is different from delegating access control to the AS. > > The AS can act as the client in many OAuth deployments, as the access > token is a bearer token. A bearer token is rather insecure. > That does not mean the AS knows what the client is doing. There are currently two attempts in the OAuth WG to let know to the AS what the client is doing: * draft-ietf-oauth-jwsreq-22   (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request) * draft-ietf-oauth-rar-01         (OAuth 2.0 Rich Authorization Requests) Denis > > /Dick > ᐧ --------------5E37C09292532BAE9A4AE654 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hello Dick,

Denis, thanks for sharing your thoughts, some clarifications on your statements inserted:
On Fri, Jun 26, 2020 at 9:42 AM Denis <denis.ietf@free.fr> wrote:
<snip>

New proposed charter

<snip> 

Resource servers inform their clients about which access token formats are acceptable and depending upon the king of operation
that is requested, which kind of attributes are needed and from which ASs that my be obtained.

While at times this may be appropriate, at other times disclosing the attributes the RS requires is not needed by the client.
For example, an enterprise client accessing a resource does not need to know which groups a user belongs to,
but the RS may require that to determine if the user running the client has access.

As soon as there is a desire to implement privacy by default, the client should not provide more attributes than strictly necessary.
Even after three readings of your example, I failed to understand it.


A major difference with OAuth 2.0 is that there is no bilateral trust relationship between an authorization server and a resource server:
for a given category of attributes, a resource server may trust one or more authorization servers. Another major difference with OAuth 2.0.
is that the content of an attributes token is meant to be accessible to the client.
This is not how OAuth 2.0 works. See slides 7 and 8 from my original IETF presentation on what became OAuth 2.0

I looked at the two slides.

Unfortunately slide 7 has just one arrow with the word "trust". This is insufficient to understand what is meant unless being present
at the presentation. Does it mean that the PR (RS) trusts one AS or that it may trust multiple ASs ?

Unfortunately slide 8 has just one arrow between the PR and the AS which is red-crossed but no text at all. This is insufficient to understand
what is meant unless being present at the presentation. Does it mean that the PR and the AS never communicate directly ?
Does it mean that they have no relationships at all, besides the one way trust relationship mentioned in slide 7 ?

So it hard to say whether these two slides are indeed meaning that there is no bilateral relationship between an authorization server and a resource server.

On June 12, Nat Sakimura recently answered to an email with the following topic:

Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))

My arguments were:

     The original model for OAuth was making the assumption that the AS and the RS had a strong bilateral relationship.

      A key question is whether such strong relationship will be maintained for ever or
     whether it will be allowed to perform some evolutions of this relationship.

     In order to respect the privacy of the users, there is the need to encompass other scenarios. One of these scenarios is that the AS and the RS
     do not need any longer to have such a strong relationship. In terms of trust relationships, a RS simply needs to trust the access tokens issued by an AS.
     The AS does have any more a "need to know" of all the RSs that are accepting its access tokens. This would be a major simplification of the current global architecture.

Nat's position was:

"My take is that the basic assumption of OAuth 2.0 Framework is that there is a strong relationship between AS and RS.
I feel that it is quite unrealistic that an RS would trust the access token issued by an AS that it has no strong relationship with".

There are indeed different positions on this topic. 


The AS may not even know who the RS (or PR in the slides) is.

<snip> 


I got rid of the word "delegation": the client does not delegate anything to an authorization server. If it would, this would mean that the authorization server
would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy.


The above is not true.
 
The Resource Owner is delegating access control to the AS in authorization use cases.

The OAuth 2.0 model does not mandate any more the presence of a Resource Owner.


The client is may be delegating user authentication to the AS in identity claim use cases.

Delegating user authentication to the AS is different from delegating access control to the AS.


The AS can act as the client in many OAuth deployments, as the access token is a bearer token.

A bearer token is rather insecure.

That does not mean the AS knows what the client is doing.

There are currently two attempts in the OAuth WG to let know to the AS what the client is doing:

  • draft-ietf-oauth-jwsreq-22   (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request)
  • draft-ietf-oauth-rar-01         (OAuth 2.0 Rich Authorization Requests)

Denis


/Dick
 
ᐧ


--------------5E37C09292532BAE9A4AE654-- From nobody Mon Jun 29 00:13:59 2020 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 5AB803A0953 for ; Mon, 29 Jun 2020 00:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 8VB7InLLGSNL for ; Mon, 29 Jun 2020 00:13:54 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr [80.12.242.127]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE053A0936 for ; Mon, 29 Jun 2020 00:13:53 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d28 with ME id wvDr2200P4FMSmm03vDrVy; Mon, 29 Jun 2020 09:13:52 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 29 Jun 2020 09:13:52 +0200 X-ME-IP: 86.238.65.197 To: Justin Richer , txauth@ietf.org Cc: Dick Hardt References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <353AF4E4-4939-4994-960E-54B0AADC6253@mit.edu> From: Denis Message-ID: <624d15e8-48c0-4ef6-9429-d8fb79407d81@free.fr> Date: Mon, 29 Jun 2020 09:13:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <353AF4E4-4939-4994-960E-54B0AADC6253@mit.edu> Content-Type: multipart/alternative; boundary="------------37267049F4897C115452165B" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 29 Jun 2020 07:13:58 -0000 This is a multi-part message in MIME format. --------------37267049F4897C115452165B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Justin, > Removing the IESG as this is really a more internal-to-the-group > discussion, as it comes down to the scope of use cases that we want to > address here in GNAP. > > While it is definitely important to understand how and why OAuth 2 > does things, we do need to keep use cases like Denis’s in mind. Thanks. > It’s not unheard of today for a single OAuth 2 RS to accept tokens > from multiple AS’s. We are preparing the future. A simple case is to prove "who you are" and since banks "need to know their customers" they would be well placed to provide an access token containing some verified personal attributes. For example, a student would like to change university and would need to present his prior graduations. In such a case, each university or school would be well placed to produce such a proof by issuing an access token. > In fact, we’ve even got cases with things like the Solid project where > the RS will take a token from :any: AS so long as it can verify that > it’s approved by the resource owner. While the Solid platform has its > own special layering in place to allow this, our model should not > assume a closely-tied connection between an RS and any single AS. The > question of :how: we solve that is, of course, up to the WG to figure > out over time. Would this mean that we strongly agree together that the model should not assume a closely-tied connection between an RS and any single AS ? > Taking that even further, I think the idea of an AS that’s personal to > the user, to promote privacy and control, is a very good one. In a previous message, I indicated that I have been able to understand what you mean by: an "AS that’s personal to the user" ? > In fact, this is one of the main selling points of UMA2 and its > federated authorization mechanisms. With GNAP, we might be able to > deliver > on this promise even more than UMA has been able to, and it’s my hope > that we can have a cohesive protocol that allows both user-to-self > and user-to-another delegation sharing without needing to use > different mechanisms. > > Additionally, the RS-first method is also something from the UMA2 work > that we should be working on, as it touches on AS discovery, AS/RS > communication, and a few other aspects of the protocol design. It’s > not a trivial problem by any stretch, and there are huge privacy and > security implications, but there’s both need for it and some good > prior art to pull from. In fact, XYZ’s whole notion of a “transaction > handle” is an adaptation of UMA2’s “permission ticket”. In UMA, this > ticket is first issued to the RS by the AS, and the RS then hands it > to the client, which starts the negotiation for access. I envision > something very similar happening here with GNAP, where a client can > get something to bootstrap the process at the AS. The important thing, > to me, is that we don’t have to jump through a bunch of weird hoops > such that the AS-first and RS-first cases look completely different, > as they do in UMA2 and OAuth 2 respectively today. We’ve got the > chance to have a clean and cohesive protocol here, let’s not miss that > opportunity. > > So in sum, the trust model of OAuth 2 is not sufficient to cover > everything, and the model that Denis is proposing is something we > should at least look at as a use case. > Where Denis and I seem to disagree is whether this trust model should > be the :only: one that we address with the protocol. Any trust relationship may be described using the following construction:  entity A trusts entity B for some action C. If you have in mind additional trust relationships, would you be able to express them using this construction ? Maybe you also have in mind some relationships that do not imply a form of trust ? > I strongly believe, as I believe much of this group does, that we > can’t discount or ignore (or make things overly difficult for) > the tightly bound AS/RS combos, or any type of static setup where the > RS offloads its trust fully to the AS. > But it’s my belief that we should be able to do so without needlessly > throwing out all of the OAuth 2 use cases. Reading these sentences confuses me again since they seem to mean that the model should assume a closely-tied connection between RSs and ASs. In OAuth 2.0, the scope parameter allows the client to specify the desired scope of the requested security token in the context of the service or resource where the token will be used. The values and associated semantics of scope are service specific and and expected to be described in the relevant service documentation [RFC 8693]. Since the scope is RS dependent, the client MUST inform the AS about the identity of the RS, but this should be avoided for privacy reasons. Currently in OAuth 2.0, there is no protocol being defined to be able to know which attributes correspond to a given scope for a given RS. IMHO, the main idea is the following:  rather than using the scope parameter, the client should be able to inform directly the AS about which attributes it needs. In this way, the client would not need to inform the AS for which RS these attributes are needed. A major difference with OAuth 2.0 would be that attributes could be requested directly to an AS without using the pair scope/RS. Such an approach would make the architecture scalable. Denis > > We shouldn’t let “OAuth 2 doesn’t do it that way” be the limiting > factor here. We need to understand the what and wherefore of things > that OAuth 2 is bad at, otherwise we’re just going to re-invent OAuth > 2 and inherit its problems. > >  — Justin > >> On Jun 26, 2020, at 1:39 PM, Dick Hardt > > wrote: >> >> Denis, thanks for sharing your thoughts, some clarifications on your >> statements inserted: >> >> On Fri, Jun 26, 2020 at 9:42 AM Denis > > wrote: >> >> >> *New proposed charter* >> >> >> >> >> Resource servers inform their clients about which access >> token formats are acceptable and depending upon the king of >> operation >> that is requested, which kind of attributes are needed and >> from which ASs that my be obtained. >> >> While at times this may be appropriate, at other times disclosing the >> attributes the RS requires is not needed by the client. For example, >> an enterprise client accessing a resource does not need to know which >> groups a user belongs to, but the RS may require that to determine if >> the user running the client has access.. >> >> >> A major difference with OAuth 2.0 is that there is no >> bilateral trust relationship between an authorization server >> and a resource server: >> for a given category of attributes, a resource server may >> trust one or more authorization servers. Another major >> difference with OAuth 2.0. >> is that the content of an attributes token is meant to be >> accessible to the client. >> >> This is not how OAuth 2.0 works. See slides 7 and 8 from my original >> IETF presentation on what became OAuth 2.0 >> >> https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation >> >> The AS may not even know who the RS (or PR in the slides) is. >> >> >> >> >> I got rid of the word "delegation": the client does not delegate >> anything to an authorization server. If it would, this would mean >> that the authorization server >> would be able to act as the client and could know everything that >> the client will do, which comes into contradiction with the >> user's privacy. >> >> >> The above is not true. >> The Resource Owner is delegating access control to the AS in >> authorization use cases. >> >> The client is may be delegating user authentication to the AS in >> identity claim use cases. >> >> The AS can act as the client in many OAuth deployments, as the access >> token is a bearer token. That does not mean the AS knows what the >> client is doing. >> >> /Dick >> ᐧ >> -- >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth > --------------37267049F4897C115452165B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Justin,

Removing the IESG as this is really a more internal-to-the-group discussion, as it comes down to the scope of use cases that we want to address here in GNAP.

While it is definitely important to understand how and why OAuth 2 does things, we do need to keep use cases like Denis’s in mind.
Thanks.
It’s not unheard of today for a single OAuth 2 RS to accept tokens from multiple AS’s.

We are preparing the future. A simple case is to prove "who you are" and since banks "need to know their customers"
they would be well placed to provide an access token containing some verified personal attributes. 

For example, a student would like to change university and would need to present his prior graduations.
In such a case, each university or school would be well placed to produce such a proof by issuing an access token.

In fact, we’ve even got cases with things like the Solid project where the RS will take a token from :any: AS so long as it can verify that it’s approved by the resource owner. While the Solid platform has its own special layering in place to allow this, our model should not assume a closely-tied connection between an RS and any single AS. The question of :how: we solve that is, of course, up to the WG to figure out over time.

Would this mean that we strongly agree together that the model should not assume a closely-tied connection between an RS and any single AS ?

Taking that even further, I think the idea of an AS that’s personal to the user, to promote privacy and control, is a very good one.

In a previous message, I indicated that I have been able to understand what you mean by: an "AS that’s personal to the user" ?

In fact, this is one of the main selling points of UMA2 and its federated authorization mechanisms. With GNAP, we might be able to deliver
on this promise even more than UMA has been able to, and it’s my hope that we can have a cohesive protocol that allows both user-to-self
and user-to-another delegation sharing without needing to use different mechanisms. 

Additionally, the RS-first method is also something from the UMA2 work that we should be working on, as it touches on AS discovery, AS/RS communication, and a few other aspects of the protocol design. It’s not a trivial problem by any stretch, and there are huge privacy and security implications, but there’s both need for it and some good prior art to pull from. In fact, XYZ’s whole notion of a “transaction handle” is an adaptation of UMA2’s “permission ticket”. In UMA, this ticket is first issued to the RS by the AS, and the RS then hands it to the client, which starts the negotiation for access. I envision something very similar happening here with GNAP, where a client can get something to bootstrap the process at the AS. The important thing, to me, is that we don’t have to jump through a bunch of weird hoops such that the AS-first and RS-first cases look completely different, as they do in UMA2 and OAuth 2 respectively today. We’ve got the chance to have a clean and cohesive protocol here, let’s not miss that opportunity.

So in sum, the trust model of OAuth 2 is not sufficient to cover everything, and the model that Denis is proposing is something we should at least look at as a use case.
Where Denis and I seem to disagree is whether this trust model should be the :only: one that we address with the protocol.

Any trust relationship may be described using the following construction:  entity A trusts entity B for some action C.
If you have in mind additional trust relationships, would you be able to express them using this construction ?
Maybe you also have in mind some relationships that do not imply a form of trust ?

I strongly believe, as I believe much of this group does, that we can’t discount or ignore (or make things overly difficult for)
the tightly bound AS/RS combos, or any type of static setup where the RS offloads its trust fully to the AS.
But it’s my belief that we should be able to do so without needlessly throwing out all of the OAuth 2 use cases.

Reading these sentences confuses me again since they seem to mean that the model should assume a closely-tied connection between RSs and ASs.

In OAuth 2.0, the scope parameter allows the client to specify the desired scope of the requested security token in the context of the service or resource
where the token will be used. The values and associated semantics of scope are service specific and and expected to be described in the relevant service
documentation [RFC 8693]. Since the scope is RS dependent, the client MUST inform the AS about the identity of the RS, but this should be avoided for
privacy reasons.

Currently in OAuth 2.0, there is no protocol being defined to be able to know which attributes correspond to a given scope for a given RS. 
IMHO, the main idea is the following:  rather than using the scope parameter, the client should be able to inform directly the AS about
which attributes it needs. In this way, the client would not need to inform the AS for which RS these attributes are needed.

A major difference with OAuth 2.0 would be that attributes could be requested directly to an AS without using the pair scope/RS.
Such an approach would make the architecture scalable.

Denis


We shouldn’t let “OAuth 2 doesn’t do it that way” be the limiting factor here. We need to understand the what and wherefore of things that OAuth 2 is bad at, otherwise we’re just going to re-invent OAuth 2 and inherit its problems.

 — Justin

On Jun 26, 2020, at 1:39 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Denis, thanks for sharing your thoughts, some clarifications on your statements inserted:

On Fri, Jun 26, 2020 at 9:42 AM Denis <denis.ietf@free.fr> wrote:
<snip>

New proposed charter

<snip> 

Resource servers inform their clients about which access token formats are acceptable and depending upon the king of operation
that is requested, which kind of attributes are needed and from which ASs that my be obtained.

While at times this may be appropriate, at other times disclosing the attributes the RS requires is not needed by the client. For example, an enterprise client accessing a resource does not need to know which groups a user belongs to, but the RS may require that to determine if the user running the client has access..

A major difference with OAuth 2.0 is that there is no bilateral trust relationship between an authorization server and a resource server:
for a given category of attributes, a resource server may trust one or more authorization servers. Another major difference with OAuth 2.0.
is that the content of an attributes token is meant to be accessible to the client.
This is not how OAuth 2.0 works. See slides 7 and 8 from my original IETF presentation on what became OAuth 2.0


The AS may not even know who the RS (or PR in the slides) is.

<snip> 


I got rid of the word "delegation": the client does not delegate anything to an authorization server. If it would, this would mean that the authorization server
would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy.


The above is not true.
 
The Resource Owner is delegating access control to the AS in authorization use cases.

The client is may be delegating user authentication to the AS in identity claim use cases.

The AS can act as the client in many OAuth deployments, as the access token is a bearer token. That does not mean the AS knows what the client is doing. 

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


--------------37267049F4897C115452165B-- From nobody Mon Jun 29 07:28:20 2020 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 0F1B33A0F7B for ; Mon, 29 Jun 2020 07:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 6rSUMbeNcxlh for ; Mon, 29 Jun 2020 07:28:15 -0700 (PDT) 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 C5A303A0F67 for ; Mon, 29 Jun 2020 07:28:14 -0700 (PDT) Received: from [192.168.1.14] (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 05TES96X031928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Jun 2020 10:28:10 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_59294A0B-C13A-4CCD-BFD6-515ABBC85B15" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 29 Jun 2020 10:28:09 -0400 In-Reply-To: <624d15e8-48c0-4ef6-9429-d8fb79407d81@free.fr> Cc: txauth@ietf.org, Dick Hardt To: Denis References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <353AF4E4-4939-4994-960E-54B0AADC6253@mit.edu> <624d15e8-48c0-4ef6-9429-d8fb79407d81@free.fr> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 29 Jun 2020 14:28:18 -0000 --Apple-Mail=_59294A0B-C13A-4CCD-BFD6-515ABBC85B15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Denis, > On Jun 29, 2020, at 3:13 AM, Denis wrote: >=20 > Justin, >=20 >> Removing the IESG as this is really a more internal-to-the-group = discussion, as it comes down to the scope of use cases that we want to = address here in GNAP. =20 >>=20 >> While it is definitely important to understand how and why OAuth 2 = does things, we do need to keep use cases like Denis=E2=80=99s in mind. > Thanks. >> It=E2=80=99s not unheard of today for a single OAuth 2 RS to accept = tokens from multiple AS=E2=80=99s. > We are preparing the future. A simple case is to prove "who you are" = and since banks "need to know their customers"=20 > they would be well placed to provide an access token containing some = verified personal attributes. =20 >=20 > For example, a student would like to change university and would need = to present his prior graduations.=20 > In such a case, each university or school would be well placed to = produce such a proof by issuing an access token. >=20 This is a great example =E2=80=94 each university is definitely in place = to produce the attributes bound to the user, and therefore to host the = =E2=80=9Cgraduation proof=E2=80=9D API. But the question is, who will = produce the access tokens that can be used for each copy of that API? In the OAuth 2 trust model, each university would have its own AS = protecting its own API. That model still makes sense for a lot of = things, and maybe even this case as well. But each university could also = accept, say, access tokens from other universities within a consortium, = or from a trusted third-party agency, or even an arbitrary AS as long as = the access token can prove it=E2=80=99s bound to a user credential the = university can trust as being that former student. There are a lot of = possibilities, and the details of most of these other scenarios are = going to rely on additional pieces that will be defined outside of GNAP. >> In fact, we=E2=80=99ve even got cases with things like the Solid = project where the RS will take a token from :any: AS so long as it can = verify that it=E2=80=99s approved by the resource owner. While the Solid = platform has its own special layering in place to allow this, our model = should not assume a closely-tied connection between an RS and any single = AS. The question of :how: we solve that is, of course, up to the WG to = figure out over time. > Would this mean that we strongly agree together that the model should = not assume a closely-tied connection between an RS and any single AS ? >=20 Correct, we shouldn=E2=80=99t assume it, but we should also not preclude = it. I think a lot of the internet is going keep with that model for some = time to come, even if it=E2=80=99s not universal. >> Taking that even further, I think the idea of an AS that=E2=80=99s = personal to the user, to promote privacy and control, is a very good = one. > In a previous message, I indicated that I have been able to understand = what you mean by: an "AS that=E2=80=99s personal to the user" ? >=20 This means that a user has their own AS that=E2=80=99s under their = personal control. Maybe it=E2=80=99s something they host on the web = somewhere, or maybe it=E2=80=99s an app on their personal device, or any = number of things. As below, this is the idealized UMA model below, where = the user gets to decide which AS to use to protect their data API. >> In fact, this is one of the main selling points of UMA2 and its = federated authorization mechanisms. With GNAP, we might be able to = deliver=20 >> on this promise even more than UMA has been able to, and it=E2=80=99s = my hope that we can have a cohesive protocol that allows both = user-to-self=20 >> and user-to-another delegation sharing without needing to use = different mechanisms.=20 >>=20 >> Additionally, the RS-first method is also something from the UMA2 = work that we should be working on, as it touches on AS discovery, AS/RS = communication, and a few other aspects of the protocol design. It=E2=80=99= s not a trivial problem by any stretch, and there are huge privacy and = security implications, but there=E2=80=99s both need for it and some = good prior art to pull from. In fact, XYZ=E2=80=99s whole notion of a = =E2=80=9Ctransaction handle=E2=80=9D is an adaptation of UMA2=E2=80=99s = =E2=80=9Cpermission ticket=E2=80=9D. In UMA, this ticket is first issued = to the RS by the AS, and the RS then hands it to the client, which = starts the negotiation for access. I envision something very similar = happening here with GNAP, where a client can get something to bootstrap = the process at the AS. The important thing, to me, is that we don=E2=80=99= t have to jump through a bunch of weird hoops such that the AS-first and = RS-first cases look completely different, as they do in UMA2 and OAuth 2 = respectively today. We=E2=80=99ve got the chance to have a clean and = cohesive protocol here, let=E2=80=99s not miss that opportunity. >>=20 >> So in sum, the trust model of OAuth 2 is not sufficient to cover = everything, and the model that Denis is proposing is something we should = at least look at as a use case.=20 >> Where Denis and I seem to disagree is whether this trust model should = be the :only: one that we address with the protocol. > Any trust relationship may be described using the following = construction: entity A trusts entity B for some action C. > If you have in mind additional trust relationships, would you be able = to express them using this construction ? > Maybe you also have in mind some relationships that do not imply a = form of trust ? >=20 The difference isn=E2=80=99t on what =E2=80=9Ctrust=E2=80=9D means, the = difference is on which parties are A, B, and C in your equation above, = and more importantly, *why* they trust. There are scenarios where the RS = would trust the user because the RS knows the user, not because of which = AS the user is using.=20 >> I strongly believe, as I believe much of this group does, that we = can=E2=80=99t discount or ignore (or make things overly difficult for)=20= >> the tightly bound AS/RS combos, or any type of static setup where the = RS offloads its trust fully to the AS.=20 >> But it=E2=80=99s my belief that we should be able to do so without = needlessly throwing out all of the OAuth 2 use cases. > Reading these sentences confuses me again since they seem to mean that = the model should assume a closely-tied connection between RSs and ASs. >=20 > In OAuth 2.0, the scope parameter allows the client to specify the = desired scope of the requested security token in the context of the = service or resource > where the token will be used. The values and associated semantics of = scope are service specific and and expected to be described in the = relevant service=20 > documentation [RFC 8693]. Since the scope is RS dependent, the client = MUST inform the AS about the identity of the RS, but this should be = avoided for=20 > privacy reasons. >=20 The scope doesn=E2=80=99t have to be RS dependent, you can have many = RS=E2=80=99s implementing the same API with the same scopes. There are = of course plenty of instances where the scope does identify the RS, but = there=E2=80=99s also been other work in the OAuth WG like the = =E2=80=9Cresource=E2=80=9D parameter [RFC8707] to provide explicit = direction as well. Honestly that aspect of the request is a bit of a = mess in OAuth right now, and it=E2=80=99s one of the main things I think = we need to clean up here in GNAP. Incidentally, this is why I=E2=80=99m = so against simply importing =E2=80=9Cscope=E2=80=9D and RAR directly = into GNAP, we need to move past the intrinsic limitations in those = systems. > Currently in OAuth 2.0, there is no protocol being defined to be able = to know which attributes correspond to a given scope for a given RS. =20 > IMHO, the main idea is the following: rather than using the scope = parameter, the client should be able to inform directly the AS about=20 > which attributes it needs. In this way, the client would not need to = inform the AS for which RS these attributes are needed. >=20 > A major difference with OAuth 2.0 would be that attributes could be = requested directly to an AS without using the pair scope/RS. > Such an approach would make the architecture scalable. >=20 In GNAP, we will be defining ways to do fine-grained access control. = This will let the client specify what it wants across a wide range of = dimensions, and that=E2=80=99s a really powerful pattern. One of the = dimensions that the client :could: specify to the AS is which RS it = wants to talk to. In some deployments, this will let the AS draft a = token that is limited to just that single RS, perhaps by encrypting it = against the RS=E2=80=99s key or setting an audience-restriction field. = So using the syntax from XYX and RAR (which is a back-port of part of = XYZ to OAuth 2), you get something like this: { resources: { location: [=E2=80=9Chttps://rs.example.com/resourc= e =E2=80=9D], action: [=E2=80=9Cread=E2=80=9D] } } But there are other cases, like what you=E2=80=99re talking about in = this thread, where you don=E2=80=99t want the AS to know which RS the = client is going to talk to. The client knows, and it just needs to get a = token that the RS will trust for the action it wants to take. Using the = same syntax, that would look something like this: { resources: { action: [=E2=80=9Cread=E2=80=9D] type: =E2=80=9Cproof_of_graduation=E2=80=9D } } Which one of these do you use? That=E2=80=99s up to your API deployment. = What will your RS want or need to know in order to fulfill the request? = What will your AS need in order to create a token that will work for the = deployed system? That=E2=80=99s not something the protocol should = dictate, but it should allow that choice. The client needs to know what = to ask for, the AS needs to know what to expect and issue, and the RS = needs to know what to look for in (or about) the token. This is one of the places where I think we can really start to innovate = and bring these worlds together. There=E2=80=99s kind of an artificial = split right now and we can do better. OAuth 2 moved us past the concept = of the AS and RS being the same system (just called the =E2=80=9Cserver=E2= =80=9D in OAuth 1), and UMA pushed the conversation further into the AS = and RS being introduced to each other during the protocol flow. GNAP can = keep this going, and do so without giving up the ability for the RS to = be tightly bound to the AS, if the deployment desires or requires it. I = think we can do these advanced distributed trust models without getting = in the way of the classical AS-as-the-hub trust model form OAuth 2, and = both become options that (importantly) work pretty similarly within the = GNAP protocol itself. =E2=80=94 Justin > Denis >=20 >>=20 >> We shouldn=E2=80=99t let =E2=80=9COAuth 2 doesn=E2=80=99t do it that = way=E2=80=9D be the limiting factor here. We need to understand the what = and wherefore of things that OAuth 2 is bad at, otherwise we=E2=80=99re = just going to re-invent OAuth 2 and inherit its problems. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jun 26, 2020, at 1:39 PM, Dick Hardt > wrote: >>>=20 >>> Denis, thanks for sharing your thoughts, some clarifications on your = statements inserted: >>>=20 >>> On Fri, Jun 26, 2020 at 9:42 AM Denis > wrote: >>> >>> New proposed charter >>>=20 >>> =20 >>>=20 >>> Resource servers inform their clients about which access token = formats are acceptable and depending upon the king of operation >>> that is requested, which kind of attributes are needed and from = which ASs that my be obtained. >>>=20 >>> While at times this may be appropriate, at other times disclosing = the attributes the RS requires is not needed by the client. For example, = an enterprise client accessing a resource does not need to know which = groups a user belongs to, but the RS may require that to determine if = the user running the client has access.. >>>=20 >>> A major difference with OAuth 2.0 is that there is no bilateral = trust relationship between an authorization server and a resource = server:=20 >>> for a given category of attributes, a resource server may trust one = or more authorization servers. Another major difference with OAuth 2.0. >>> is that the content of an attributes token is meant to be accessible = to the client. >>> This is not how OAuth 2.0 works. See slides 7 and 8 from my original = IETF presentation on what became OAuth 2.0 >>>=20 >>> = https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation = >>>=20 >>> The AS may not even know who the RS (or PR in the slides) is. >>>=20 >>> =20 >>>=20 >>> I got rid of the word "delegation": the client does not delegate = anything to an authorization server. If it would, this would mean that = the authorization server=20 >>> would be able to act as the client and could know everything that = the client will do, which comes into contradiction with the user's = privacy. >>>=20 >>>=20 >>> The above is not true. >>> =20 >>> The Resource Owner is delegating access control to the AS in = authorization use cases. >>>=20 >>> The client is may be delegating user authentication to the AS in = identity claim use cases. >>>=20 >>> The AS can act as the client in many OAuth deployments, as the = access token is a bearer token. That does not mean the AS knows what the = client is doing.=20 >>>=20 >>> /Dick >>> =20 >>> =E1=90=A7 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >>=20 >=20 --Apple-Mail=_59294A0B-C13A-4CCD-BFD6-515ABBC85B15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Denis,

On Jun 29, 2020, at 3:13 AM, Denis <denis.ietf@free.fr> = wrote:

=20
Justin,

=20 Removing the IESG as this is really a more internal-to-the-group discussion, as it comes down to the scope of use cases that we want to address here in GNAP.

While it is definitely important to understand how and why OAuth 2 does things, we do need to keep use cases like Denis=E2=80=99s in mind.
Thanks.
It=E2=80=99s not unheard of today for a single = OAuth 2 RS to accept tokens from multiple AS=E2=80=99s.

We are preparing the future. A simple = case is to prove "who you are" and since banks "need to know their customers"
they would be well placed to provide an access token containing some verified personal attributes. 

For example, a student would like to change university and would need to present his prior graduations.
In such a case, each university or school would be well placed to produce such a proof by issuing an access = token.

This is a great example =E2=80=94 = each university is definitely in place to produce the attributes bound = to the user, and therefore to host the =E2=80=9Cgraduation proof=E2=80=9D = API. But the question is, who will produce the access tokens that can be = used for each copy of that API?

In = the OAuth 2 trust model, each university would have its own AS = protecting its own API. That model still makes sense for a lot of = things, and maybe even this case as well. But each university could also = accept, say, access tokens from other universities within a consortium, = or from a trusted third-party agency, or even an arbitrary AS as long as = the access token can prove it=E2=80=99s bound to a user credential the = university can trust as being that former student. There are a lot of = possibilities, and the details of most of these other scenarios are = going to rely on additional pieces that will be defined outside of = GNAP.

In fact, we=E2=80=99ve even got cases with things = like the Solid project where the RS will take a token from :any: AS so long as it can verify that it=E2=80=99s approved by the resource = owner. While the Solid platform has its own special layering in place to allow this, our model should not assume a closely-tied connection between an RS and any single AS. The question of :how: we solve that is, of course, up to the WG to figure out over time.

Would this mean that we strongly agree = together that the model should not assume a closely-tied connection between an RS and any single AS ?

Correct, we = shouldn=E2=80=99t assume it, but we should also not preclude it. I think = a lot of the internet is going keep with that model for some time to = come, even if it=E2=80=99s not universal.

Taking that even further, I think the idea of an = AS that=E2=80=99s personal to the user, to promote privacy and = control, is a very good one.

In a previous message, I indicated that I = have been able to understand what you mean by: an "AS that=E2=80=99s personal to the = user" ?

This means that = a user has their own AS that=E2=80=99s under their personal control. = Maybe it=E2=80=99s something they host on the web somewhere, or maybe = it=E2=80=99s an app on their personal device, or any number of things. = As below, this is the idealized UMA model below, where the user gets to = decide which AS to use to protect their data API.

In fact, this is one of the main selling points of UMA2 and its federated authorization mechanisms. With GNAP, we might be able to deliver
on this promise even more than UMA has been able to, and it=E2=80=99= s my hope that we can have a cohesive protocol that allows both user-to-self
and user-to-another delegation sharing without needing to use different mechanisms. 

Additionally, the RS-first method is also = something from the UMA2 work that we should be working on, as it touches on AS discovery, AS/RS communication, and a few other aspects of the protocol design. It=E2=80=99s not a trivial problem by any = stretch, and there are huge privacy and security implications, but there=E2=80=99s both need for it and some good prior art to pull = from. In fact, XYZ=E2=80=99s whole notion of a =E2=80=9Ctransaction = handle=E2=80=9D is an adaptation of UMA2=E2=80=99s =E2=80=9Cpermission ticket=E2=80=9D. = In UMA, this ticket is first issued to the RS by the AS, and the RS then hands it to the client, which starts the negotiation for access. I envision something very similar happening here with GNAP, where a client can get something to bootstrap the process at the AS. The important thing, to me, is that we don=E2=80=99t have to jump = through a bunch of weird hoops such that the AS-first and RS-first cases look completely different, as they do in UMA2 and OAuth 2 respectively today. We=E2=80=99ve got the chance to have a clean = and cohesive protocol here, let=E2=80=99s not miss that = opportunity.

So in sum, the trust model of OAuth 2 is not sufficient to cover everything, and the model that Denis is proposing is something we should at least look at as a use case.
Where Denis and I seem to disagree is whether this trust model should be the :only: one that we address with the protocol. =

Any trust relationship may be described = using the following construction:  entity A trusts entity B for some action C.
If you have in mind additional trust relationships, would you be able to express them using this construction ?
Maybe you also have in mind some relationships that do not imply a form of trust ?

The = difference isn=E2=80=99t on what =E2=80=9Ctrust=E2=80=9D means, the = difference is on which parties are A, B, and C in your equation above, = and more importantly, *why* they trust. There are scenarios where the RS = would trust the user because the RS knows the user, not because of which = AS the user is using. 

I strongly believe, as I believe much of this = group does, that we can=E2=80=99t discount or ignore (or make things = overly difficult for)
the tightly bound AS/RS combos, or any type of static setup where the RS offloads its trust fully to the AS.
But it=E2=80=99s my belief that we should be able to do so = without needlessly throwing out all of the OAuth 2 use cases.

Reading these sentences confuses me again = since they seem to mean that the model should assume a closely-tied connection between RSs and ASs.

In OAuth 2.0, the scope parameter allows = the client to specify the desired scope of the requested security token in the context of the service or resource
where the token will be used. The values and associated semantics of scope are service specific and and expected to be described in the relevant service
documentation [RFC 8693]. Since the scope is RS dependent, the client MUST inform the AS about the identity of the RS, but this should be avoided for
privacy reasons.

The scope doesn=E2=80=99= t have to be RS dependent, you can have many RS=E2=80=99s implementing = the same API with the same scopes. There are of course plenty of = instances where the scope does identify the RS, but there=E2=80=99s also = been other work in the OAuth WG like the =E2=80=9Cresource=E2=80=9D = parameter [RFC8707] to provide explicit direction as well. Honestly that = aspect of the request is a bit of a mess in OAuth right now, and it=E2=80=99= s one of the main things I think we need to clean up here in GNAP. = Incidentally, this is why I=E2=80=99m so against simply importing = =E2=80=9Cscope=E2=80=9D and RAR directly into GNAP, we need to move past = the intrinsic limitations in those systems.

Currently in OAuth 2.0, there is no protocol being defined to = be able to know which attributes correspond to a given scope for a given RS. 
IMHO, the main idea is the following:  rather than using the = scope parameter, the client should be able to inform directly the AS about
which attributes it needs. In this way, the client would not need to inform the AS for which RS these attributes are needed.

A major difference with OAuth 2.0 would be that attributes = could be requested directly to an AS without using the pair scope/RS.
Such an approach would make the architecture scalable.


In = GNAP, we will be defining ways to do fine-grained access control. This = will let the client specify what it wants across a wide range of = dimensions, and that=E2=80=99s a really powerful pattern. One of the = dimensions that the client :could: specify to the AS is which RS it = wants to talk to. In some deployments, this will let the AS draft a = token that is limited to just that single RS, perhaps by encrypting it = against the RS=E2=80=99s key or setting an audience-restriction field. = So using the syntax from XYX and RAR (which is a back-port of part of = XYZ to OAuth 2), you get something like this:

{
= resources: {
location: [=E2=80=9C= https://rs.example.com/resource=E2=80=9D],
= action: [=E2=80=9Cread=E2=80=9D]
= }
}

But there are other cases, like what you=E2=80=99re = talking about in this thread, where you don=E2=80=99t want the AS to = know which RS the client is going to talk to. The client knows, and it = just needs to get a token that the RS will trust for the action it wants = to take. Using the same syntax, that would look something like = this:

{
= resources: {
action: = [=E2=80=9Cread=E2=80=9D]
type: = =E2=80=9Cproof_of_graduation=E2=80=9D
= }
}

Which one of these do you use? That=E2=80=99s up = to your API deployment. What will your RS want or need to know in order = to fulfill the request? What will your AS need in order to create a = token that will work for the deployed system? That=E2=80=99s not = something the protocol should dictate, but it should allow that choice. = The client needs to know what to ask for, the AS needs to know what to = expect and issue, and the RS needs to know what to look for in (or = about) the token.

This is one of the = places where I think we can really start to innovate and bring these = worlds together. There=E2=80=99s kind of an artificial split right now = and we can do better. OAuth 2 moved us past the concept of the AS and RS = being the same system (just called the =E2=80=9Cserver=E2=80=9D in OAuth = 1), and UMA pushed the conversation further into the AS and RS being = introduced to each other during the protocol flow. GNAP can keep this = going, and do so without giving up the ability for the RS to be tightly = bound to the AS, if the deployment desires or requires it. I think we = can do these advanced distributed trust models without getting in the = way of the classical AS-as-the-hub trust model form OAuth 2, and both = become options that (importantly) work pretty similarly within the GNAP = protocol itself.

 =E2=80=94 = Justin

Denis


We shouldn=E2=80=99t let =E2=80=9COAuth 2 = doesn=E2=80=99t do it that way=E2=80=9D be the limiting factor here. We need to understand the what and wherefore of things that OAuth 2 is bad at, otherwise we=E2=80=99r= e just going to re-invent OAuth 2 and inherit its problems.

 =E2=80=94 Justin

On Jun 26, 2020, at 1:39 PM, Dick Hardt = <dick.hardt@gmail.com> wrote:

=20
Denis, thanks for sharing = your thoughts, some clarifications on your statements inserted:

On Fri, Jun 26, = 2020 at 9:42 AM Denis <denis.ietf@free.fr> wrote:
<snip>

New proposed charter

<snip> 

Resource servers inform their clients about which access token formats are acceptable and depending upon the king of = operation
that is requested, which kind of attributes are needed and from which ASs that my be = obtained.
=
While at times this may be = appropriate, at other times disclosing the attributes the RS requires is not needed by the client. For example, an enterprise client accessing a resource does not need to know which groups a user belongs to, but the RS may require that to determine if the user running the client has access..

A major difference with OAuth 2.0 is that there is no bilateral trust relationship between an authorization server and a resource server:
for a given category of attributes, a resource server may trust one or more authorization servers. Another major difference with OAuth = 2.0.
is that the content of an attributes token is meant to be accessible to the = client.
This is not how OAuth 2.0 works. See slides 7 and 8 from my original IETF presentation on what became OAuth 2.0

https://www.slideshare.net/gueste648b/ietf-77-oau= th-wrap-presentation

The AS may not even know who the RS = (or PR in the slides) is.

<snip> 


I got rid of the word "delegation": the client does not delegate anything to an authorization server. If it would, this would mean that the authorization server =
would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy.


The above is not true.
 
The Resource Owner is delegating = access control to the AS in authorization use cases.

The client is may be delegating user authentication to the AS in identity claim use cases.

The AS can act as the client in many OAuth deployments, as the access token is a bearer token. That does not mean the AS knows what the client is doing. 

/Dick
 
3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org= /mailman/listinfo/txauth



= --Apple-Mail=_59294A0B-C13A-4CCD-BFD6-515ABBC85B15-- From nobody Mon Jun 29 09:02:42 2020 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 2DE8C3A0400 for ; Mon, 29 Jun 2020 09:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=securekeytechnologies.onmicrosoft.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 lbMWsk8EFYtg for ; Mon, 29 Jun 2020 09:02:39 -0700 (PDT) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660091.outbound.protection.outlook.com [40.107.66.91]) (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 303573A03F6 for ; Mon, 29 Jun 2020 09:02:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cN/iJTiPyStGP/eZ5+k80Cav91lbcQPTIMaFtXnhbimgdkcuM3TuUQEWAjQN7mUuOu/Cl/i1CYV4R2ehFy9OsbFn5p0hp01FxTpqw3CwChFmfcUstTZIddRmw+6wn5mIJ/1fgt2Lr/nmm9znj76/8UVL2BVSscLTfOCDYDgCMEl0GwKwfGSTXoFkLPZQ5ga0WteVk8LUMheOBw2L1dwaa7Yh/1Hs9ZSxNva9mjP2l88gIZiexEbu8KtYF37QC8Nr/a1WzfhEca36jMnmh5GewFcB8SiwLOiF/Ieef/Ytn24sMSRqhw1epv/obPSH+zH62TyycGfye3c2nGBBE0qvNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FAbLCJSHTyrpuRImDFc8V1RZhcQqg+AtjRs6h/E/QCo=; b=ZWhBMv+FW/+SVxV9PLfJE+YIVfYFrjd/Y6o0cUL33wj6Qbtj4CRmmd9PbyaW98J9DNvjqn6bV56DM6L9CJMP4dvmkaPjHYh+PePnH0jzYeoie615aQ7xcxByynsEwb8G97+geWpbIYgDsQ6550l7Yq3449fG4N5ZDtURHA4ahUyQ3SjRrtCYQFS9gceWIYkqvLZf7ePNTCpgS3FqkazauMT/6kDsO8NZmrKhcd20jO+WbxzjRq2X+sSMyv2jL6Q7+RbiyLdhnskKxYQlNjQsFmasZ4vbmmEcibttND1TaHC5Ij0XFzG9dnRPelaNryluGmpyam+x/D+MfkGl2/rhKw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=securekey.com; dmarc=pass action=none header.from=securekey.com; dkim=pass header.d=securekey.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securekeytechnologies.onmicrosoft.com; s=selector1-securekeytechnologies-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FAbLCJSHTyrpuRImDFc8V1RZhcQqg+AtjRs6h/E/QCo=; b=xgp/6H1iUojUFEwShG8tOFWuH4Eagt3D0zm7+NxvKvofpf72kBNalsuga5omvf+EO4+k+6nZNSFtJ6SZ3W7t/3G0JNH1UNoN9gVq8+PGtOgpLMJLH3ZnXYL0U5h6ArMTHWux4xVR65NY/F2lkB0oraIWw2MBXEYT2dJhLATElY8= Received: from YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:20::25) by YTBPR01MB3437.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:1c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Mon, 29 Jun 2020 16:02:32 +0000 Received: from YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM ([fe80::1146:fc82:c5e4:b710]) by YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM ([fe80::1146:fc82:c5e4:b710%6]) with mapi id 15.20.3131.026; Mon, 29 Jun 2020 16:02:32 +0000 From: Mike Varley To: Denis , Justin Richer , "txauth@ietf.org" CC: Dick Hardt Thread-Topic: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) Thread-Index: AQHWS9R4OmNt+Q5cMEqZqmxQCAM7BqjrGeIAgAAQEoCAAbiGAIACT42AgABQpgA= Date: Mon, 29 Jun 2020 16:02:32 +0000 Message-ID: <9668FD63-A2E3-4DC1-BF13-558B87C05E86@securekey.com> References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <353AF4E4-4939-4994-960E-54B0AADC6253@mit.edu> <624d15e8-48c0-4ef6-9429-d8fb79407d81@free.fr> In-Reply-To: <624d15e8-48c0-4ef6-9429-d8fb79407d81@free.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 authentication-results: free.fr; dkim=none (message not signed) header.d=none;free.fr; dmarc=none action=none header.from=securekey.com; x-originating-ip: [50.101.239.135] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8c6b971b-8c11-4085-b24f-08d81c45d514 x-ms-traffictypediagnostic: YTBPR01MB3437: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 044968D9E1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 54scbOymMPMl3gesQ/IPzNryvqOqu+MysYs3/9kuXwrThOpMqjEtVxFDIqBKLmcB0iUqFNZ44IL6k6Gr7hxAAffuCGAuColi4bUk5oELmXpY9nRkaiRC3E8mMHiq5Hy9L28V3PN9DosNkSQ/kCNkniXJFqrXkEm8PrPWMiY8wdO0EG9X6t7/MQkt4LqrHvBBWk+ID2xQg0S2+JZG2NFr+65E7byFh5pCN/Dbqwl1eOq97PQVWjlDMuPcpzGgN0+m6m6KvkuvmGu9U32V2bMfSQa5XkTDmb04vP29gT8bNDRKnDEBFMQhwQ4B6qh9/Ly6m4VfDo0c2ANPqyHx57u7rnVjVtpDchYy27cPZhVqSGpXECflV76kwc+puDn9LYVn x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39840400004)(366004)(396003)(376002)(346002)(26005)(2616005)(44832011)(33656002)(66446008)(316002)(4326008)(478600001)(66556008)(76116006)(66946007)(91956017)(2906002)(66476007)(6486002)(6512007)(36756003)(64756008)(5660300002)(8936002)(6506007)(110136005)(8676002)(186003)(83380400001)(86362001)(71200400001)(15866825006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: m9OiVUW2OIXIq4CY48d2gmqZ1kv7n7sPHfAm2qWfkobTq9Faa5Ubgonw85VDdwvUINwLUwWmgp33PsAlWtpA9TRcojG2tA9/XLTbC0pVFhn3hls4RZQ3ETkC8NCl1x9gaEaH3ZOCARA80GkYxNcUgxqqvE20+StKpZeoP5jFb2ghyAuq7vy1+Ia3FMCthejTlZsEKRQzBidz9nKbWPM6LZ17z7MmIOHzYi5oczyllJUHc+apbhlH28JwhdI7iqvGNytvCXc/mTN30fgvOemofhutB18uJ8FW0zX/Bn5hRdvM4nqoDAn3jTjGGgygomgCy4fk6hVqwPYtOovLnewfVN6aL1cpIGVvrw+qWFMmhtMs8hchK/gbWJzpFYPKk9iFqlAEWC6dsTv7FehM8nlozgK8g65t4x+M0skQ0Pr+L8AwEvNwg/ZE+ZeQBsN7cUX0uZ4KOgYHtfcpLlMyfq1974fpzCULe6I2JlY5nBxJKCh6VPP7hDvtrJ3ArHiUNy0K x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_9668FD63A2E34DC1BF13558B87C05E86securekeycom_" MIME-Version: 1.0 X-OriginatorOrg: securekey.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTOPR0101MB2316.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 8c6b971b-8c11-4085-b24f-08d81c45d514 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 16:02:32.5530 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e211fbf0-7d88-4a7c-b5b5-09a66b0b7ad0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kvnCZ68vyPWb5XFxllETOHMdKVaHctQhHDgOYQd0w489Yrv/VJiMgPlS/kwT4VTZNUZJw7vSVTBTwAO2znufSAGHkMJy4V0U+eJ0OmzJKEo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3437 Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 29 Jun 2020 16:02:41 -0000 --_000_9668FD63A2E34DC1BF13558B87C05E86securekeycom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gRGVuaXMsIGFsbCwgSSBqdXN0IHdhbnRlZCB0byBqdW1wIGluIG9uIHRoaXMgcG9pbnQg YmVsb3c6DQoNCkZyb206IFR4YXV0aCA8dHhhdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFs ZiBvZiBEZW5pcyA8ZGVuaXMuaWV0ZkBmcmVlLmZyPg0KRGF0ZTogTW9uZGF5LCBKdW5lIDI5LCAy MDIwIGF0IDM6MTQgQU0NCg0KDQpBbnkgdHJ1c3QgcmVsYXRpb25zaGlwIG1heSBiZSBkZXNjcmli ZWQgdXNpbmcgdGhlIGZvbGxvd2luZyBjb25zdHJ1Y3Rpb246ICBlbnRpdHkgQSB0cnVzdHMgZW50 aXR5IEIgZm9yIHNvbWUgYWN0aW9uIEMuDQpJZiB5b3UgaGF2ZSBpbiBtaW5kIGFkZGl0aW9uYWwg dHJ1c3QgcmVsYXRpb25zaGlwcywgd291bGQgeW91IGJlIGFibGUgdG8gZXhwcmVzcyB0aGVtIHVz aW5nIHRoaXMgY29uc3RydWN0aW9uID8NCk1heWJlIHlvdSBhbHNvIGhhdmUgaW4gbWluZCBzb21l IHJlbGF0aW9uc2hpcHMgdGhhdCBkbyBub3QgaW1wbHkgYSBmb3JtIG9mIHRydXN0ID8NCg0KDQoN ClRoZXJlIGlzIGEgcHJveHkvYnJva2VyIG1vZGVsIHdoaWNoIHNvcnQgb2YgaXMgZGVzY3JpYmVk IGJ5IHRoZSBhYm92ZSwgYnV0IEnigJlkIGxpa2UgdG8gY2FsbCBvdXQgYmVsb3cuDQoNClRoZXJl IGFyZSBjYXNlcyB3aGVyZSBBIHRydXN0cyBaIGFuZCAgQiB0cnVzdHMgWiwgYnV0IEEgYW5kIEIg ZG8gbm90IGtub3cvdHJ1c3QgZWFjaCBvdGhlciBkaXJlY3RseSwgYW5kIFogaXMgTm90IHRoZSBB UyAoYnV0IHRoZXJlIGlzIGEgdHJ1c3QgcmVsYXRpb25zaGlwIGJldHdlZW4gWiBhbmQgdGhlIEFT IOKAkyB0aGlzIGFsbG93cyBmb3IgbW9yZSB0aGFuIG9uZSBBUyBpbiB0aGUgdHJ1c3QgZnJhbWV3 b3JrKS4gSW4gb3JkZXIgZm9yIEEgYW5kIEIgdG8gaW50ZXJhY3QsIHRoZSBBUyB3aWxsIGFjdCBh cyBhIOKAmGxvY2F0b3LigJkgc2VydmljZSBhbmQgc3ViamVjdC1yZXByZXNlbnRhdGl2ZSwgYnV0 IGFueSBhc3NvY2lhdGVkIGFjY2VzcyB0b2tlbnMgdGhlIEFTIGdlbmVyYXRlIHdpbGwgcmVxdWly ZSBhc3N1cmFuY2VzIGZyb20gWiB0aGF0IHRoZSBwYXJ0aWNpcGFudHMgaW4gdGhlIHRyYW5zYWN0 aW9uIGFyZSBsZWdpdGltYXRlIGVudGl0aWVzIGluIHRoZSB0cmFuc2FjdGlvbi4NCg0KSGVyZSBp cyBhIGZvciBleGFtcGxlOiBBIGlzIGEgcmVudGFsIGNhciBjb21wYW55LCBCIGlzIGEgRE1WLiBU aGUgQVMgaXMgYSBwZXJzb25hbCBkaWdpdGFsIGlkZW50aXR5IG1hbmFnZW1lbnQgc2VydmljZSAo KmNvdWdoKiB3YWxsZXQgKmNvdWdoKikgdGhhdCBpbnRlcmFjdHMgd2l0aCB0aGUgbGljZW5zZSBo b2xkZXIvUmVudGVyLiBBLCBCLCBhbmQgQVMgaGF2ZSBhIHRydXN0IHJlbGF0aW9uc2hpcCBhbmQg ZGVmaW5lZCByb2xlIGluIGFuIG9yZ2FuaXphdGlvbiBaLiBXaGVuIHRoZSBSZW50ZXIgd2lzaGVz IHRvIHByb3ZpZGUgaGlzIGVsaWdpYmlsaXR5IHRvIGRyaXZlIHRvIEEsIHRoZSBBUyBtdXN0IHBy b3ZpZGU6DQoNCiAgMS4gIEV2aWRlbmNlIHRvIEEgZnJvbSBaIHRoYXQgQiBpcyBhIHF1YWxpZmll ZCBETVYgKHBlcm1pdHRlZCB0byBwcm92aWRlIHRoZSByZXF1aXJlZCBpbmZvKS4NCiAgMi4gIEV2 aWRlbmNlIHRvIEIgZnJvbSBaIHRoYXQgQSBpcyBhIHF1YWxpZmllZCBSZW50YWwgQ2FyIENvbXBh bnkgKHBlcm1pdHRlZCB0byBjb2xsZWN0IHRoZSByZXF1aXJlZCBpbnRvKS4NCiAgMy4gIEV2aWRl bmNlIHRvIGJvdGggQSBhbmQgQiBmcm9tIFogdGhhdCB0aGUgQVMgaXMgYSB0cnVzdGVkIHN1Ympl Y3QgcmVwcmVzZW50YXRpdmUuDQogIDQuICBBIHJvdXRlIGZvciBBIGFuZCBCIHRvIGNvbW11bmlj YXRlIHdpdGggZWFjaCBvdGhlciB3aXRoIGFsbCB0aGVzZSBhY2Nlc3MgcGVybWlzc2lvbnMuDQoN Ck5vdGUgaW4gdGhpcyBtb2RlbCB0aGUgQVMgY2FuIGFsc28gYmUgYSB0cnVzdGVkIHBhcnRpY2lw YW50IGluIGFub3RoZXIgWisxIHRydXN0IGZyYW1ld29yay4NCg0KSSBzZWUgR05BUCBhcyBhbiBv cHBvcnR1bml0eSB0byBzdXBwb3J0IHRoZSBhYm92ZSBtb2RlbCB3aXRoIGZsZXhpYmxlIHVzZXIg YWdlbnRzLCBBUywgZGlzY292ZXJ5LCB0b2tlbiBzdHJ1Y3R1cmVzIGFuZCBjcnlwdG8uDQoNClRo YW5rcywNCg0KTVYNCg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBmb3IgdGhl IHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnRzIGFuZCBtYXkgYmUgcHJpdmlsZWdl ZCwgY29uZmlkZW50aWFsIG9yIG90aGVyd2lzZSBleGVtcHQgZnJvbSBkaXNjbG9zdXJlIHVuZGVy IGxhdy4gQW55IGRpc3RyaWJ1dGlvbiwgcHJpbnRpbmcgb3Igb3RoZXIgdXNlIGJ5IGFueW9uZSBv dGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFy ZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5LCBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoaXMgZW1haWwgYW5kIGl0cyBhdHRh Y2htZW50cy4NCg== --_000_9668FD63A2E34DC1BF13558B87C05E86securekeycom_ Content-Type: text/html; charset="utf-8" Content-ID: <66C3AA8C2F448A49BBBC7B1491AAC046@CANPRD01.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDoxMjUwOTcwMzkyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczoyNjc2NTU4NiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhlbGxvIERlbmlzLCBhbGwsIEkganVzdCB3YW50ZWQgdG8ganVtcCBpbiBv biB0aGlzIHBvaW50IGJlbG93OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+VHhhdXRoICZsdDt0eGF1dGgtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9m IERlbmlzICZsdDtkZW5pcy5pZXRmQGZyZWUuZnImZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRh eSwgSnVuZSAyOSwgMjAyMCBhdCAzOjE0IEFNPGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BbnkgdHJ1c3QgcmVs YXRpb25zaGlwIG1heSBiZSBkZXNjcmliZWQgdXNpbmcgdGhlIGZvbGxvd2luZyBjb25zdHJ1Y3Rp b246Jm5ic3A7IGVudGl0eSBBIHRydXN0cyBlbnRpdHkgQiBmb3Igc29tZSBhY3Rpb24gQy48YnI+ DQpJZiB5b3UgaGF2ZSBpbiBtaW5kIGFkZGl0aW9uYWwgdHJ1c3QgcmVsYXRpb25zaGlwcywgd291 bGQgeW91IGJlIGFibGUgdG8gZXhwcmVzcyB0aGVtIHVzaW5nIHRoaXMgY29uc3RydWN0aW9uID88 YnI+DQpNYXliZSB5b3UgYWxzbyBoYXZlIGluIG1pbmQgc29tZSByZWxhdGlvbnNoaXBzIHRoYXQg ZG8gbm90IGltcGx5IGEgZm9ybSBvZiB0cnVzdCA/PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPlRoZXJlIGlzIGEg cHJveHkvYnJva2VyIG1vZGVsIHdoaWNoIHNvcnQgb2YgaXMgZGVzY3JpYmVkIGJ5IHRoZSBhYm92 ZSwgYnV0IEnigJlkIGxpa2UgdG8gY2FsbCBvdXQgYmVsb3cuPG86cD48L286cD48L3A+DQo8cD5U aGVyZSBhcmUgY2FzZXMgd2hlcmUgQSB0cnVzdHMgWiBhbmQgJm5ic3A7QiB0cnVzdHMgWiwgYnV0 IEEgYW5kIEIgZG8gbm90IGtub3cvdHJ1c3QgZWFjaCBvdGhlciBkaXJlY3RseSwgYW5kIFogaXMg Tm90IHRoZSBBUyAoYnV0IHRoZXJlIGlzIGEgdHJ1c3QgcmVsYXRpb25zaGlwIGJldHdlZW4gWiBh bmQgdGhlIEFTIOKAkyB0aGlzIGFsbG93cyBmb3IgbW9yZSB0aGFuIG9uZSBBUyBpbiB0aGUgdHJ1 c3QgZnJhbWV3b3JrKS4gSW4gb3JkZXIgZm9yIEEgYW5kDQogQiB0byBpbnRlcmFjdCwgdGhlIEFT IHdpbGwgYWN0IGFzIGEg4oCYbG9jYXRvcuKAmSBzZXJ2aWNlIGFuZCBzdWJqZWN0LXJlcHJlc2Vu dGF0aXZlLCBidXQgYW55IGFzc29jaWF0ZWQgYWNjZXNzIHRva2VucyB0aGUgQVMgZ2VuZXJhdGUg d2lsbCByZXF1aXJlIGFzc3VyYW5jZXMgZnJvbSBaIHRoYXQgdGhlIHBhcnRpY2lwYW50cyBpbiB0 aGUgdHJhbnNhY3Rpb24gYXJlIGxlZ2l0aW1hdGUgZW50aXRpZXMgaW4gdGhlIHRyYW5zYWN0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPHA+SGVyZSBpcyBhIGZvciBleGFtcGxlOiBBIGlzIGEgcmVudGFs IGNhciBjb21wYW55LCBCIGlzIGEgRE1WLiBUaGUgQVMgaXMgYSBwZXJzb25hbCBkaWdpdGFsIGlk ZW50aXR5IG1hbmFnZW1lbnQgc2VydmljZSAoKmNvdWdoKiB3YWxsZXQgKjxiPmNvdWdoPC9iPiop IHRoYXQgaW50ZXJhY3RzIHdpdGggdGhlIGxpY2Vuc2UgaG9sZGVyL1JlbnRlci4gQSwgQiwgYW5k IEFTIGhhdmUgYSB0cnVzdCByZWxhdGlvbnNoaXAgYW5kIGRlZmluZWQgcm9sZQ0KIGluIGFuIG9y Z2FuaXphdGlvbiBaLiBXaGVuIHRoZSBSZW50ZXIgd2lzaGVzIHRvIHByb3ZpZGUgaGlzIGVsaWdp YmlsaXR5IHRvIGRyaXZlIHRvIEEsIHRoZSBBUyBtdXN0IHByb3ZpZGU6PG86cD48L286cD48L3A+ DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+RXZpZGVuY2UgdG8gQSBmcm9tIFogdGhhdCBCIGlzIGEgcXVhbGlmaWVkIERNViAocGVy bWl0dGVkIHRvIHByb3ZpZGUgdGhlIHJlcXVpcmVkIGluZm8pLjxvOnA+PC9vOnA+PC9saT48bGkg c3R5bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8xIj5FdmlkZW5jZSB0byBCIGZyb20gWiB0aGF0 IEEgaXMgYSBxdWFsaWZpZWQgUmVudGFsIENhciBDb21wYW55IChwZXJtaXR0ZWQgdG8gY29sbGVj dCB0aGUgcmVxdWlyZWQgaW50bykuPG86cD48L286cD48L2xpPjxsaSBzdHlsZT0ibXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPkV2aWRlbmNlIHRvIGJvdGggQSBhbmQgQiBmcm9tIFogdGhhdCB0aGUg QVMgaXMgYSB0cnVzdGVkIHN1YmplY3QgcmVwcmVzZW50YXRpdmUuPG86cD48L286cD48L2xpPjxs aSBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkEgcm91dGUgZm9yIEEgYW5kIEIgdG8g Y29tbXVuaWNhdGUgd2l0aCBlYWNoIG90aGVyIHdpdGggYWxsIHRoZXNlIGFjY2VzcyBwZXJtaXNz aW9ucy48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwPk5vdGUgaW4gdGhpcyBtb2RlbCB0aGUgQVMg Y2FuIGFsc28gYmUgYSB0cnVzdGVkIHBhcnRpY2lwYW50IGluIGFub3RoZXIgWiYjNDM7MSB0cnVz dCBmcmFtZXdvcmsuPG86cD48L286cD48L3A+DQo8cD5JIHNlZSBHTkFQIGFzIGFuIG9wcG9ydHVu aXR5IHRvIHN1cHBvcnQgdGhlIGFib3ZlIG1vZGVsIHdpdGggZmxleGlibGUgdXNlciBhZ2VudHMs IEFTLCBkaXNjb3ZlcnksIHRva2VuIHN0cnVjdHVyZXMgYW5kIGNyeXB0by48bzpwPjwvbzpwPjwv cD4NCjxwPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwPk1WPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBpZD0iYm9keSIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDsgY29sb3I6ZGFy a2dyYXk7IGxpbmUtaGVpZ2h0OjEwcHQ7IGZvbnQtZmFtaWx5OiAnQXJpYWwnLCd0aW1lcyByb21h bicsc2VyaWY7Ij4NClRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgZm9yIHRoZSBz b2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50cyBhbmQgbWF5IGJlIHByaXZpbGVnZWQs IGNvbmZpZGVudGlhbCBvciBvdGhlcndpc2UgZXhlbXB0IGZyb20gZGlzY2xvc3VyZSB1bmRlciBs YXcuIEFueSBkaXN0cmlidXRpb24sIHByaW50aW5nIG9yIG90aGVyIHVzZSBieSBhbnlvbmUgb3Ro ZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuDQogSWYgeW91IGFy ZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGlt bWVkaWF0ZWx5LCBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoaXMgZW1haWwgYW5kIGl0cyBhdHRh Y2htZW50cy48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9668FD63A2E34DC1BF13558B87C05E86securekeycom_-- From nobody Mon Jun 29 09:35:42 2020 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 BEA673A07BC for ; Mon, 29 Jun 2020 09:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 vcDJ0aoaCF6L for ; Mon, 29 Jun 2020 09:35:38 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DB63A07BA for ; Mon, 29 Jun 2020 09:35:38 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id k6so11022077oij.11 for ; Mon, 29 Jun 2020 09:35:38 -0700 (PDT) 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=zWMTWqOMxzQSG4exn5Awx7LdQ1p3YwFNnTXf5gTptnY=; b=jskTrHBgOCbF7nJtD/MM2xIpRTsXtcgmefLLA4lx91Tu02LzMU4tFQDs/oNukfwg3b F2KuNkL5SSHk0d2rGccJK6MjGb3pg9OBBM+AITrMjgH7XxWq7c3wIIoU80txtnAPpyPj QvKXPWmFtRDZNP7Z96onwOWHFctpX9W0S258xeF05xwLuW3UkHccfOmiMA+Dhcn7PUCc gcDhR5yq9S9VJDuslgc42o0wOshdwEn/5hQpR6k7R0mrpmp9aw8Y666uGWftdAw7lfAX w4gG2uCMuNtoNYRkwSD5pHKvJRFmulWjv9cBUHRSYozAcuegwuxubjLclP9jx/NZ8wVx h/1Q== 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=zWMTWqOMxzQSG4exn5Awx7LdQ1p3YwFNnTXf5gTptnY=; b=nfUQptdkXzS0jFzupsbVG7bHiYEjZDFBuMENifKSrg2DKkpsJgu7P+gzy1HqKNsE/q 6nnLLwGLlU3WchfPILL0aWI3Rucv1ugIiNY6ZvPPnI7T/pbTjKQ/lUjmiWZiweNzBcMc y6NYMkDi4KfjBDHUdQtwM1vkbSI3RRhZ5UgKXcWYROLhUUuXO+Mt1XBFFZywJdHzDQKB bzU38FtrxTEJcCNa8dq8lU3+oaL6Pq3ge7h0XUW5P032tXffLg2fpmFPjwLyESqdRQL1 KQh13TZ/V81PtBp6gp19JorhilyjS4wh04jnMgnXNKBmpuzIFpNR0voXkkEo1aVMNt9E TcFA== X-Gm-Message-State: AOAM533vO8eEgao6s18nySUli5bCD8hiEWh0ymzP0/qiB+QOIA15apyU r8+LIc7PDZ+tL4hcGsSjWAjy4LDtugifIcblPRA= X-Google-Smtp-Source: ABdhPJxT7TaUkEYCjuSlk3RsdZ8N0yvsc+D4mrJtP6KJZH50rvMDvI6wyByMw5WYF7EhjChVaQBmlhanOaK8GxmjJ7I= X-Received: by 2002:aca:3685:: with SMTP id d127mr8507758oia.172.1593448537464; Mon, 29 Jun 2020 09:35:37 -0700 (PDT) MIME-Version: 1.0 References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <353AF4E4-4939-4994-960E-54B0AADC6253@mit.edu> <624d15e8-48c0-4ef6-9429-d8fb79407d81@free.fr> <9668FD63-A2E3-4DC1-BF13-558B87C05E86@securekey.com> In-Reply-To: <9668FD63-A2E3-4DC1-BF13-558B87C05E86@securekey.com> From: Tom Jones Date: Mon, 29 Jun 2020 09:35:26 -0700 Message-ID: To: Mike Varley Cc: Denis , Justin Richer , "txauth@ietf.org" , Dick Hardt Content-Type: multipart/alternative; boundary="0000000000000b23c105a93ba6a6" Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 29 Jun 2020 16:35:41 -0000 --0000000000000b23c105a93ba6a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We have addressed that problem w/i Kantara and have a proposed solution. See link below. But there is a caveat. You MUST stop using the term trust - it has no agreed meaning. So you must define what attribute needs attestation. In our case we identified three things that the second party needs to know. we also stop trying to define the difference between the client and the rs. At least in our case two parties could switch roles w/i milliseconds. We defined these attributes to be shared between parties of the many that could be spec'd. 1. identify proofing 2. authentication proofing 3. proof of presence each had to be a signed assertion that was included in the az token. perhaps this model could work for this wg? https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token Peace ..tom On Mon, Jun 29, 2020 at 9:02 AM Mike Varley wrote: > Hello Denis, all, I just wanted to jump in on this point below: > > > > *From: *Txauth on behalf of Denis < > denis.ietf@free.fr> > *Date: *Monday, June 29, 2020 at 3:14 AM > > Any trust relationship may be described using the following construction: > entity A trusts entity B for some action C. > If you have in mind additional trust relationships, would you be able to > express them using this construction ? > Maybe you also have in mind some relationships that do not imply a form o= f > trust ? > > > > There is a proxy/broker model which sort of is described by the above, bu= t > I=E2=80=99d like to call out below. > > There are cases where A trusts Z and B trusts Z, but A and B do not > know/trust each other directly, and Z is Not the AS (but there is a trust > relationship between Z and the AS =E2=80=93 this allows for more than one= AS in the > trust framework). In order for A and B to interact, the AS will act as a > =E2=80=98locator=E2=80=99 service and subject-representative, but any ass= ociated access > tokens the AS generate will require assurances from Z that the participan= ts > in the transaction are legitimate entities in the transaction. > > Here is a for example: A is a rental car company, B is a DMV. The AS is a > personal digital identity management service (*cough* wallet **cough**) > that interacts with the license holder/Renter. A, B, and AS have a trust > relationship and defined role in an organization Z. When the Renter wishe= s > to provide his eligibility to drive to A, the AS must provide: > > 1. Evidence to A from Z that B is a qualified DMV (permitted to > provide the required info). > 2. Evidence to B from Z that A is a qualified Rental Car Company > (permitted to collect the required into). > 3. Evidence to both A and B from Z that the AS is a trusted subject > representative. > 4. A route for A and B to communicate with each other with all these > access permissions. > > Note in this model the AS can also be a trusted participant in another Z+= 1 > trust framework. > > I see GNAP as an opportunity to support the above model with flexible use= r > agents, AS, discovery, token structures and crypto. > > Thanks, > > MV > > This email and any attachments are for the sole use of the intended > recipients and may be privileged, confidential or otherwise exempt from > disclosure under law. Any distribution, printing or other use by anyone > other than the intended recipient is prohibited. If you are not an intend= ed > recipient, please contact the sender immediately, and permanently delete > this email and its attachments. > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000000b23c105a93ba6a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We have addressed=C2=A0that problem=C2=A0w/i Kantara and h= ave a proposed solution. See link below.
But there is a caveat.
You MUST stop using the term trust - it has no agreed meaning.
So you must define what attribute needs attestation.
In our case= we identified three things=C2=A0that the second party needs to know.
=
we also stop trying to define the difference between the client and th= e rs. At least in our case two parties could switch roles w/i milliseconds.=
We defined these attributes to be shared between parties of the = many that could be spec'd.
1. identify proofing
2. = authentication proofing
3. proof of presence
each had t= o be a signed assertion=C2=A0that was included=C2=A0in the az token.
<= div>perhaps this model could work for this wg?

<= div class=3D"gmail_quote">
On Mon, Jun= 29, 2020 at 9:02 AM Mike Varley <mike.varley@securekey.com> wrote:

Hello Denis, all, I just wanted to jump in on this p= oint below:

=C2=A0

From: = Txauth <txauth-bounces@ietf.org<= /a>> on behalf of Denis <denis.ietf@free.fr>
Date: Monday, June 29, 2020 at 3:14 AM

Any trust relationship may be described using= the following construction:=C2=A0 entity A trusts entity B for some action= C.
If you have in mind additional trust relationships, would you be able to ex= press them using this construction ?
Maybe you also have in mind some relationships that do not imply a form of = trust ?

=C2=A0

There is a proxy/broker model which sort of is described by the above, b= ut I=E2=80=99d like to call out below.

There are cases where A trusts Z and =C2=A0B trusts Z, but A and B do no= t know/trust each other directly, and Z is Not the AS (but there is a trust= relationship between Z and the AS =E2=80=93 this allows for more than one = AS in the trust framework). In order for A and B to interact, the AS will act as a =E2=80=98locator=E2=80=99 service and = subject-representative, but any associated access tokens the AS generate wi= ll require assurances from Z that the participants in the transaction are l= egitimate entities in the transaction.

Here is a for example: A is a rental car company, B is a DMV. The AS is = a personal digital identity management service (*cough* wallet *cough*) that interacts with the license holder/Renter. A, B, and AS have a trus= t relationship and defined role in an organization Z. When the Renter wishes to provide his eligibility to= drive to A, the AS must provide:

  1. Evidence to A from Z that B is a qualified DMV (permitted to provide th= e required info).
  2. Evidence to B from Z that A is a qu= alified Rental Car Company (permitted to collect the required into).=
  3. Evidence to both A and B from Z that the AS is a trusted su= bject representative.
  4. A route for A and B to communic= ate with each other with all these access permissions.

    5. Note in this model the AS can also be a trusted participant in another Z= +1 trust framework.

    I see GNAP as an opportunity to support the above model with flexible us= er agents, AS, discovery, token structures and crypto.

    Thanks,

    MV

This email and any attachments are for the sole use of the intended recipie= nts and may be privileged, confidential or otherwise exempt from disclosure= under law. Any distribution, printing or other use by anyone other than th= e intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediatel= y, and permanently delete this email and its attachments.

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000000b23c105a93ba6a6-- From nobody Mon Jun 29 10:20:27 2020 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 56D3B3A0841 for ; Mon, 29 Jun 2020 10:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.619 X-Spam-Level: X-Spam-Status: No, score=-0.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 nuC2JZiOgQPW for ; Mon, 29 Jun 2020 10:20:10 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp12.smtpout.orange.fr [80.12.242.134]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14EEC3A0886 for ; Mon, 29 Jun 2020 10:20:05 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d35 with ME id x5L3220054FMSmm035L3AE; Mon, 29 Jun 2020 19:20:04 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 29 Jun 2020 19:20:04 +0200 X-ME-IP: 86.238.65.197 To: Justin Richer Cc: txauth@ietf.org, Dick Hardt References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <353AF4E4-4939-4994-960E-54B0AADC6253@mit.edu> <624d15e8-48c0-4ef6-9429-d8fb79407d81@free.fr> From: Denis Message-ID: <2a350e4e-2871-a237-d711-0324617ca1ee@free.fr> Date: Mon, 29 Jun 2020 19:20:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8D0F3DE620F049C4E616DBDE" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 29 Jun 2020 17:20:23 -0000 This is a multi-part message in MIME format. --------------8D0F3DE620F049C4E616DBDE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Justin, A good news: we are progressing. The most important sentences from the text below are the following: [Denis]  Would this mean that we strongly agree together that the model should not assume a closely-tied connection between an RS and any single AS ? [Justin] Correct, *we shouldn’t assume it, but we should also not preclude it*. I think a lot of the internet is going keep with that model for some time to come, even if it’s not universal. When we don't assume a closely-tied connection between a RS and any single AS, it is possible to respect the user's privacy. When we assume a closely-tied connection between a RS and a *single AS*, it is not possible to respect the user's privacy as soon as a scope/RS pair is being used. In OAuth 2.0, the scope/RS pair is being managed using "out of bands" means. If we maintain the use of the scope/RS pair, we should define some automated way(s) to manage it. Let me illustrate it using two extreme examples: 1) First example: the RS *publicly* publishes a table with a list of operations and for each operation, a scope name and the attributes that relate to that scope. The client connects to the RS and get this table. Knowing the operation it wants to perform, it inspects whether the associated attributes are adequate and then selects the associated scope. Then the client requests an access token using a scope/RS pair. In such a case, the AS may know which kind operation(s) will be performed by the user on that RS. 2) Second example: the client connects to the RS and indicates which kind of operation it wants to perform. The RS replies to the client by communicating the row in the table which corresponds to that operation and which includes a scope name and the attributes that relate to that scope. The user inspects whether the associated attributes are adequate and then selects the associated scope. Then the client requests an access token using a scope/RS pair. Unless the AS has maliciously used or created an account on that RS, the AS will not know which kind operation will be performed by the user on that RS. The difference between these two cases is the following: in the case (1), the table is made publicly available while in case (2) a row of the table is only made available to authenticated clients at the time of the operation. Nevertheless, the use of a scope/RS pair will never fully protect the users' privacy. Denis > Hi Denis, > >> On Jun 29, 2020, at 3:13 AM, Denis > > wrote: >> >> Justin, >> >>> Removing the IESG as this is really a more internal-to-the-group >>> discussion, as it comes down to the scope of use cases that we want >>> to address here in GNAP. >>> >>> While it is definitely important to understand how and why OAuth 2 >>> does things, we do need to keep use cases like Denis’s in mind. >> Thanks. >>> It’s not unheard of today for a single OAuth 2 RS to accept tokens >>> from multiple AS’s. >> >> We are preparing the future. A simple case is to prove "who you are" >> and since banks "need to know their customers" >> they would be well placed to provide an access token containing some >> verified personal attributes. >> >> For example, a student would like to change university and would need >> to present his prior graduations. >> In such a case, each university or school would be well placed to >> produce such a proof by issuing an access token. >> > This is a great example — each university is definitely in place to > produce the attributes bound to the user, and therefore to host the > “graduation proof” API. But the question is, who will produce the > access tokens that can be used for each copy of that API? > > In the OAuth 2 trust model, each university would have its own AS > protecting its own API. That model still makes sense for a lot of > things, and maybe even this case as well. But each university could > also accept, say, access tokens from other universities within a > consortium, or from a trusted third-party agency, or even an arbitrary > AS as long as the access token can prove it’s bound to a user > credential the university can trust as being that former student. > There are a lot of possibilities, and the details of most of these > other scenarios are going to rely on additional pieces that will be > defined outside of GNAP. > >>> In fact, we’ve even got cases with things like the Solid project >>> where the RS will take a token from :any: AS so long as it can >>> verify that it’s approved by the resource owner. While the Solid >>> platform has its own special layering in place to allow this, our >>> model should not assume a closely-tied connection between an RS and >>> any single AS. The question of :how: we solve that is, of course, up >>> to the WG to figure out over time. >> >> Would this mean that we strongly agree together that the model should >> not assume a closely-tied connection between an RS and any single AS ? >> > Correct, we shouldn’t assume it, but we should also not preclude it. I > think a lot of the internet is going keep with that model for some > time to come, even if it’s not universal. > >>> Taking that even further, I think the idea of an AS that’s personal >>> to the user, to promote privacy and control, is a very good one. >> >> In a previous message, I indicated that I have been able to >> understand what you mean by: an "AS that’s personal to the user" ? >> > This means that a user has their own AS that’s under their personal > control. Maybe it’s something they host on the web somewhere, or maybe > it’s an app on their personal device, or any number of things. As > below, this is the idealized UMA model below, where the user gets to > decide which AS to use to protect their data API. >> >>> In fact, this is one of the main selling points of UMA2 and its >>> federated authorization mechanisms. With GNAP, we might be able to >>> deliver >>> on this promise even more than UMA has been able to, and it’s my >>> hope that we can have a cohesive protocol that allows both user-to-self >>> and user-to-another delegation sharing without needing to use >>> different mechanisms. >>> >>> Additionally, the RS-first method is also something from the UMA2 >>> work that we should be working on, as it touches on AS discovery, >>> AS/RS communication, and a few other aspects of the protocol design. >>> It’s not a trivial problem by any stretch, and there are huge >>> privacy and security implications, but there’s both need for it and >>> some good prior art to pull from. In fact, XYZ’s whole notion of a >>> “transaction handle” is an adaptation of UMA2’s “permission ticket”. >>> In UMA, this ticket is first issued to the RS by the AS, and the RS >>> then hands it to the client, which starts the negotiation for >>> access. I envision something very similar happening here with GNAP, >>> where a client can get something to bootstrap the process at the AS. >>> The important thing, to me, is that we don’t have to jump through a >>> bunch of weird hoops such that the AS-first and RS-first cases look >>> completely different, as they do in UMA2 and OAuth 2 respectively >>> today. We’ve got the chance to have a clean and cohesive protocol >>> here, let’s not miss that opportunity. >>> >>> So in sum, the trust model of OAuth 2 is not sufficient to cover >>> everything, and the model that Denis is proposing is something we >>> should at least look at as a use case. >>> Where Denis and I seem to disagree is whether this trust model >>> should be the :only: one that we address with the protocol. >> >> Any trust relationship may be described using the following >> construction:  entity A trusts entity B for some action C. >> If you have in mind additional trust relationships, would you be able >> to express them using this construction ? >> Maybe you also have in mind some relationships that do not imply a >> form of trust ? >> > The difference isn’t on what “trust” means, the difference is on which > parties are A, B, and C in your equation above, and more importantly, > *why* they trust. There are scenarios where the RS would trust the > user because the RS knows the user, not because of which AS the user > is using. >> >>> I strongly believe, as I believe much of this group does, that we >>> can’t discount or ignore (or make things overly difficult for) >>> the tightly bound AS/RS combos, or any type of static setup where >>> the RS offloads its trust fully to the AS. >>> But it’s my belief that we should be able to do so without >>> needlessly throwing out all of the OAuth 2 use cases. >> >> Reading these sentences confuses me again since they seem to mean >> that the model should assume a closely-tied connection between RSs >> and ASs. >> >> In OAuth 2.0, the scope parameter allows the client to specify the >> desired scope of the requested security token in the context of the >> service or resource >> where the token will be used. The values and associated semantics of >> scope are service specific and and expected to be described in the >> relevant service >> documentation [RFC 8693]. Since the scope is RS dependent, the client >> MUST inform the AS about the identity of the RS, but this should be >> avoided for >> privacy reasons. >> > The scope doesn’t have to be RS dependent, you can have many RS’s > implementing the same API with the same scopes. There are of course > plenty of instances where the scope does identify the RS, but there’s > also been other work in the OAuth WG like the “resource” parameter > [RFC8707] to provide explicit direction as well. Honestly that aspect > of the request is a bit of a mess in OAuth right now, and it’s one of > the main things I think we need to clean up here in GNAP. > Incidentally, this is why I’m so against simply importing “scope” and > RAR directly into GNAP, we need to move past the intrinsic limitations > in those systems. >> >> Currently in OAuth 2.0, there is no protocol being defined to be able >> to know which attributes correspond to a given scope for a given RS. >> IMHO, the main idea is the following:  rather than using the scope >> parameter, the client should be able to inform directly the AS about >> which attributes it needs. In this way, the client would not need to >> inform the AS for which RS these attributes are needed. >> >> A major difference with OAuth 2.0 would be that attributes could be >> requested directly to an AS without using the pair scope/RS. >> Such an approach would make the architecture scalable. >> > > In GNAP, we will be defining ways to do fine-grained access control. > This will let the client specify what it wants across a wide range of > dimensions, and that’s a really powerful pattern. One of the > dimensions that the client :could: specify to the AS is which RS it > wants to talk to. In some deployments, this will let the AS draft a > token that is limited to just that single RS, perhaps by encrypting it > against the RS’s key or setting an audience-restriction field. So > using the syntax from XYX and RAR (which is a back-port of part of XYZ > to OAuth 2), you get something like this: > > { > resources: { > location: [“https://rs.example.com/resource”], > action: [“read”] > } > } > > But there are other cases, like what you’re talking about in this > thread, where you don’t want the AS to know which RS the client is > going to talk to. The client knows, and it just needs to get a token > that the RS will trust for the action it wants to take. Using the same > syntax, that would look something like this: > > { > resources: { > action: [“read”] > type: “proof_of_graduation” > } > } > > Which one of these do you use? That’s up to your API deployment. What > will your RS want or need to know in order to fulfill the request? > What will your AS need in order to create a token that will work for > the deployed system? That’s not something the protocol should dictate, > but it should allow that choice. The client needs to know what to ask > for, the AS needs to know what to expect and issue, and the RS needs > to know what to look for in (or about) the token. > > This is one of the places where I think we can really start to > innovate and bring these worlds together. There’s kind of an > artificial split right now and we can do better. OAuth 2 moved us past > the concept of the AS and RS being the same system (just called the > “server” in OAuth 1), and UMA pushed the conversation further into the > AS and RS being introduced to each other during the protocol flow. > GNAP can keep this going, and do so without giving up the ability for > the RS to be tightly bound to the AS, if the deployment desires or > requires it. I think we can do these advanced distributed trust models > without getting in the way of the classical AS-as-the-hub trust model > form OAuth 2, and both become options that (importantly) work pretty > similarly within the GNAP protocol itself. > >  — Justin > >> Denis >> >>> >>> We shouldn’t let “OAuth 2 doesn’t do it that way” be the limiting >>> factor here. We need to understand the what and wherefore of things >>> that OAuth 2 is bad at, otherwise we’re just going to re-invent >>> OAuth 2 and inherit its problems. >>> >>>  — Justin >>> >>>> On Jun 26, 2020, at 1:39 PM, Dick Hardt >>> > wrote: >>>> >>>> Denis, thanks for sharing your thoughts, some clarifications on >>>> your statements inserted: >>>> >>>> On Fri, Jun 26, 2020 at 9:42 AM Denis >>> > wrote: >>>> >>>> >>>> *New proposed charter* >>>> >>>> >>>> >>>> >>>> Resource servers inform their clients about which access >>>> token formats are acceptable and depending upon the king of >>>> operation >>>> that is requested, which kind of attributes are needed and >>>> from which ASs that my be obtained. >>>> >>>> While at times this may be appropriate, at other times disclosing >>>> the attributes the RS requires is not needed by the client. For >>>> example, an enterprise client accessing a resource does not need to >>>> know which groups a user belongs to, but the RS may require that to >>>> determine if the user running the client has access.. >>>> >>>> >>>> A major difference with OAuth 2.0 is that there is no >>>> bilateral trust relationship between an authorization >>>> server and a resource server: >>>> for a given category of attributes, a resource server may >>>> trust one or more authorization servers. Another major >>>> difference with OAuth 2.0. >>>> is that the content of an attributes token is meant to be >>>> accessible to the client. >>>> >>>> This is not how OAuth 2.0 works. See slides 7 and 8 from my >>>> original IETF presentation on what became OAuth 2.0 >>>> >>>> https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation >>>> >>>> The AS may not even know who the RS (or PR in the slides) is. >>>> >>>> >>>> >>>> >>>> I got rid of the word "delegation": the client does not >>>> delegate anything to an authorization server. If it would, this >>>> would mean that the authorization server >>>> would be able to act as the client and could know everything >>>> that the client will do, which comes into contradiction with >>>> the user's privacy. >>>> >>>> >>>> The above is not true. >>>> The Resource Owner is delegating access control to the AS in >>>> authorization use cases. >>>> >>>> The client is may be delegating user authentication to the AS in >>>> identity claim use cases. >>>> >>>> The AS can act as the client in many OAuth deployments, as the >>>> access token is a bearer token. That does not mean the AS knows >>>> what the client is doing. >>>> >>>> /Dick >>>> ᐧ >>>> -- >>>> Txauth mailing list >>>> Txauth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/txauth >>> >> > --------------8D0F3DE620F049C4E616DBDE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Justin,

A good news: we are progressing. The most important sentences from the text below are the following:

[Denis]  Would this mean that we strongly agree together that the model should not assume a closely-tied connection between an RS and any single AS ?

[Justin] Correct, we shouldn’t assume it, but we should also not preclude it. I think a lot of the internet is going keep with that model for some time to come, even if it’s not universal.
When we don't assume a closely-tied connection between a RS and any single AS, it is possible to respect the user's privacy. 
When we assume a closely-tied connection between a RS and a single AS, it is not possible to respect the user's privacy as soon as a scope/RS pair is being used.

In OAuth 2.0, the scope/RS pair is being managed using "out of bands" means. If we maintain the use of the scope/RS pair, we should define some automated way(s)
to manage it. Let me illustrate it using two extreme examples:
1) First example: the RS publicly publishes a table with a list of operations and for each operation, a scope name and the attributes that relate to that scope.
The client connects to the RS and get this table. Knowing the operation it wants to perform, it inspects whether the associated attributes are adequate
and then selects the associated scope. Then the client requests an access token using a scope/RS pair. In such a case, the AS may know which kind operation(s)
will be performed by the user on that RS.

2) Second example: the client connects to the RS and indicates which kind of operation it wants to perform. The RS replies to the client by communicating
the row in the table which corresponds to that operation and which includes a scope name and the attributes that relate to that scope. The user inspects
whether the associated attributes are adequate and then selects the associated scope. Then the client requests an access token using a scope/RS pair.
Unless the AS has maliciously used or created an account on that RS, the AS will not know which kind operation will be performed by the user on that RS. 
The difference between these two cases is the following: in the case (1), the table is made publicly available while in case (2) a row of the table is only made available
to authenticated clients at the time of the operation. Nevertheless, the use of a scope/RS pair will never fully protect the users' privacy.

Denis

Hi Denis,

On Jun 29, 2020, at 3:13 AM, Denis <denis.ietf@free.fr> wrote:

Justin,

Removing the IESG as this is really a more internal-to-the-group discussion, as it comes down to the scope of use cases that we want to address here in GNAP.

While it is definitely important to understand how and why OAuth 2 does things, we do need to keep use cases like Denis’s in mind.
Thanks.
It’s not unheard of today for a single OAuth 2 RS to accept tokens from multiple AS’s.

We are preparing the future. A simple case is to prove "who you are" and since banks "need to know their customers"
they would be well placed to provide an access token containing some verified personal attributes. 

For example, a student would like to change university and would need to present his prior graduations.
In such a case, each university or school would be well placed to produce such a proof by issuing an access token.

This is a great example — each university is definitely in place to produce the attributes bound to the user, and therefore to host the “graduation proof” API. But the question is, who will produce the access tokens that can be used for each copy of that API?

In the OAuth 2 trust model, each university would have its own AS protecting its own API. That model still makes sense for a lot of things, and maybe even this case as well. But each university could also accept, say, access tokens from other universities within a consortium, or from a trusted third-party agency, or even an arbitrary AS as long as the access token can prove it’s bound to a user credential the university can trust as being that former student. There are a lot of possibilities, and the details of most of these other scenarios are going to rely on additional pieces that will be defined outside of GNAP.

In fact, we’ve even got cases with things like the Solid project where the RS will take a token from :any: AS so long as it can verify that it’s approved by the resource owner. While the Solid platform has its own special layering in place to allow this, our model should not assume a closely-tied connection between an RS and any single AS. The question of :how: we solve that is, of course, up to the WG to figure out over time.

Would this mean that we strongly agree together that the model should not assume a closely-tied connection between an RS and any single AS ?

Correct, we shouldn’t assume it, but we should also not preclude it. I think a lot of the internet is going keep with that model for some time to come, even if it’s not universal.

Taking that even further, I think the idea of an AS that’s personal to the user, to promote privacy and control, is a very good one.

In a previous message, I indicated that I have been able to understand what you mean by: an "AS that’s personal to the user" ?

This means that a user has their own AS that’s under their personal control. Maybe it’s something they host on the web somewhere, or maybe it’s an app on their personal device, or any number of things. As below, this is the idealized UMA model below, where the user gets to decide which AS to use to protect their data API.

In fact, this is one of the main selling points of UMA2 and its federated authorization mechanisms. With GNAP, we might be able to deliver
on this promise even more than UMA has been able to, and it’s my hope that we can have a cohesive protocol that allows both user-to-self
and user-to-another delegation sharing without needing to use different mechanisms. 

Additionally, the RS-first method is also something from the UMA2 work that we should be working on, as it touches on AS discovery, AS/RS communication, and a few other aspects of the protocol design. It’s not a trivial problem by any stretch, and there are huge privacy and security implications, but there’s both need for it and some good prior art to pull from. In fact, XYZ’s whole notion of a “transaction handle” is an adaptation of UMA2’s “permission ticket”. In UMA, this ticket is first issued to the RS by the AS, and the RS then hands it to the client, which starts the negotiation for access. I envision something very similar happening here with GNAP, where a client can get something to bootstrap the process at the AS. The important thing, to me, is that we don’t have to jump through a bunch of weird hoops such that the AS-first and RS-first cases look completely different, as they do in UMA2 and OAuth 2 respectively today. We’ve got the chance to have a clean and cohesive protocol here, let’s not miss that opportunity.

So in sum, the trust model of OAuth 2 is not sufficient to cover everything, and the model that Denis is proposing is something we should at least look at as a use case.
Where Denis and I seem to disagree is whether this trust model should be the :only: one that we address with the protocol.

Any trust relationship may be described using the following construction:  entity A trusts entity B for some action C.
If you have in mind additional trust relationships, would you be able to express them using this construction ?
Maybe you also have in mind some relationships that do not imply a form of trust ?

The difference isn’t on what “trust” means, the difference is on which parties are A, B, and C in your equation above, and more importantly, *why* they trust. There are scenarios where the RS would trust the user because the RS knows the user, not because of which AS the user is using. 

I strongly believe, as I believe much of this group does, that we can’t discount or ignore (or make things overly difficult for)
the tightly bound AS/RS combos, or any type of static setup where the RS offloads its trust fully to the AS.
But it’s my belief that we should be able to do so without needlessly throwing out all of the OAuth 2 use cases.

Reading these sentences confuses me again since they seem to mean that the model should assume a closely-tied connection between RSs and ASs.

In OAuth 2.0, the scope parameter allows the client to specify the desired scope of the requested security token in the context of the service or resource
where the token will be used. The values and associated semantics of scope are service specific and and expected to be described in the relevant service
documentation [RFC 8693]. Since the scope is RS dependent, the client MUST inform the AS about the identity of the RS, but this should be avoided for
privacy reasons.

The scope doesn’t have to be RS dependent, you can have many RS’s implementing the same API with the same scopes. There are of course plenty of instances where the scope does identify the RS, but there’s also been other work in the OAuth WG like the “resource” parameter [RFC8707] to provide explicit direction as well. Honestly that aspect of the request is a bit of a mess in OAuth right now, and it’s one of the main things I think we need to clean up here in GNAP. Incidentally, this is why I’m so against simply importing “scope” and RAR directly into GNAP, we need to move past the intrinsic limitations in those systems.

Currently in OAuth 2.0, there is no protocol being defined to be able to know which attributes correspond to a given scope for a given RS. 
IMHO, the main idea is the following:  rather than using the scope parameter, the client should be able to inform directly the AS about
which attributes it needs. In this way, the client would not need to inform the AS for which RS these attributes are needed.

A major difference with OAuth 2.0 would be that attributes could be requested directly to an AS without using the pair scope/RS.
Such an approach would make the architecture scalable.


In GNAP, we will be defining ways to do fine-grained access control. This will let the client specify what it wants across a wide range of dimensions, and that’s a really powerful pattern. One of the dimensions that the client :could: specify to the AS is which RS it wants to talk to. In some deployments, this will let the AS draft a token that is limited to just that single RS, perhaps by encrypting it against the RS’s key or setting an audience-restriction field. So using the syntax from XYX and RAR (which is a back-port of part of XYZ to OAuth 2), you get something like this:

{
resources: {
action: [“read”]
}
}

But there are other cases, like what you’re talking about in this thread, where you don’t want the AS to know which RS the client is going to talk to. The client knows, and it just needs to get a token that the RS will trust for the action it wants to take. Using the same syntax, that would look something like this:

{
resources: {
action: [“read”]
type: “proof_of_graduation”
}
}

Which one of these do you use? That’s up to your API deployment. What will your RS want or need to know in order to fulfill the request? What will your AS need in order to create a token that will work for the deployed system? That’s not something the protocol should dictate, but it should allow that choice. The client needs to know what to ask for, the AS needs to know what to expect and issue, and the RS needs to know what to look for in (or about) the token.

This is one of the places where I think we can really start to innovate and bring these worlds together. There’s kind of an artificial split right now and we can do better. OAuth 2 moved us past the concept of the AS and RS being the same system (just called the “server” in OAuth 1), and UMA pushed the conversation further into the AS and RS being introduced to each other during the protocol flow. GNAP can keep this going, and do so without giving up the ability for the RS to be tightly bound to the AS, if the deployment desires or requires it. I think we can do these advanced distributed trust models without getting in the way of the classical AS-as-the-hub trust model form OAuth 2, and both become options that (importantly) work pretty similarly within the GNAP protocol itself.

 — Justin

Denis


We shouldn’t let “OAuth 2 doesn’t do it that way” be the limiting factor here. We need to understand the what and wherefore of things that OAuth 2 is bad at, otherwise we’re just going to re-invent OAuth 2 and inherit its problems.

 — Justin

On Jun 26, 2020, at 1:39 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Denis, thanks for sharing your thoughts, some clarifications on your statements inserted:

On Fri, Jun 26, 2020 at 9:42 AM Denis <denis.ietf@free.fr> wrote:
<snip>

New proposed charter

<snip> 

Resource servers inform their clients about which access token formats are acceptable and depending upon the king of operation
that is requested, which kind of attributes are needed and from which ASs that my be obtained.

While at times this may be appropriate, at other times disclosing the attributes the RS requires is not needed by the client. For example, an enterprise client accessing a resource does not need to know which groups a user belongs to, but the RS may require that to determine if the user running the client has access..

A major difference with OAuth 2.0 is that there is no bilateral trust relationship between an authorization server and a resource server:
for a given category of attributes, a resource server may trust one or more authorization servers. Another major difference with OAuth 2.0.
is that the content of an attributes token is meant to be accessible to the client.
This is not how OAuth 2.0 works. See slides 7 and 8 from my original IETF presentation on what became OAuth 2.0


The AS may not even know who the RS (or PR in the slides) is.

<snip> 


I got rid of the word "delegation": the client does not delegate anything to an authorization server. If it would, this would mean that the authorization server
would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy.


The above is not true.
 
The Resource Owner is delegating access control to the AS in authorization use cases.

The client is may be delegating user authentication to the AS in identity claim use cases.

The AS can act as the client in many OAuth deployments, as the access token is a bearer token. That does not mean the AS knows what the client is doing. 

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




--------------8D0F3DE620F049C4E616DBDE-- From nobody Mon Jun 29 10:23:59 2020 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 A1C7A3A082D for ; Mon, 29 Jun 2020 10:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 14IQltoQpA3g for ; Mon, 29 Jun 2020 10:23:55 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp12.smtpout.orange.fr [80.12.242.134]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9F63A082C for ; Mon, 29 Jun 2020 10:23:54 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d35 with ME id x5Ps2200A4FMSmm035PsYH; Mon, 29 Jun 2020 19:23:52 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Mon, 29 Jun 2020 19:23:52 +0200 X-ME-IP: 86.238.65.197 To: Mike Varley Cc: Justin Richer , "txauth@ietf.org" , Dick Hardt References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <353AF4E4-4939-4994-960E-54B0AADC6253@mit.edu> <624d15e8-48c0-4ef6-9429-d8fb79407d81@free.fr> <9668FD63-A2E3-4DC1-BF13-558B87C05E86@securekey.com> From: Denis Message-ID: <56c2904e-6df1-4f3a-ce70-b87132abefe6@free.fr> Date: Mon, 29 Jun 2020 19:23:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <9668FD63-A2E3-4DC1-BF13-558B87C05E86@securekey.com> Content-Type: multipart/alternative; boundary="------------A50A291BB2F679A392F37371" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 29 Jun 2020 17:23:57 -0000 This is a multi-part message in MIME format. --------------A50A291BB2F679A392F37371 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Mike, The following sentence does not describe correctly a trust relationship: "There are cases where A trusts Z and  B trusts Z, ..." since it does not follow the construction indicated in the previous email:  entity A trusts entity B *for some action C*. The following sentence sounds strange to me: "the AS is a personal digital identity management service". A "personal digital identity management service" is fine but I see no reason why it can also be an AS since it does not issue/generate directly access tokens. Denis > Hello Denis, all, I just wanted to jump in on this point below: > > *From: *Txauth on behalf of Denis > > *Date: *Monday, June 29, 2020 at 3:14 AM > > Any trust relationship may be described using the following > construction:  entity A trusts entity B for some action C. > If you have in mind additional trust relationships, would you be able > to express them using this construction ? > Maybe you also have in mind some relationships that do not imply a > form of trust ? > > There is a proxy/broker model which sort of is described by the above, > but I’d like to call out below. > > There are cases where A trusts Z and  B trusts Z, but A and B do not > know/trust each other directly, and Z is Not the AS (but there is a > trust relationship between Z and the AS – this allows for more than > one AS in the trust framework). In order for A and B to interact, the > AS will act as a ‘locator’ service and subject-representative, but any > associated access tokens the AS generate will require assurances from > Z that the participants in the transaction are legitimate entities in > the transaction. > > Here is a for example: A is a rental car company, B is a DMV. The AS > is a personal digital identity management service (*cough* wallet > **cough**) that interacts with the license holder/Renter. A, B, and AS > have a trust relationship and defined role in an organization Z. When > the Renter wishes to provide his eligibility to drive to A, the AS > must provide: > > 1. Evidence to A from Z that B is a qualified DMV (permitted to > provide the required info). > 2. Evidence to B from Z that A is a qualified Rental Car Company > (permitted to collect the required into). > 3. Evidence to both A and B from Z that the AS is a trusted subject > representative. > 4. A route for A and B to communicate with each other with all these > access permissions. > > Note in this model the AS can also be a trusted participant in another > Z+1 trust framework. > > I see GNAP as an opportunity to support the above model with flexible > user agents, AS, discovery, token structures and crypto. > > Thanks, > > MV > > This email and any attachments are for the sole use of the intended > recipients and may be privileged, confidential or otherwise exempt > from disclosure under law. Any distribution, printing or other use by > anyone other than the intended recipient is prohibited. If you are not > an intended recipient, please contact the sender immediately, and > permanently delete this email and its attachments. > --------------A50A291BB2F679A392F37371 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Mike,

The following sentence does not describe correctly a trust relationship: "There are cases where A trusts Z and  B trusts Z, ..."
since it does not follow the construction indicated in the previous email:  entity A trusts entity B for some action C.

The following sentence sounds strange to me: "the AS is a personal digital identity management service".

A "personal digital identity management service" is fine but I see no reason why it can also be an AS
since it does not issue/generate directly access tokens.

Denis

Hello Denis, all, I just wanted to jump in on this point below:

 

From: Txauth <txauth-bounces@ietf.org> on behalf of Denis <denis.ietf@free.fr>
Date: Monday, June 29, 2020 at 3:14 AM

Any trust relationship may be described using the following construction:  entity A trusts entity B for some action C.
If you have in mind additional trust relationships, would you be able to express them using this construction ?
Maybe you also have in mind some relationships that do not imply a form of trust ?

 

There is a proxy/broker model which sort of is described by the above, but I’d like to call out below.

There are cases where A trusts Z and  B trusts Z, but A and B do not know/trust each other directly, and Z is Not the AS (but there is a trust relationship between Z and the AS – this allows for more than one AS in the trust framework). In order for A and B to interact, the AS will act as a ‘locator’ service and subject-representative, but any associated access tokens the AS generate will require assurances from Z that the participants in the transaction are legitimate entities in the transaction.

Here is a for example: A is a rental car company, B is a DMV. The AS is a personal digital identity management service (*cough* wallet *cough*) that interacts with the license holder/Renter. A, B, and AS have a trust relationship and defined role in an organization Z. When the Renter wishes to provide his eligibility to drive to A, the AS must provide:

  1. Evidence to A from Z that B is a qualified DMV (permitted to provide the required info).
  2. Evidence to B from Z that A is a qualified Rental Car Company (permitted to collect the required into).
  3. Evidence to both A and B from Z that the AS is a trusted subject representative.
  4. A route for A and B to communicate with each other with all these access permissions.

Note in this model the AS can also be a trusted participant in another Z+1 trust framework.

I see GNAP as an opportunity to support the above model with flexible user agents, AS, discovery, token structures and crypto.

Thanks,

MV

This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited. If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.


--------------A50A291BB2F679A392F37371-- From nobody Tue Jun 30 12:27:03 2020 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 D1CEC3A07C2; Tue, 30 Jun 2020 12:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 U2qIhqX2QOzH; Tue, 30 Jun 2020 12:26:52 -0700 (PDT) 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 6A9A53A07AA; Tue, 30 Jun 2020 12:26:51 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05UJQhpG022637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 15:26:45 -0400 Date: Tue, 30 Jun 2020 12:26:43 -0700 From: Benjamin Kaduk To: Roman Danyliw Cc: The IESG , "gnap-chairs@ietf.org" , "txauth@ietf.org" Message-ID: <20200630192643.GS58278@kduck.mit.edu> References: <159305522436.11733.15198171728373227965@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT) 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, 30 Jun 2020 19:27:01 -0000 Hi Roman, Sorry to have let this slip well past the telechat... On Thu, Jun 25, 2020 at 01:36:36PM +0000, Roman Danyliw wrote: > Hi Ben! > > A few quick, but incomplete, responses/edits before the telechat. > > > -----Original Message----- > > From: Txauth On Behalf Of Benjamin Kaduk via > > Datatracker > > Sent: Wednesday, June 24, 2020 11:20 PM > > To: The IESG > > Cc: gnap-chairs@ietf.org; txauth@ietf.org > > Subject: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: > > (with COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > charter-ietf-gnap-00-01: No Objection > > > > When responding, please keep the subject line intact and reply to all email > > addresses included in the To and CC lines. (Feel free to cut this introductory > > paragraph, however.) > > > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-gnap/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > This group is chartered to develop a fine-grained delegation protocol > > for authorization and API access, as well as requesting and providing > > user identifiers and claims. > > > > nit: this appears to parse as "providing user claims", and I'm not sure what that > > means. > > TODO > > > The protocol will decouple the interaction channels, such as the end > > user’s browser [...] > > > > "interaction channels" might be a term of art that needs clarification? > > TODO > > > The client and Authorization Server (AS) will involve a user to make > > an authorization decision as necessary through interaction mechanisms > > indicated by the protocol. > > > > >From a privacy perspective, will all of the information to be made > > available from the AS to the RS be visible to the user as they make this > > authorization decision? > > TODO > > > The group will define interoperability for this protocol between different > > parties, including > > - client and authorization server; > > - client and resource server; and > > - authorization server and resource server. > > > > [obligatory note that just because we define an AS/RS channel doesn't mean it > > will be required to use one at runtime, given the potential for self-contained > > tokens?] > > Are you thinking that clarification would be explicitly stated? I don't think it needs to be, no. > > Additionally, the delegation process will allow for: > > [...] > > > > Do all of these need to be fully fleshed out in the main protocol spec, or could > > some of them be defered to future extensions? Some of them feel much more > > "core" than others, to me. > > Fair. IMO, the WG needs to have a discussion about how to appropriately decompose these capabilities, once there is an understood scope. I'm not sure we need to decide now what capabilities are in the "core" vs. follow-on extensions. Sure. "Allow for" could be read either way, I suppose... > > - Support for directed, audience-restricted access tokens > > > > I think we need to clarify what "directed" is intended to mean here (if it's not > > just a synonym for "audience-restricted" in which case it should just be > > removed). > > TODO > > > - A variety of client applications, including Web, mobile, > > single-page, and interaction-constrained applications > > > > side note: this one feels like it would be easier to phrase as "the WG will seek > > to minimize assumptions about the form of client applications, allowing for > > [...]" > > TODO > > > - Mechanisms for conveying user, software, organization, and other > > pieces of information used in authorization decisions > > > > nit: the "pieces of information" is in a weird place. What are "user pieces of > > information"? > > Editorially, the read should be "user [information], software [information], etc.". > > Removed "pieces of". > > > (Also, this is a somewhat interesting place to put an extension point, though I > > concede that there will eventually be need for some kind of extension here .. it > > just seems like we should try to make use of this extension point a rare event.) > > > > - Optimized inclusion of additional information through the > > delegation process (including identifiers and identity assertions) > > > > This seems pretty open-ended and prone to risky things. E.g., even just a setup > > with multiple identifiers quickly becomes complicated in terms of being able to > > make precise statements about what specifically is being proven, whether there > > is a guaranteed relationship between the two (or more) identities in question, > > etc.; and this point seems even more open-ended than just that. > > So the thinking is to scope down what that "additional information" might be? That would help some, yes. If we could phrase things such that there's only a single entity being describe that would be best, e.g., "information relating to the identity of the [client/whatever]" > > Additionally, the group will provide mechanisms for management of the > > protocol lifecycle including: > > [...] > > - Mechanisms for the AS and RS to communicate the access granted by an > > access token > > > > Maybe I'm just confused, but isn't "the access granted by an access token" > > exactly the set of authorizations conveyed by that token, i.e., the core point of > > the protocol? I'm not sure what kind "protocol lifecycle management" this > > item is intending to indicate. > > TODO > > > This group is not chartered to develop extensions to OAuth 2.0, and as > > such will focus on new technological solutions not necessarily > > compatible with OAuth 2.0. Functionality that builds directly on OAuth > > 2.0 will be developed in the OAuth Working Group, including > > functionality back-ported from the protocol developed here to OAuth 2.0. > > > > Perhaps s/developed in/directed to/ -- we don't need this WG's charter to make > > statements that are more appropriate in the OAuth WG's charter. > > Fixed. > > > The group is chartered to develop mechanisms for conveying identity > > information within the protocol including identifiers (such as email > > addresses, phone numbers, usernames, and subject identifiers) and > > assertions (such as OpenID Connect ID Tokens, SAML Assertions, and > > Verifiable Credentials). The group is not chartered to develop new > > formats for identifiers or assertions, nor is the group chartered to > > develop schemas for user information, profiles, or other identity > > attributes, unless a viable existing format is not available. > > > > This last bit is a decently sized loophole. If we leave it out that would force a > > recharter for picking up a new format, which might not be so bad. > > In the consensus building to produce this text, it seemed helpful to be clear on what's in and out. > > To be clear, is your concern that the text "... unless a viable existing format is not available" is the loophole? Right. > > The working group will cooperate and coordinate with other IETF WGs such > > as OAUTH, and work with organizations in the community, such as the > > OpenID, as appropriate. > > > > nit: "organizations in the community" is an unusual phrase; I think "external > > organizations" is probably more common. > > Fixed. (Was cut-and-pasted from the RATS charter) Thanks for the updates, Ben From nobody Tue Jun 30 12:36:18 2020 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 B3E3A3A076C; Tue, 30 Jun 2020 12:36:12 -0700 (PDT) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 yUsOy_3AD7oy; Tue, 30 Jun 2020 12:36:10 -0700 (PDT) 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 7FFA73A0769; Tue, 30 Jun 2020 12:36:10 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05UJa2wX026144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 15:36:04 -0400 Date: Tue, 30 Jun 2020 12:36:02 -0700 From: Benjamin Kaduk To: Justin Richer Cc: "rdd@cert.org" , The IESG , "gnap-chairs@ietf.org" , "txauth@ietf.org" Message-ID: <20200630193602.GT58278@kduck.mit.edu> References: <159305522436.11733.15198171728373227965@ietfa.amsl.com> <559FF73B-38D4-4D49-8827-0958613912C0@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <559FF73B-38D4-4D49-8827-0958613912C0@mit.edu> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT) 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, 30 Jun 2020 19:36:13 -0000 Hi Justin! On Thu, Jun 25, 2020 at 03:29:36PM -0400, Justin Richer wrote: > Hi Ben, > > Thanks for the thorough read through, as always. > > Some of my own thoughts the TODO items inline below. > > >> > >> This group is chartered to develop a fine-grained delegation protocol > >> for authorization and API access, as well as requesting and providing > >> user identifiers and claims. > >> > >> nit: this appears to parse as "providing user claims", and I'm not sure what that > >> means. > > > > TODO > > Yes, the is intended to parse as “providing user claims”. The idea here is that the client should be able to send claims that it has to the AS that will identify the user in a fashion that the AS can verify. In these cases, the AS can make a policy decision without directly involving the user for interaction. This is largely a gap in the OAuth 2 world, though the Resource Owner Password grant and the Assertions grant kind go in this direction, but there’s a desire in the community for a general mechanism for doing this. To be clear, GNAP is going to defer the details of these kinds of assertions to other specifications, like W3C’s Verifiable Credentials. Let me play this back to check that I've got it right: the idea is that the client might have some existing assertion or something that is evidence that the user has already consented to something, and the protocol is going to include a way for the client to convey this artifact to the AS so that the AS can validate it and skip bothering the user directly? I think we'd probably want some additional adjective here to clarify ("user-consent claims", "user verification claims", etc.) -- my original best-guess reading was that this was "user-supplied claims", e.g., "I'd like my token to include this arbitrary claim I just made up, please". (The latter's intermingling of user-supplied and trusted-source data is a recipe for security issues, of course.) > > > > >> The protocol will decouple the interaction channels, such as the end > >> user’s browser [...] > >> > >> "interaction channels" might be a term of art that needs clarification? > > > > TODO > > I don’t think it’s a specific term of art. I think we really meant “different ways to interact with the user”. One of OAuth 2’s limitations is that it, for the most part, assumes the user’s in a browser, and the core of the protocol is built around that. One of the goals of GNAP is to get away from that as a base assumption. Perhaps "decouple the channels by which the protocol participants communicate"? > > > >> The client and Authorization Server (AS) will involve a user to make > >> an authorization decision as necessary through interaction mechanisms > >> indicated by the protocol. > >> > >>> From a privacy perspective, will all of the information to be made > >> available from the AS to the RS be visible to the user as they make this > >> authorization decision? > > > > TODO > > Ultimately I don’t think we can fully specify the AS behavior here, but this is a good pillar for privacy considerations. > > > > >> The group will define interoperability for this protocol between different > >> parties, including > >> - client and authorization server; > >> - client and resource server; and > >> - authorization server and resource server. > >> > >> [obligatory note that just because we define an AS/RS channel doesn't mean it > >> will be required to use one at runtime, given the potential for self-contained > >> tokens?] > > > > Are you thinking that clarification would be explicitly stated? > > Note that a self-contained token is one of the communication channels that the group had in mind for AS/RS. We tried to write the requirements in such a way as to allow for self-contained messages, service-based stuff (like introspection), or even all-in-one-box solutions that don’t need “communication” apart from both reading the same database. This is an architectural pillar borrowed from OAuth 2. > > > > >> - Support for directed, audience-restricted access tokens > >> > >> I think we need to clarify what "directed" is intended to mean here (if it's not > >> just a synonym for "audience-restricted" in which case it should just be > >> removed). > > > > TODO > > This one is my fault — the concept we’re talking about here is one where the AS can effectively tell the client where and how it should use the token. There are a couple different WG participants who have expressed explicit interest in this, and I’ve started a thread on that topic recently: > > https://mailarchive.ietf.org/arch/msg/txauth/eP162P235OU0_JksY515FgmHFj0/ I think I read that one :) Would "AS-directed dispatch to the appropriate RS" (or similar) be a useful way to describe this? > > > >> - A variety of client applications, including Web, mobile, > >> single-page, and interaction-constrained applications > >> > >> side note: this one feels like it would be easier to phrase as "the WG will seek > >> to minimize assumptions about the form of client applications, allowing for > >> [...]" > > > > TODO > > That seems reasonable to me, and it goes hand-in-hand with the changes to interaction mentioned above. > > >> Additionally, the group will provide mechanisms for management of the > >> protocol lifecycle including: > >> [...] > >> - Mechanisms for the AS and RS to communicate the access granted by an > >> access token > >> > >> Maybe I'm just confused, but isn't "the access granted by an access token" > >> exactly the set of authorizations conveyed by that token, i.e., the core point of > >> the protocol? I'm not sure what kind "protocol lifecycle management" this > >> item is intending to indicate. > > > > TODO > > This ties into what’s above: the idea is to have a standard model for what an access token represents, and this says we’re going to standardize ways for the AS and RS to communicate that. This could be inside the token, through an introspection style service, or some other thing we haven’t figured out yet. But the thing is, all of these mechanisms should be communicating the same set of information. This is something the OAuth WG didn’t address, and so we ended up with some disparity in the handful of de-facto access token data models there. The goal was to avoid that. Ah, okay. So is the key point that these mechanisms/data-models are "consistent across the entire set of protocol flows"? Thanks, Ben From nobody Tue Jun 30 12:59:25 2020 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 1CBF63A07BA; Tue, 30 Jun 2020 12:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 Moq1Mfv3SPt2; Tue, 30 Jun 2020 12:59:21 -0700 (PDT) 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 062ED3A07B7; Tue, 30 Jun 2020 12:59:20 -0700 (PDT) Received: from [192.168.1.14] (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 05UJxH22002000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 15:59:17 -0400 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7FF89E6B-158E-492C-BBCE-94F08E72EB62" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 30 Jun 2020 15:59:17 -0400 In-Reply-To: <20200630193602.GT58278@kduck.mit.edu> Cc: "rdd@cert.org" , The IESG , "gnap-chairs@ietf.org" , "txauth@ietf.org" To: Benjamin Kaduk References: <159305522436.11733.15198171728373227965@ietfa.amsl.com> <559FF73B-38D4-4D49-8827-0958613912C0@mit.edu> <20200630193602.GT58278@kduck.mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT) 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, 30 Jun 2020 19:59:24 -0000 --Apple-Mail=_7FF89E6B-158E-492C-BBCE-94F08E72EB62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ben, > On Jun 30, 2020, at 3:36 PM, Benjamin Kaduk wrote: >=20 > Hi Justin! >=20 > On Thu, Jun 25, 2020 at 03:29:36PM -0400, Justin Richer wrote: >> Hi Ben, >>=20 >> Thanks for the thorough read through, as always. >>=20 >> Some of my own thoughts the TODO items inline below. >>=20 >>>>=20 >>>> This group is chartered to develop a fine-grained delegation = protocol >>>> for authorization and API access, as well as requesting and = providing >>>> user identifiers and claims. >>>>=20 >>>> nit: this appears to parse as "providing user claims", and I'm not = sure what that >>>> means. >>>=20 >>> TODO >>=20 >> Yes, the is intended to parse as =E2=80=9Cproviding user claims=E2=80=9D= . The idea here is that the client should be able to send claims that it = has to the AS that will identify the user in a fashion that the AS can = verify. In these cases, the AS can make a policy decision without = directly involving the user for interaction. This is largely a gap in = the OAuth 2 world, though the Resource Owner Password grant and the = Assertions grant kind go in this direction, but there=E2=80=99s a desire = in the community for a general mechanism for doing this. To be clear, = GNAP is going to defer the details of these kinds of assertions to other = specifications, like W3C=E2=80=99s Verifiable Credentials.=20 >=20 > Let me play this back to check that I've got it right: the idea is = that the > client might have some existing assertion or something that is = evidence > that the user has already consented to something, and the protocol is = going > to include a way for the client to convey this artifact to the AS so = that > the AS can validate it and skip bothering the user directly? I think = we'd > probably want some additional adjective here to clarify ("user-consent > claims", "user verification claims", etc.) -- my original best-guess > reading was that this was "user-supplied claims", e.g., "I'd like my = token > to include this arbitrary claim I just made up, please". (The = latter's > intermingling of user-supplied and trusted-source data is a recipe for > security issues, of course.) Ah, I see the confusion now; right, the idea is not about the user = putting claims into something that the AS echoes back to the client. We = want the AS to be able to send stuff back that it knows about the user, = but the client should be able to send it to the AS as well. For stuff = from the client, there are two categories of information people are = interested in: identifiers that aren=E2=80=99t proven yet (so it=E2=80=99s= just a hint to the AS about who the client :thinks: the user is, like a = username) and provable claim sets that the AS can verify independently = (and the protocol doesn=E2=80=99t care how that gets validated). Most = likely these latter ones will be formatted as assertions. I didn=E2=80=99t= want the charter language to limit the format, but I might be = overthinking it. I wanted to make sure the charter captured the intent = of user information not being a one-way flow in the protocol. How about = this: =E2=80=A6 for authorization, API access, user identifiers, and = identity assertions. The protocol will also allow the client to present = unverified identifiers and verifiable assertions to the AS as part of = its request. It=E2=80=99s much, much longer, but hopefully it avoids the garden path = and hopefully gets at capturing the intent. >=20 >>=20 >>>=20 >>>> The protocol will decouple the interaction channels, such as the = end >>>> user=E2=80=99s browser [...] >>>>=20 >>>> "interaction channels" might be a term of art that needs = clarification? >>>=20 >>> TODO >>=20 >> I don=E2=80=99t think it=E2=80=99s a specific term of art. I think we = really meant =E2=80=9Cdifferent ways to interact with the user=E2=80=9D. = One of OAuth 2=E2=80=99s limitations is that it, for the most part, = assumes the user=E2=80=99s in a browser, and the core of the protocol is = built around that. One of the goals of GNAP is to get away from that as = a base assumption. >=20 > Perhaps "decouple the channels by which the protocol participants > communicate"? That can work. >=20 >>>=20 >>>> The client and Authorization Server (AS) will involve a user to = make >>>> an authorization decision as necessary through interaction = mechanisms >>>> indicated by the protocol. >>>>=20 >>>>> =46rom a privacy perspective, will all of the information to be = made >>>> available from the AS to the RS be visible to the user as they make = this >>>> authorization decision? >>>=20 >>> TODO >>=20 >> Ultimately I don=E2=80=99t think we can fully specify the AS behavior = here, but this is a good pillar for privacy considerations. >>=20 >>>=20 >>>> The group will define interoperability for this protocol between = different >>>> parties, including >>>> - client and authorization server; >>>> - client and resource server; and >>>> - authorization server and resource server. >>>>=20 >>>> [obligatory note that just because we define an AS/RS channel = doesn't mean it >>>> will be required to use one at runtime, given the potential for = self-contained >>>> tokens?] >>>=20 >>> Are you thinking that clarification would be explicitly stated? >>=20 >> Note that a self-contained token is one of the communication channels = that the group had in mind for AS/RS. We tried to write the requirements = in such a way as to allow for self-contained messages, service-based = stuff (like introspection), or even all-in-one-box solutions that = don=E2=80=99t need =E2=80=9Ccommunication=E2=80=9D apart from both = reading the same database. This is an architectural pillar borrowed from = OAuth 2. >>=20 >>>=20 >>>> - Support for directed, audience-restricted access tokens >>>>=20 >>>> I think we need to clarify what "directed" is intended to mean here = (if it's not >>>> just a synonym for "audience-restricted" in which case it should = just be >>>> removed). >>>=20 >>> TODO >>=20 >> This one is my fault =E2=80=94 the concept we=E2=80=99re talking = about here is one where the AS can effectively tell the client where and = how it should use the token. There are a couple different WG = participants who have expressed explicit interest in this, and I=E2=80=99v= e started a thread on that topic recently: >>=20 >> = https://mailarchive.ietf.org/arch/msg/txauth/eP162P235OU0_JksY515FgmHFj0/ >=20 > I think I read that one :) >=20 > Would "AS-directed dispatch to the appropriate RS" (or similar) be a = useful > way to describe this? I think that works, as it=E2=80=99s basically about the AS telling the = client what to do next.=20 >=20 >>>=20 >>>> - A variety of client applications, including Web, mobile, >>>> single-page, and interaction-constrained applications >>>>=20 >>>> side note: this one feels like it would be easier to phrase as "the = WG will seek >>>> to minimize assumptions about the form of client applications, = allowing for >>>> [...]" >>>=20 >>> TODO >>=20 >> That seems reasonable to me, and it goes hand-in-hand with the = changes to interaction mentioned above.=20 >>=20 >>>> Additionally, the group will provide mechanisms for management of = the >>>> protocol lifecycle including: >>>> [...] >>>> - Mechanisms for the AS and RS to communicate the access granted by = an >>>> access token >>>>=20 >>>> Maybe I'm just confused, but isn't "the access granted by an access = token" >>>> exactly the set of authorizations conveyed by that token, i.e., the = core point of >>>> the protocol? I'm not sure what kind "protocol lifecycle = management" this >>>> item is intending to indicate. >>>=20 >>> TODO >>=20 >> This ties into what=E2=80=99s above: the idea is to have a standard = model for what an access token represents, and this says we=E2=80=99re = going to standardize ways for the AS and RS to communicate that. This = could be inside the token, through an introspection style service, or = some other thing we haven=E2=80=99t figured out yet. But the thing is, = all of these mechanisms should be communicating the same set of = information. This is something the OAuth WG didn=E2=80=99t address, and = so we ended up with some disparity in the handful of de-facto access = token data models there. The goal was to avoid that. >=20 > Ah, okay. So is the key point that these mechanisms/data-models are > "consistent across the entire set of protocol flows"? >=20 Yes, exactly. We want the different pieces to have a consistent model, = without turning the spec into an =E2=80=9Cabstract data model=E2=80=9D = spec itself (because we want it to be a concrete protocol). So how = about: - Data model for granted access and mechanisms for the AS and RS = to communicate the granted access model. > Thanks, >=20 > Ben Thanks again, =E2=80=94 Justin --Apple-Mail=_7FF89E6B-158E-492C-BBCE-94F08E72EB62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Ben,

On Jun 30, 2020, at 3:36 PM, Benjamin Kaduk = <kaduk@mit.edu> = wrote:

Hi Justin!

On Thu, Jun 25, 2020 at = 03:29:36PM -0400, Justin Richer wrote:
Hi Ben,

Thanks for the thorough read through, as always.

Some of my own thoughts the TODO items inline = below.


This = group is chartered to develop a fine-grained delegation protocol
for authorization and API access, as well as requesting and = providing
user identifiers and claims.

nit: this appears to parse as "providing user claims", and = I'm not sure what that
means.
TODO

Yes, the is = intended to parse as =E2=80=9Cproviding user claims=E2=80=9D. The idea = here is that the client should be able to send claims that it has to the = AS that will identify the user in a fashion that the AS can verify. In = these cases, the AS can make a policy decision without directly = involving the user for interaction. This is largely a gap in the OAuth 2 = world, though the Resource Owner Password grant and the Assertions grant = kind go in this direction, but there=E2=80=99s a desire in the community = for a general mechanism for doing this. To be clear, GNAP is going to = defer the details of these kinds of assertions to other specifications, = like W3C=E2=80=99s Verifiable Credentials. 

Let me play this back to check that I've got it right: the = idea is that the
client might have some existing assertion or something that = is evidence
that the user = has already consented to something, and the protocol is going
to include a way for the client = to convey this artifact to the AS so that
the AS can validate it and skip bothering the user directly? =  I think we'd
probably want some additional adjective here to clarify = ("user-consent
claims", "user verification claims", etc.) -- my original = best-guess
reading was = that this was "user-supplied claims", e.g., "I'd like my token
to include this arbitrary claim = I just made up, please".  (The latter's
intermingling of user-supplied = and trusted-source data is a recipe for
security issues, of course.)

Ah, I see the confusion now; right, the idea is not about the user putting claims into something that the = AS echoes back to the client. We want the AS to be able to send stuff = back that it knows about the user, but the client should be able to send = it to the AS as well. For stuff from the client, there are two = categories of information people are interested in: identifiers that = aren=E2=80=99t proven yet (so it=E2=80=99s just a hint to the AS about = who the client :thinks: the user is, like a username) and provable claim = sets that the AS can verify independently (and the protocol doesn=E2=80=99= t care how that gets validated). Most likely these latter ones will be = formatted as assertions. I didn=E2=80=99t want the charter language to = limit the format, but I might be overthinking it. I wanted to make sure = the charter captured the intent of user information not being a one-way = flow in the protocol. How about this:

=E2=80=A6 for authorization, API = access, user identifiers, and identity assertions. The protocol will = also allow the client to present unverified identifiers and verifiable = assertions to the AS as part of its request.

It=E2=80=99s much, much longer, but hopefully it = avoids the garden path and hopefully gets at capturing the = intent.




The protocol will decouple the interaction = channels, such as the end
user=E2=80=99s browser [...]

"interaction channels" might be a term of art = that needs clarification?

TODO

I don=E2=80=99t = think it=E2=80=99s a specific term of art. I think we really meant = =E2=80=9Cdifferent ways to interact with the user=E2=80=9D. One of OAuth = 2=E2=80=99s limitations is that it, for the most part, assumes the = user=E2=80=99s in a browser, and the core of the protocol is built = around that. One of the goals of GNAP is to get away from that as a base = assumption.

Perhaps "decouple the channels by which the protocol = participants
communicate"?

That can work.



The = client and Authorization Server (AS) will involve a user to make
an authorization decision as necessary through interaction = mechanisms
indicated by the protocol.

=46rom a privacy = perspective, will all of the information to be made
available from the AS to the RS be visible to = the user as they make this
authorization decision?

TODO
Ultimately I don=E2=80=99t think we can fully specify the AS = behavior here, but this is a good pillar for privacy considerations.


The group will define = interoperability for this protocol between different
parties, including
 - client and = authorization server;
 - client and resource server; = and
 - authorization server and resource server.

[obligatory note that just because we define = an AS/RS channel doesn't mean it
will be required to use = one at runtime, given the potential for self-contained
tokens?]

Are you = thinking that clarification would be explicitly stated?

Note that a self-contained token = is one of the communication channels that the group had in mind for = AS/RS. We tried to write the requirements in such a way as to allow for = self-contained messages, service-based stuff (like introspection), or = even all-in-one-box solutions that don=E2=80=99t need = =E2=80=9Ccommunication=E2=80=9D apart from both reading the same = database. This is an architectural pillar borrowed from OAuth 2.


- Support for directed, = audience-restricted access tokens

I think = we need to clarify what "directed" is intended to mean here (if it's = not
just a synonym for "audience-restricted" in which case = it should just be
removed).

TODO

This one is my = fault =E2=80=94 the concept we=E2=80=99re talking about here is one = where the AS can effectively tell the client where and how it should use = the token. There are a couple different WG participants who have = expressed explicit interest in this, and I=E2=80=99ve started a thread = on that topic recently:

https://mailarchive.ietf.org/arch/msg/txauth/eP162P235OU0_JksY5= 15FgmHFj0/

I think I read that one :)

Would "AS-directed dispatch to the appropriate RS" (or = similar) be a useful
way to describe this?

I think that works, as it=E2=80=99s basically = about the AS telling the client what to do next. 



- A variety of client applications, including = Web, mobile,
  single-page, and = interaction-constrained applications

side = note: this one feels like it would be easier to phrase as "the WG will = seek
to minimize assumptions about the form of client = applications, allowing for
[...]"

TODO
That seems reasonable to me, and it goes hand-in-hand with = the changes to interaction mentioned above. 

Additionally, the group will provide mechanisms for = management of the
protocol lifecycle including:
[...]
- Mechanisms for the AS and RS to = communicate the access granted by an
  access = token

Maybe I'm just confused, but isn't = "the access granted by an access token"
exactly the set of = authorizations conveyed by that token, i.e., the core point of
the protocol?  I'm not sure what kind "protocol = lifecycle management" this
item is intending to = indicate.

TODO

This ties into what=E2=80=99s = above: the idea is to have a standard model for what an access token = represents, and this says we=E2=80=99re going to standardize ways for = the AS and RS to communicate that. This could be inside the token, = through an introspection style service, or some other thing we haven=E2=80= =99t figured out yet. But the thing is, all of these mechanisms should = be communicating the same set of information. This is something the = OAuth WG didn=E2=80=99t address, and so we ended up with some disparity = in the handful of de-facto access token data models there. The goal was = to avoid that.

Ah, okay.  So is the key point that these = mechanisms/data-models are
"consistent across the entire set of protocol = flows"?


Yes, = exactly. We want the different pieces to have a consistent model, = without turning the spec into an =E2=80=9Cabstract data model=E2=80=9D = spec itself (because we want it to be a concrete protocol). So how = about:

- Data model for granted access = and mechanisms for the AS and RS to communicate the granted access = model.


Thanks,

Ben

Thanks = again,
 =E2=80=94 Justin

= --Apple-Mail=_7FF89E6B-158E-492C-BBCE-94F08E72EB62-- From nobody Tue Jun 30 13:09:11 2020 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 080893A07E0; Tue, 30 Jun 2020 13:08:57 -0700 (PDT) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 vEJC5Cpmz9ue; Tue, 30 Jun 2020 13:08:55 -0700 (PDT) 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 DCE3C3A07D1; Tue, 30 Jun 2020 13:08:54 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05UK8n7G005818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 16:08:51 -0400 Date: Tue, 30 Jun 2020 13:08:48 -0700 From: Benjamin Kaduk To: Justin Richer Cc: "rdd@cert.org" , The IESG , "gnap-chairs@ietf.org" , "txauth@ietf.org" Message-ID: <20200630200848.GU58278@kduck.mit.edu> References: <159305522436.11733.15198171728373227965@ietfa.amsl.com> <559FF73B-38D4-4D49-8827-0958613912C0@mit.edu> <20200630193602.GT58278@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Txauth] Benjamin Kaduk's No Objection on charter-ietf-gnap-00-01: (with COMMENT) 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, 30 Jun 2020 20:08:57 -0000 Hi Justin, On Tue, Jun 30, 2020 at 03:59:17PM -0400, Justin Richer wrote: > Hi Ben, > > > On Jun 30, 2020, at 3:36 PM, Benjamin Kaduk wrote: > > > > Hi Justin! > > > > On Thu, Jun 25, 2020 at 03:29:36PM -0400, Justin Richer wrote: > >> Hi Ben, > >> > >> Thanks for the thorough read through, as always. > >> > >> Some of my own thoughts the TODO items inline below. > >> > >>>> > >>>> This group is chartered to develop a fine-grained delegation protocol > >>>> for authorization and API access, as well as requesting and providing > >>>> user identifiers and claims. > >>>> > >>>> nit: this appears to parse as "providing user claims", and I'm not sure what that > >>>> means. > >>> > >>> TODO > >> > >> Yes, the is intended to parse as “providing user claims”. The idea here is that the client should be able to send claims that it has to the AS that will identify the user in a fashion that the AS can verify. In these cases, the AS can make a policy decision without directly involving the user for interaction. This is largely a gap in the OAuth 2 world, though the Resource Owner Password grant and the Assertions grant kind go in this direction, but there’s a desire in the community for a general mechanism for doing this. To be clear, GNAP is going to defer the details of these kinds of assertions to other specifications, like W3C’s Verifiable Credentials. > > > > Let me play this back to check that I've got it right: the idea is that the > > client might have some existing assertion or something that is evidence > > that the user has already consented to something, and the protocol is going > > to include a way for the client to convey this artifact to the AS so that > > the AS can validate it and skip bothering the user directly? I think we'd > > probably want some additional adjective here to clarify ("user-consent > > claims", "user verification claims", etc.) -- my original best-guess > > reading was that this was "user-supplied claims", e.g., "I'd like my token > > to include this arbitrary claim I just made up, please". (The latter's > > intermingling of user-supplied and trusted-source data is a recipe for > > security issues, of course.) > > Ah, I see the confusion now; right, the idea is not about the user putting claims into something that the AS echoes back to the client. We want the AS to be able to send stuff back that it knows about the user, but the client should be able to send it to the AS as well. For stuff from the client, there are two categories of information people are interested in: identifiers that aren’t proven yet (so it’s just a hint to the AS about who the client :thinks: the user is, like a username) and provable claim sets that the AS can verify independently (and the protocol doesn’t care how that gets validated). Most likely these latter ones will be formatted as assertions. I didn’t want the charter language to limit the format, but I might be overthinking it. I wanted to make sure the charter captured the intent of user information not being a one-way flow in the protocol. How about this: > > … for authorization, API access, user identifiers, and identity assertions. The protocol will also allow the client to present unverified identifiers and verifiable assertions to the AS as part of its request. > > It’s much, much longer, but hopefully it avoids the garden path and hopefully gets at capturing the intent. I think it looks good, thanks. > > > >> > >>> > >>>> The protocol will decouple the interaction channels, such as the end > >>>> user’s browser [...] > >>>> > >>>> "interaction channels" might be a term of art that needs clarification? > >>> > >>> TODO > >> > >> I don’t think it’s a specific term of art. I think we really meant “different ways to interact with the user”. One of OAuth 2’s limitations is that it, for the most part, assumes the user’s in a browser, and the core of the protocol is built around that. One of the goals of GNAP is to get away from that as a base assumption. > > > > Perhaps "decouple the channels by which the protocol participants > > communicate"? > > That can work. > > > > >>> > >>>> The client and Authorization Server (AS) will involve a user to make > >>>> an authorization decision as necessary through interaction mechanisms > >>>> indicated by the protocol. > >>>> > >>>>> From a privacy perspective, will all of the information to be made > >>>> available from the AS to the RS be visible to the user as they make this > >>>> authorization decision? > >>> > >>> TODO > >> > >> Ultimately I don’t think we can fully specify the AS behavior here, but this is a good pillar for privacy considerations. > >> > >>> > >>>> The group will define interoperability for this protocol between different > >>>> parties, including > >>>> - client and authorization server; > >>>> - client and resource server; and > >>>> - authorization server and resource server. > >>>> > >>>> [obligatory note that just because we define an AS/RS channel doesn't mean it > >>>> will be required to use one at runtime, given the potential for self-contained > >>>> tokens?] > >>> > >>> Are you thinking that clarification would be explicitly stated? > >> > >> Note that a self-contained token is one of the communication channels that the group had in mind for AS/RS. We tried to write the requirements in such a way as to allow for self-contained messages, service-based stuff (like introspection), or even all-in-one-box solutions that don’t need “communication” apart from both reading the same database. This is an architectural pillar borrowed from OAuth 2. > >> > >>> > >>>> - Support for directed, audience-restricted access tokens > >>>> > >>>> I think we need to clarify what "directed" is intended to mean here (if it's not > >>>> just a synonym for "audience-restricted" in which case it should just be > >>>> removed). > >>> > >>> TODO > >> > >> This one is my fault — the concept we’re talking about here is one where the AS can effectively tell the client where and how it should use the token. There are a couple different WG participants who have expressed explicit interest in this, and I’ve started a thread on that topic recently: > >> > >> https://mailarchive.ietf.org/arch/msg/txauth/eP162P235OU0_JksY515FgmHFj0/ > > > > I think I read that one :) > > > > Would "AS-directed dispatch to the appropriate RS" (or similar) be a useful > > way to describe this? > > I think that works, as it’s basically about the AS telling the client what to do next. > > > > >>> > >>>> - A variety of client applications, including Web, mobile, > >>>> single-page, and interaction-constrained applications > >>>> > >>>> side note: this one feels like it would be easier to phrase as "the WG will seek > >>>> to minimize assumptions about the form of client applications, allowing for > >>>> [...]" > >>> > >>> TODO > >> > >> That seems reasonable to me, and it goes hand-in-hand with the changes to interaction mentioned above. > >> > >>>> Additionally, the group will provide mechanisms for management of the > >>>> protocol lifecycle including: > >>>> [...] > >>>> - Mechanisms for the AS and RS to communicate the access granted by an > >>>> access token > >>>> > >>>> Maybe I'm just confused, but isn't "the access granted by an access token" > >>>> exactly the set of authorizations conveyed by that token, i.e., the core point of > >>>> the protocol? I'm not sure what kind "protocol lifecycle management" this > >>>> item is intending to indicate. > >>> > >>> TODO > >> > >> This ties into what’s above: the idea is to have a standard model for what an access token represents, and this says we’re going to standardize ways for the AS and RS to communicate that. This could be inside the token, through an introspection style service, or some other thing we haven’t figured out yet. But the thing is, all of these mechanisms should be communicating the same set of information. This is something the OAuth WG didn’t address, and so we ended up with some disparity in the handful of de-facto access token data models there. The goal was to avoid that. > > > > Ah, okay. So is the key point that these mechanisms/data-models are > > "consistent across the entire set of protocol flows"? > > > > Yes, exactly. We want the different pieces to have a consistent model, without turning the spec into an “abstract data model” spec itself (because we want it to be a concrete protocol). So how about: > > - Data model for granted access and mechanisms for the AS and RS to communicate the granted access model. Works for me. Thanks again! -Ben
On Tue, Jun 16, 2020 at = 10:44 AM Justin Richer <jricher@mit.e= du> wrote:
My concern on the pronunciation= remains, and I don=E2=80=99t think putting a pronunciation in the charter,= which hardly anyone will read again after a couple weeks from now, is goin= g to address it. That=E2=80=99s why I think we should just get used to hear= ing it multiple ways, which you=E2=80=99ve agreed with. I personally think = it=E2=80=99s just a problem we=E2=80=99ll have to live with, and that was o= ne of the concerns I had with the name.

But really, does= it matter? I don=E2=80=99t think it does.

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

On Jun 16, 2020, a= t 1:08 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

It seems strange that you now call addressing the concerns you raised "s= illy".=C2=A0

While there is no confusion in w= ritten communication with GNAP, there clearly will be in verbal communicati= on.=C2=A0

Starting off with a suggested pronunciat= ion looks to me to nip a significant amount of the confusion in the bud.

We can deal with it now, or deal with it later, or i= t can be a source of confusion and communication friction forever.

Why not just pick one pronunciation and move on?

=
On Tue, Ju= n 16, 2020 at 7:42 AM Justin Richer <jricher@mit.edu> wrote:
I don=E2=80=99t believe we should add= a proposed pronunciation to the charter. It seems silly to focus on this s= o much.

=C2=A0=E2=80=94 Justin

On Jun 15, 2020, at 6:14 PM, Dick Hardt <dick.hardt@gmail.com> w= rote:

I agree we should be = prepared for both. Can we agree that we can be consistent? Personally I don= 't care which we choose -- I only care that we choose one.

I was working=C2=A0to address the conc= ern that you (Justin) had brought up:

This is ok, but it has a couple downsides. The pronunciation of a hard =E2=80=9Cg=E2= =80=9D or not is going to potentially be confusing, as is the fact that it = looks like it=E2=80=99s part of the GNU project because of that.



On Mon, Jun 15, 20= 20 at 1:56 PM Justin Richer <jricher@mit.edu> wrote:
I agree with Mike, in that we should get us= ed to answering to both.

In my head, it reads with a har= d =E2=80=9CG=E2=80=9D, at least partially because of the Smurfs video=E2=80= =99s legacy.

=C2=A0=E2=80=94 Justin

On Jun 15, 2020, at 3:38 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> wrote:
<= br>
I= don=E2=80=99t care a lot one way or the other.=C2=A0 My main point is that= no matter what guidance we give, many people are likely to pronounce the = =E2=80=9CG=E2=80=9D.=C2=A0 If we try to insist on it being silent, we shoul= d get used to the fact that we=E2=80=99ll probably be hearing both pronunci= ations.
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
=C2=A0
P.S.=C2=A0 Thanks for the Smurfs l= ink, Vittorio!
=C2=A0
From:=C2=A0vittorio.bertocci@auth0.com=C2=A0<= vittorio.bertocci@auth0.com>=C2=A0
Sent:=C2=A0Monday, June 15, 2020 12= :25 PM
To:=C2=A0'Dick Hardt' <dick.hardt@gmail.com>; 'Peter Saint-Andre'= ; <stpeter@mozilla.com>
Cc:=C2=A0Mike Jones <Mic= hael.Jones@microsoft.com>; 'Jared Jennings' <jaredljennings@gmail.com>; 'Amanjeev Sethi= ' <aj@amanjeev.com>; 'Fabien Imb= ault' <fabien.imbault@gmail.com>;=C2=A0txauth@ietf.org
Subject:=C2=A0RE: [Txauth] GNAP it is
=
=C2=A0
Perhaps not to be= taken too seriously, but here=E2=80=99s prior art on GNAP pronunciation.
As Leif mentioned few mails ago, =E2=80=9CGNAP= =E2=80=9D appeared on the Smurfs comic and was reprised in a cartoon episod= e as well.
You=E2=80=99ll find few examples ar= ound 3:30
= =C2=A0
= From:=C2=A0Txauth <= txauth-bounces@ietf.org>=C2=A0On Behalf Of=C2= =A0Dick Hardt
Sent:=C2=A0Monday, June 15,= 2020 12:18 PM
To:=C2=A0Peter Saint-Andre <stpeter@mozilla.com>
Cc:=C2= =A0Mike Jones <Michael.Jones= @microsoft.com>; Jared Jennings <jaredljennings@gmail.com>; Amanjeev Sethi <aj@amanjeev.com>; Fabien Imbault <fabien.imbault@gmail.com>;=C2=A0txauth@ietf.org
Subject:=C2=A0Re: [T= xauth] GNAP it is
=C2=A0
Checking in again on pronunciation.
<= div>
=C2=A0
Mike: do you s= till have concerns with a silent 'G'?
=C2=A0
Anyone else have = concerns?
=C2=A0
I'd like to nip pronunciation confusion in the bu= d by having the recommended pronunciation=C2=A0in the charter.
=C2=A0
= =C2=A0
=E1=90=A7
= =C2=A0
On Sun, Jun 7, 2020 at 1:23 P= M Peter Saint-Andre <stpeter@mozilla.com> wrote:
Looks like we w= ere caught gnapping. ;-)

OK, that's the last of my snarky commen= ts, let's get to work!

Peter

On 6/7/20 2:09 PM, Dick Hard= t wrote:
> It is if you are familiar with any of the GNU projects.>=C2=A0
>=C2=A0https://www.gnu.org/gnu/pronunciation.en.html>=C2=A0
> A quick search on the internet has the &q= uot;normal" pronunciation of "gnu"
> to have a silent = 'g'.
>=C2=A0
>=C2=A0https://www.howtopronounce.com/gnu
>= ;=C2=A0https://dictionary.cambridge.org/us/pronunciation/english/gnu<= br>>=C2=A0
>=C2=A0
>=C2=A0=E1=90=A7
>= =C2=A0
> On Sun, Jun 7, 2020 at 12:51 PM Mike Jones <= Michael.Jones@microsoft.com
>= ; <mailto:Michael.Jones@microsoft.c= om>> wrote:
>=C2=A0
>=C2=A0 =C2=A0 =C2= =A0I had assumed Guh-Nap =E2=80=93 parallel to the pronunciation of GNU.=C2= =A0 I
>=C2=A0 =C2=A0 =C2=A0think that=E2=80=99s the most natural way = to read it.____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0__=C2= =A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 -- Mike____
>=C2=A0
>=C2=A0 =C2=A0 =C2= =A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0*From:*= Txauth <txauth-bounces@ietf.org>=C2=A0 =C2=A0 =C2=A0<mailto:txauth= -bounces@ietf.org>> *On Behalf Of *Dick Hardt
>=C2=A0 =C2= =A0 =C2=A0*Sent:* Sunday, June 7, 2020 12:45 PM
>=C2=A0 =C2=A0 =C2=A0= *To:* Amanjeev Sethi <aj@amanjeev.com= =C2=A0<mailto:aj@amanjeev.com>>= ;
>=C2=A0 =C2=A0 =C2=A0*Cc:* Fabien Imbault <fabien.imbault@gmail.com
>=C2=A0 =C2=A0 =C2=A0<ma= ilto:fabien.imbault@gmail.com>>= ; Jared Jennings
>=C2=A0 =C2=A0 =C2=A0<jaredljennings@gmail.com=C2=A0<mailto:jaredljennings@gmail.com>>;
>=C2=A0= =C2=A0 =C2=A0txauth@ietf.org=C2=A0<mailto:txauth@ietf.org>
>=C2=A0= =C2=A0 =C2=A0*Subject:* Re: [Txauth] GNAP it is____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
&g= t;=C2=A0 =C2=A0 =C2=A0Anyone have objection to the recommended pronunciatio= n=C2=A0being the
>=C2=A0 =C2=A0 =C2=A0English word "nap", a= s in "gnaw"?____
>=C2=A0
>=C2=A0 =C2=A0 = =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0If n= ot, then we could add a pronunciation=C2=A0recommendation to the
>=C2= =A0 =C2=A0 =C2=A0Charter.____
>=C2=A0
>=C2=A0 =C2= =A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0= =E1=90=A7____
><= span>=C2=A0
>=C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2= =A0
>=C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020 at 8:03 AM Amanje= ev Sethi <aj@amanjeev.com
>=C2=A0 =C2= =A0 =C2=A0<mailto:aj@amanjeev.com>> w= rote:____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Vote for 'G' silent, as in 'lagnappe' ;)____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>= =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Sat, Jun 6,= 2020, at 10:52 AM, Jared Jennings wrote:____
>=C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I vote for G silent. F= or the reason it's most common to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0pronounce, especially for those not familiar with open<= br>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0source usages.____>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0On Sat, Jun 6, 2020, 08:45 Dick Hardt <dick.hardt@gmail.com
>=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:dick.h= ardt@gmail.com>> wrote:____
>=C2=A0
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The obvious pron= unciation choices are:____
>=C2=A0
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2= =A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0nap (silent g as in gnaw)____
>=C2=A0
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
&g= t;=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0guh-nap (as in the GNU OS
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0https://www.gnu.org/gnu/pronunciation.en..html
&g= t;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.gnu.org/gnu/pronunciat= ion.en.html>)____
>=C2=A0
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2= =A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0gee-nap (as in G-man - government man
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0https://en.wikipedia.org/wiki/G-man)____
>=C2= =A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2= =A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0= =E1=90=A7____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0O= n Sat, Jun 6, 2020 at 1:34 AM Fabien Imbault
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<fabien.imbault@gmail.com
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:fab= ien.imbault@gmail.com>> wrote:____
>=C2=A0
= >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0So, let's adopt a GNAP! We can even come with a
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0little ma= scot (a bit like go gopher) as imagined
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by=C2=A0http://elisegravel.com/blog/adopte-un-gnap/,=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0loved by little Canadians :-)=C2=A0____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Just to be sure, ho= w do you recommand we pronounce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it?=C2=A0____
>=C2=A0<= /span>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Looking forw= ard to the next steps too..=C2=A0____
>=C2=A0
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__= =C2=A0__
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thxs____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0Fabien____
>=C2=A0
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--____
>= ;=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list____
>=C2=A0<= /span>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Txauth@ietf.org=C2=A0<mailto:Txauth@ietf.org>____
>= ;=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/txauth____
>= =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0--____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth mailing list____
>= =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Txauth@ietf.org=C2=A0&l= t;mailto:Txauth@ietf.org>____
>= =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0https://www.ie= tf.org/mailman/listinfo/txauth____
>=C2=A0
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--=C2=A0____
>= =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth= mailing list____
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Txauth@ietf.org=C2=A0<mailto:Txauth@ietf.org>_= ___
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0https://www= .ietf.org/mailman/listinfo/txauth____
>=C2=A0
>= ;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>= =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0__=C2=A0__
>=C2=A0
>=C2=A0
--=C2= =A0
Txauth mailing list
Txauth@ie= tf.org
https://www.i= etf.org/mailman/listinfo/txauth


I find this feature interesting and think it could be an i= mportant=C2=A0pattern going=C2=A0forward to enable an AS to be able to desc= ribe the utility of a token to the client, however as already pointed out i= n the thread I think there is some potential hidden complexity that would n= eed to be ironed out such that it does not make the simple things complicat= ed.

Justin, do you see this feature as something the cli= ent has to explicitly request, i.e "please give me access and instruct= ions on how to use my access" or rather that the AS would just return = this information in conjunction with the access token if it had it availabl= e?

> This is just the start, too. Things get ev= en more complex if the client can ask for multiple different kinds of resou= rces at once. What if the AS decides that the client needs a hyper-focused = directed token for one part of the API, but can use a general token for oth= er stuff? Can it signal that to the client? And if it can, does that mean t= hat all clients need to be prepared for that kind of thing?

<= /div>
Would a potential default be that if a client did for any reason = not support processing the additional information returned with the access_= token, just to ignore it? I think in the spirit of keeping the simple thing= s simple, this potentially makes sense?

> here = are some worked out samples of this:
Peace ..tom

As one of the authors of those mentioned drafts, I am inte= rested in discussing that, but perhaps on a seperate thread? As at least=C2= =A0the bound assertion spec is=C2=A0primarily=C2=A0concerned with binding m= echanisms for the artifacts produced from an authorization flow (specifical= ly identity claims), whereas I think directed access tokens is just more ge= nerally talking about whether GNAP should support an AS conveying how to us= e an access_token it produces during a flow with a client.

Thanks,
3D==C2=A0=
Tobias Looker
Mattr<= /td>
+64 (0) 27 378 0461
to= bias.looker@mattr.global
3D"Mattr
3D"Mattr3D"Mattr3D"Mattr

This communication, including any attachments, is= confidential. If you are not the intended recipient, you should not read i= t - please contact me immediately, destroy it, and do not copy or use any p= art of this communication or disclose anything about it. Thank you. Please = note that this communication does not designate an information system for t= he purposes of the Electronic Transactions Act 2002.


On Wed, Jun 24, 2020 at 10:14 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Justin, I fear we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I am getting tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it=E2=80=99s g= oing to be overwhelmingly common that a given RS is going to trust exactly one AS
that it knows about ahead of time". Such an architecture would have exactly the same limitations as OAuth 2.0. and would not be scalable.

Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions.
For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believe that we have an agreement at this time on what these trust relationships are.

You are also using the following wording: "methods for the AS and RS to communicate what the token=E2=80=99s good for".
With such a paradigm, it would be impossible to protect the user'= s privacy.

A key question is : Will GNAP take care of the user's privacy or will GNAP prevent to take care of the user's privacy ?

About "the ability for the client to get several access tokens to get different resources from one request" is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform
on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).

First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases.

When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS.
His "consent and choice" should then be obtained by the first RS and, when the user agrees, the client should then ask an access token
to one of the ASs trusted by the second RS in order to perform the subsequent operation.=C2=A0

Denis

PS.=C2=A0 In an email sent on June 23 you wrote: " I think an on-device AS is an important use case".= =C2=A0 I am sorry, but I don't understand.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 However, I do understand what &q= uot;a server-based AS" is.


=20 Denis, thanks for the great comments. I think that your trust model is pretty different from what I=E2=80=99d laid out initially, a= nd while it=E2=80=99s an interesting and important one, it is not what I meant by =E2=80=9Cmultiple access tokens=E2=80=9D in my discussion be= low. I think that might be the cause of some disconnect here, but that doesn=E2=80= =99t mean it=E2=80=99s out of reach for what the WG is after.

When I refer to multiple access tokens, and what the charter calls out as multiple access tokens, is the ability for the client to get several access tokens to get different resources from one request. I personally see this as an optimization of a specific set of use cases, some of which I discussed in my original email. There are others, I=E2=80=99m sure,= but all the ones I=E2=80=99ve seen are around the client needing to get several different kinds of access through an AS.=C2=A0

I think it=E2=80=99s going to be overwhelmingly common that a given RS is going to trust exactly one AS that it knows about ahead of time. But for RS=E2=80=99s that can trust multiple AS=E2=80=99s, then we should have a model that can accommodate th= at as well. That=E2=80=99s why the charter calls out methods for the AS= and RS to communicate what the token=E2=80=99s good for. I think the = basis of those methods is going to start with a common token model, and likely incorporate into things like token formats and introspection-style token APIs.=C2=A0

=C2=A0=E2=80=94 Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the lines.

One of the most i= mportant aspects to GNAP is going to be an ability to address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do witho= ut significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don=E2=80=99= t know if this concept has a regular term, so I=E2=80=99m g= oing to call it =E2=80=9Cdirected access tokens=E2=80=9D until= we come up with something better =E2=80=94 assuming we decide this i= s worthwhile.=C2=A0

I don't understand what may mean "directed access tokens=E2= =80=9D but I understand what means "multiple access tokens"= ;.=C2=A0
When speaking of "multiple access tokens", thes= e access tokens may come from one or more ASs.

In OAuth, the client=E2=80=99s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we=E2=80=99re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.=C2=A0

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".<= br> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of=C2=A0di= rections=C2=A0about what that specific token is good for. This needs to be information outside the token itself, since I=C2=A0believe we want to keep OAuth 2=E2=80=99s featur= e of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t enough to tell the client what to do with= the token=C2=A0if it doesn=E2=80=99t know a= lready.=C2=A0

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I=E2=80=99ll try to summarize here, but I know the folk= s I=E2=80=99ve been talking to about this are also on the= list so hopefully they can chime in with more detail or any corrections for something I=E2=80=99ve missed.=C2= =A0

(1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s= hosted. Everything is in a single security domain controlled by the AS,=C2=A0

Speaking of "multiple access tokens" is in contradiction wi= th single security domain "controlled" by an AS.=C2=A0
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also=C2= =A0
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be=C2=A0<= /span>
the "primary issuer" of a university diploma. I= t should not be either a "secondary issuer", beca= use=C2=A0
the bank does not "need to know"= =C2=A0what are the diplomas of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved in that step.= =C2=A0
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" which= has the knowledge of the different RSs affiliated to it.=C2=A0

(2) The client knows what kind of thing it=E2=80=99s looking for, but doesn=E2=80=99t know who = to ask it from.=C2=A0

Once again, the client could first talk to a "global service provide= r" which has the knowledge of the different RSs affiliated to it.=C2=A0

There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver=E2=80=99s license information, but doesn=E2=80= =99t know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn=E2=80= =99t know yet who the user is.=C2=A0

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at.=C2=A0

=C2=A0A single AS should not be aware of all the attributes a user has.=C2=A0


As far as I know, in both of these cases, the token is only good for that API and not others =E2=80=94 but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go.=C2=A0

{
=E2=80= =9Caccess_token=E2=80=9D: {
=E2= =80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
=E2= =80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
}
}

This is good for some kinds of APIs, but it=E2=80=99s limiting because not all APIs dispatch bas= ed on the URL. An AS might want to divvy up access tokens to an API that=E2=80=99s keyed on headers, or verbs, or= any number of things. And it doesn=E2=80=99t tell us immedi= ately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it=E2=80=99s not univers= al. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can=E2=80=99t get= in the way of this, because if it does, there=E2=80=99s ve= ry small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I=E2=80=99m really looking forward to hearing what the community thinks about these use cases, and hopefully the people I=E2=80=99ve chatted with offline = about this can join the conversation and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s= hosted.
(2) The client knows what kind of thing it=E2=80=99s lo= oking for, but doesn=E2=80=99t know who to ask it from.= =C2=A0

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Denis


=C2=A0=E2=80=94 Justin


--=C2= =A0
Txauth mail= ing list
Txauth@ietf= .org
https://www.ietf.org/mailman/listinfo/txauth


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

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
--0000000000007ee79805a8f2570a-- From nobody Thu Jun 25 21:38:49 2020 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 B439B3A1125 for ; Thu, 25 Jun 2020 21:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 Y4zE2bm5HvQa for ; Thu, 25 Jun 2020 21:38:44 -0700 (PDT) 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 40F323A1124 for ; Thu, 25 Jun 2020 21:38:44 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id m2so7432861otr.12 for ; Thu, 25 Jun 2020 21:38:44 -0700 (PDT) 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=nXyGC+y+xkN6r2KkxCo2pme39qwworaDU4Aq87HJebQ=; b=N2Jt/PDQVc/9E8H6A7z+LDfqogzWQpsj2hL+JRbllSNT0XYrrRxGAKZHHg/ME3sMYe tpJeTsCcNp5TAGcloybcX2dC7dAdsMGxx3NvTd9umu7GFuB37eel0rYsHmdBsHf7mEPF x8BwPfmBm5w3nVv35amcFMRHsXSBZmY4f3ugfJIfa4iGJ9fHZEmqU2r68dbhV8jn+N5+ oAus1VJeg+h46GsoBjZjn6KwhyuUUMhHN5Qof41sVWcuSnBRJc0DLmXA6c972AKOTGIw FT2Zd5qaQc+EEygum2vy4b0LdODBHEsUPrquMWkMSK2+B1yTm3tjiCwMQu3a+o6WcCTj oF8w== 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=nXyGC+y+xkN6r2KkxCo2pme39qwworaDU4Aq87HJebQ=; b=KGG1P4qknfAQybwrYisjqvb+6ow8uBCRrgmLw29lkYZXdpiL6DtDNLWM6o1hSveaB/ adqsgfypFIjdmRoyZDQ0FQHwkQZ0tof+G/SfJSTlLeQ4pv7EmKIEZvYrxMA2tDgVFEC6 BxEiizqiNW7HsTDJZfapd1TZ9/iEVwAUsXYum4uI9gU8yRTHKKIv/UeZJ4dpAfJ2GTJ+ 4zjAKQwwWZ5Et0R29RE3JsrOQHW6IyCZiHW/kKpmIWom9EOJ9gvR8OelVo+L4p2Lhcle mbYb2oOW5jbm61jqXixNQGzCRckLZQ+bxJyMUQMtTNajESz+nb5le3lzW5L1AVaEWkcB TWqA== X-Gm-Message-State: AOAM530AH46CjKaFwMUq/M8cRcyx1s5RMAqN9YbMGp7wy0SfElYxB0l+ 4eF55usDrQQVNsgvgoRSoXnyOXVy8Es7LjVAXqQ= X-Google-Smtp-Source: ABdhPJwbgbtAoN7S0kTh+x/8msoP9nU7p4z2RKZFF1xH5WovYdX0nK1XfnrPkyT/4zW4fvEuLkIEQULvmggsvDvtaZE= X-Received: by 2002:a05:6830:837:: with SMTP id t23mr884985ots.87.1593146323259; Thu, 25 Jun 2020 21:38:43 -0700 (PDT) MIME-Version: 1.0 References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> In-Reply-To: From: Tom Jones Date: Thu, 25 Jun 2020 21:38:31 -0700 Message-ID: To: Tobias Looker Cc: Denis , txauth@ietf.org, Justin Richer Content-Type: multipart/alternative; boundary="000000000000ac56fa05a8f54899" Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 26 Jun 2020 04:38:48 -0000 --000000000000ac56fa05a8f54899 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think Tobias & I have converged to a single request for a "bound" token. I really don't care much what it is called. I do have some input on the continents of the claims. Peace ..tom On Thu, Jun 25, 2020 at 6:08 PM Tobias Looker wrote: > I find this feature interesting and think it could be an important patter= n > going forward to enable an AS to be able to describe the utility of a tok= en > to the client, however as already pointed out in the thread I think there > is some potential hidden complexity that would need to be ironed out such > that it does not make the simple things complicated. > > Justin, do you see this feature as something the client has to explicitly > request, i.e "please give me access and instructions on how to use my > access" or rather that the AS would just return this information in > conjunction with the access token if it had it available? > > > This is just the start, too. Things get even more complex if the client > can ask for multiple different kinds of resources at once. What if the AS > decides that the client needs a hyper-focused directed token for one part > of the API, but can use a general token for other stuff? Can it signal th= at > to the client? And if it can, does that mean that all clients need to be > prepared for that kind of thing? > > Would a potential default be that if a client did for any reason not > support processing the additional information returned with the > access_token, just to ignore it? I think in the spirit of keeping the > simple things simple, this potentially makes sense? > > > here are some worked out samples of this: > https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token > https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ > Peace ..tom > > As one of the authors of those mentioned drafts, I am interested in > discussing that, but perhaps on a seperate thread? As at least the bound > assertion spec is primarily concerned with binding mechanisms for the > artifacts produced from an authorization flow (specifically identity > claims), whereas I think directed access tokens is just more generally > talking about whether GNAP should support an AS conveying how to use an > access_token it produces during a flow with a client. > > Thanks, > [image: Mattr website] > *Tobias Looker* > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > [image: Mattr website] [image: Mattr on LinkedIn] > [image: Mattr on Twitter] > [image: Mattr on Github] > > This communication, including any attachments, is confidential. If you ar= e > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > > On Wed, Jun 24, 2020 at 10:14 PM Denis wrote: > >> Justin, I fear we are still far away from an agreement about what this >> BoF should do. >> >> Tom Jones is saying " I am getting tired of the whack-a-mole approach ..= ." >> >> I don't agree with you when you write: "I think it=E2=80=99s going to be >> overwhelmingly common that a given RS is going to trust exactly one AS >> that it knows about ahead of time". Such an architecture would have >> exactly the same limitations as OAuth 2.0. and would not be scalable. >> >> Before we start, we should have a clear view of the whole picture rather >> than starting from one scenario and expanding it in many different >> directions. >> For building an architecture, a pre-requirement is to define ALL the >> trust relationships. I don't believe that we have an agreement at this t= ime >> on what >> these trust relationships are. >> >> You are also using the following wording: "methods for the AS and RS to >> communicate what the token=E2=80=99s good for". >> With such a paradigm, it would be impossible to protect the user's >> privacy. >> >> A key question is : Will GNAP take care of the user's privacy or will >> GNAP *prevent *to take care of the user's privacy ? >> >> About "the ability for the client to get several access tokens to get >> different resources from one request" is indeed a complex case. >> >> No one (including ASs) is able to predict in advance which access tokens >> will be needed, since they depend upon the kind of operation(s) >> the client will be willing to perform. For privacy reasons, ASs should b= e >> kept ignorant of all the operations that a client is going to perform >> on one or more resource servers. I believe that every effort should be >> made to avoid the AS to be in a position to be able to trace the operati= ons >> performed by its clients on various RSs. >> >> To handle the complex case you envision, the full workflow of operations >> needs to be considered with a detailed focus on the time >> at which the user's *consent and choice* happens (*consent and choice* >> is the first privacy principle from ISO 29100). >> >> First of all, an access token could be targeted to a service rather than >> to a server. This would already solve many cases. >> >> When a RS needs to call another RS (which does not support the same >> service) then the client should be informed by the first RS. >> His "consent and choice" should then be obtained by the first RS and, >> when the user agrees, the client should then ask an access token >> to one of the ASs trusted by the second RS in order to perform the >> subsequent operation. >> >> Denis >> >> PS. In an email sent on June 23 you wrote: " I think an on-device AS is >> an important use case". I am sorry, but I don't understand. >> However, I do understand what "a server-based AS" is. >> >> >> Denis, thanks for the great comments. I think that your trust model is >> pretty different from what I=E2=80=99d laid out initially, and while it= =E2=80=99s an >> interesting and important one, it is not what I meant by =E2=80=9Cmultip= le access >> tokens=E2=80=9D in my discussion below. I think that might be the cause = of some >> disconnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of reach= for what the WG is >> after. >> >> When I refer to multiple access tokens, and what the charter calls out a= s >> multiple access tokens, is the ability for the client to get several acc= ess >> tokens to get different resources from one request. I personally see thi= s >> as an optimization of a specific set of use cases, some of which I >> discussed in my original email. There are others, I=E2=80=99m sure, but = all the >> ones I=E2=80=99ve seen are around the client needing to get several diff= erent kinds >> of access through an AS. >> >> I think it=E2=80=99s going to be overwhelmingly common that a given RS i= s going >> to trust exactly one AS that it knows about ahead of time. But for RS=E2= =80=99s >> that can trust multiple AS=E2=80=99s, then we should have a model that c= an >> accommodate that as well. That=E2=80=99s why the charter calls out metho= ds for the >> AS and RS to communicate what the token=E2=80=99s good for. I think the = basis of >> those methods is going to start with a common token model, and likely >> incorporate into things like token formats and introspection-style token >> APIs. >> >> =E2=80=94 Justin >> >> On Jun 22, 2020, at 3:55 AM, Denis wrote: >> >> Hello Justin, >> >> A few comments between the lines. >> >> One of the most important aspects to GNAP is going to be an ability to >> address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do = without significant >> gymnastics. So with that, I wanted to bring back a use case discussion t= hat >> originally came up while we were talking about the possibility of multip= le >> access tokens, a few months back. I don=E2=80=99t know if this concept h= as a >> regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access t= okens=E2=80=9D until we >> come up with something better =E2=80=94 assuming we decide this is worth= while. >> >> I don't understand what may mean "directed access tokens=E2=80=9D but I >> understand what means "multiple access tokens". >> When speaking of "multiple access tokens", these access tokens may come >> from one or more ASs. >> >> In OAuth, the client=E2=80=99s supposed to always know where to send its= access >> token, and that knowledge is completely outside the protocol. This makes= a >> lot of sense for many (if not most) deployments, as OAuth is really ther= e >> to enable the API access that the client already knows about. >> >> But we=E2=80=99re now in a world where a client could be talking to a ge= neric API >> that could be deployed at a number of different places, or a cloud >> deployment that the AS wants to be able to dispatch the client to. >> >> As soon the AS is placed (again) at the centre of the model, the AS will >> have the ability to act as "Big Brother". >> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP >> should take care of them. >> >> In order to do this, the AS needs to be able to communicate to the clien= t >> not only the token information (and any related key and presentation >> information), but also a set of *directions* about what that specific >> token is good for. This needs to be information outside the token itself= , >> since I believe we want to keep OAuth 2=E2=80=99s feature of having the = token be >> opaque to the client. Note: while we could map all of these to different >> resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlanc= e) >> on the request side, this isn=E2=80=99t enough to tell the client what t= o do with >> the token *if it doesn=E2=80=99t know already*. >> >> I know of two use cases already in the wild, where people are addressing >> things using a mix of existing standards and some proprietary extensions= to >> address things within their silos. I=E2=80=99ll try to summarize here, b= ut I know >> the folks I=E2=80=99ve been talking to about this are also on the list s= o hopefully >> they can chime in with more detail or any corrections for something I=E2= =80=99ve >> missed. >> >> (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2= =80=99t know >> where it=E2=80=99s hosted. Everything is in a single security domain con= trolled by >> the AS, >> >> Speaking of "multiple access tokens" is in contradiction with single >> security domain "controlled" by an AS. >> A user may need to demonstrate some of his identity attributes granted >> e.g. by his bank but may also >> need to demonstrate one or more diplomas granted by one or more >> universities. The bank cannot be >> the "primary issuer" of a university diploma. It should not be either a >> "secondary issuer", because >> the bank does not "*need to know"* what are the diplomas of the user. >> >> but the AS needs to decide at runtime which specific instance of the API >> to direct the client to. Since things are closely tied together, the cli= ent >> just needs to effectively known an identifier for the RS, and this is >> currently implemented as a URI. Once the client has that identifier, it >> knows how to dispatch that token to that instance of the RS. >> >> There is no good reason why the AS should be involved in that step. >> OAuth 2.0 is/was implicitly mandating a strong relationship between ASs >> and RSs which makes it non scalable. >> GNAP should be based on a simple trust relationship : a given RS trusts >> some ASs for access tokens that contains some types of attributes. >> An AS should not need to know in advance (or even at the time of an >> access token request) the RSs that are trusting it. >> >> A client could first talk to a "global service provider" which has the >> knowledge of the different RSs affiliated to it. >> >> (2) The client knows what kind of thing it=E2=80=99s looking for, but do= esn=E2=80=99t >> know who to ask it from. >> >> Once again, the client could first talk to a "global service provider" >> which has the knowledge of the different RSs affiliated to it. >> >> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, a= nd the AS needs >> to dispatch to different resources depending on which user logged in (an= d >> possibly what the user consented to). To make things more concrete, the >> client needs to get driver=E2=80=99s license information, but doesn=E2= =80=99t know ahead of >> time which of the many state/provincial bureaus to call to get that >> information because it doesn=E2=80=99t know yet who the user is. >> >> When a user has a driving license, he knows its issuer. The user can the= n >> provide some hint to the client. >> >> The AS will know who the user is once they log in and approve things, an= d >> so it can direct the client to call the correct RS. Since this is a >> relatively simple API with a pre-negotiated cross-domain trust, the AS >> returns a URL that the client presents the token at. >> >> A single AS should not be aware of all the attributes a user has. >> >> >> As far as I know, in both of these cases, the token is only good for tha= t >> API and not others =E2=80=94 but more on that later. >> >> A simple thing to do is just give back a URL with the access token, whic= h >> tells the client where to go. >> >> { >> =E2=80=9Caccess_token=E2=80=9D: { >> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D, >> =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo" >> } >> } >> >> This is good for some kinds of APIs, but it=E2=80=99s limiting because n= ot all >> APIs dispatch based on the URL. An AS might want to divvy up access toke= ns >> to an API that=E2=80=99s keyed on headers, or verbs, or any number of th= ings. And >> it doesn=E2=80=99t tell us immediately what to do about non-exact URL ma= tches. Can >> the client add query parameters and still use the token? What about path >> segments? I like that this simple approach addresses some common >> deployments that we already see today (see above), it=E2=80=99s not univ= ersal. Do >> we want or need a universal description language for directing where tok= ens >> go? >> >> This also opens up a whole new set of security questions. If the AS can >> now direct the client where to use the token, could a rogue AS convince = a >> legit client to use a stolen token at the wrong RS? And what if the clie= nt >> ignores the directions from the AS entirely? Could this open up new aven= ues >> of attack? >> >> This is just the start, too. Things get even more complex if the client >> can ask for multiple different kinds of resources at once. What if the A= S >> decides that the client needs a hyper-focused directed token for one par= t >> of the API, but can use a general token for other stuff? Can it signal t= hat >> to the client? And if it can, does that mean that all clients need to be >> prepared for that kind of thing? >> >> I firmly believe that whatever we build in GNAP, we need to optimize for >> the overwhelmingly common use case of a client getting a single access >> token to call APIs that it already knows about. Anything we add on top o= f >> that really can=E2=80=99t get in the way of this, because if it does, th= ere=E2=80=99s very >> small chance that people will try to use this for everyday things. Keep = the >> simple things simple, and the complex things possible, after all. >> >> I=E2=80=99m really looking forward to hearing what the community thinks = about >> these use cases, and hopefully the people I=E2=80=99ve chatted with offl= ine about >> this can join the conversation and provide more light than I was able to= . >> >> The two use cases which are considered above are: >> >> (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2= =80=99t know >> where it=E2=80=99s hosted. >> (2) The client knows what kind of thing it=E2=80=99s looking for, but do= esn=E2=80=99t >> know who to ask it from. >> >> That does not mean in any way that these two use cases should be solved >> by placing the AS at the centre of the solution. >> >> Denis >> >> >> =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 >> > > This communication, including any attachments, is confidential. If you ar= e not the intended recipient, you should not read it - please contact me im= mediately, destroy it, and do not copy or use any part of this communicatio= n or disclose anything about it. Thank you. Please note that this communica= tion does not designate an information system for the purposes of the Elect= ronic Transactions Act 2002. > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --000000000000ac56fa05a8f54899 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think Tobias & I have converged to a single request = for a "bound" token.
I really don't care much what it is = called. I do have some input on the continents of the claims.
Peace ..tom


On Thu, Jun 25, 2020 at 6:08 PM Tobias Looker <tobias.looker@mattr.g= lobal> wrote:
I find this feature interesting and think it could be an = important=C2=A0pattern going=C2=A0forward to enable an AS to be able to des= cribe the utility of a token to the client, however as already pointed out = in the thread I think there is some potential hidden complexity that would = need to be ironed out such that it does not make the simple things complica= ted.

Justin, do you see this feature as something the cl= ient has to explicitly request, i.e "please give me access and instruc= tions on how to use my access" or rather that the AS would just return= this information in conjunction with the access token if it had it availab= le?

> This is just the start, too. Things get e= ven more complex if the client can ask for multiple different kinds of reso= urces at once. What if the AS decides that the client needs a hyper-focused= directed token for one part of the API, but can use a general token for ot= her stuff? Can it signal that to the client? And if it can, does that mean = that all clients need to be prepared for that kind of thing?

=
Would a potential default be that if a client did for any reason= not support processing the additional information returned with the access= _token, just to ignore it? I think in the spirit of keeping the simple thin= gs simple, this potentially makes sense?

> here= are some worked out samples of this:
Peace ..tom

As one of the authors of those mentioned drafts, I am int= erested in discussing that, but perhaps on a seperate thread? As at least= =C2=A0the bound assertion spec is=C2=A0primarily=C2=A0concerned with bindin= g mechanisms for the artifacts produced from an authorization flow (specifi= cally identity claims), whereas I think directed access tokens is just more= generally talking about whether GNAP should support an AS conveying how to= use an access_token it produces during a flow with a client.

Tha= nks,
3D"Mattr=C2=A0
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
=
3D"Mattr3D"Mattr3D"Mattr

This = communication, including any attachments, is confidential. If you are not t= he intended recipient, you should not read it - please contact me immediate= ly, destroy it, and do not copy or use any part of this communication or di= sclose anything about it. Thank you. Please note that this communication do= es not designate an information system for the purposes of the Electronic T= ransactions Act 2002.


On Wed, Jun 24= , 2020 at 10:14 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Justin, I fear we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I am getting tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it=E2=80=99s g= oing to be overwhelmingly common that a given RS is going to trust exactly one AS
that it knows about ahead of time". Such an architecture would have exactly the same limitations as OAuth 2.0. and would not be scalable.

Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions.
For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believe that we have an agreement at this time on what these trust relationships are.

You are also using the following wording: "methods for the AS and RS to communicate what the token=E2=80=99s good for".
With such a paradigm, it would be impossible to protect the user'= s privacy.

A key question is : Will GNAP take care of the user's privacy or will GNAP prevent to take care of the user's privacy ?

About "the ability for the client to get several access tokens to get different resources from one request" is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform
on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).

First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases.

When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS.
His "consent and choice" should then be obtained by the first RS and, when the user agrees, the client should then ask an access token
to one of the ASs trusted by the second RS in order to perform the subsequent operation.=C2=A0

Denis

PS.=C2=A0 In an email sent on June 23 you wrote: " I think an on-device AS is an important use case".= =C2=A0 I am sorry, but I don't understand.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 However, I do understand what &q= uot;a server-based AS" is.


=20 Denis, thanks for the great comments. I think that your trust model is pretty different from what I=E2=80=99d laid out initially, a= nd while it=E2=80=99s an interesting and important one, it is not what I meant by =E2=80=9Cmultiple access tokens=E2=80=9D in my discussion be= low. I think that might be the cause of some disconnect here, but that doesn=E2=80= =99t mean it=E2=80=99s out of reach for what the WG is after.

When I refer to multiple access tokens, and what the charter calls out as multiple access tokens, is the ability for the client to get several access tokens to get different resources from one request. I personally see this as an optimization of a specific set of use cases, some of which I discussed in my original email. There are others, I=E2=80=99m sure,= but all the ones I=E2=80=99ve seen are around the client needing to get several different kinds of access through an AS.=C2=A0

I think it=E2=80=99s going to be overwhelmingly common that a given RS is going to trust exactly one AS that it knows about ahead of time. But for RS=E2=80=99s that can trust multiple AS=E2=80=99s, then we should have a model that can accommodate th= at as well. That=E2=80=99s why the charter calls out methods for the AS= and RS to communicate what the token=E2=80=99s good for. I think the = basis of those methods is going to start with a common token model, and likely incorporate into things like token formats and introspection-style token APIs.=C2=A0

=C2=A0=E2=80=94 Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the lines.

One of the most i= mportant aspects to GNAP is going to be an ability to address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do witho= ut significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don=E2=80=99= t know if this concept has a regular term, so I=E2=80=99m g= oing to call it =E2=80=9Cdirected access tokens=E2=80=9D until= we come up with something better =E2=80=94 assuming we decide this i= s worthwhile.=C2=A0

I don't understand what may mean "directed access tokens=E2= =80=9D but I understand what means "multiple access tokens"= ;.=C2=A0
When speaking of "multiple access tokens", thes= e access tokens may come from one or more ASs.

In OAuth, the client=E2=80=99s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we=E2=80=99re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.=C2=A0

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".<= br> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of=C2=A0di= rections=C2=A0about what that specific token is good for. This needs to be information outside the token itself, since I=C2=A0believe we want to keep OAuth 2=E2=80=99s featur= e of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t enough to tell the client what to do with= the token=C2=A0if it doesn=E2=80=99t know a= lready.=C2=A0

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I=E2=80=99ll try to summarize here, but I know the folk= s I=E2=80=99ve been talking to about this are also on the= list so hopefully they can chime in with more detail or any corrections for something I=E2=80=99ve missed.=C2= =A0

(1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s= hosted. Everything is in a single security domain controlled by the AS,=C2=A0

Speaking of "multiple access tokens" is in contradiction wi= th single security domain "controlled" by an AS.=C2=A0
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also=C2= =A0
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be=C2=A0<= /span>
the "primary issuer" of a university diploma. I= t should not be either a "secondary issuer", beca= use=C2=A0
the bank does not "need to know"= =C2=A0what are the diplomas of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved in that step.= =C2=A0
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" which= has the knowledge of the different RSs affiliated to it.=C2=A0

(2) The client knows what kind of thing it=E2=80=99s looking for, but doesn=E2=80=99t know who = to ask it from.=C2=A0

Once again, the client could first talk to a "global service provide= r" which has the knowledge of the different RSs affiliated to it.=C2=A0

There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver=E2=80=99s license information, but doesn=E2=80= =99t know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn=E2=80= =99t know yet who the user is.=C2=A0

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at.=C2=A0

=C2=A0A single AS should not be aware of all the attributes a user has.=C2=A0


As far as I know, in both of these cases, the token is only good for that API and not others =E2=80=94 but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go.=C2=A0

{
=E2=80= =9Caccess_token=E2=80=9D: {
=E2= =80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
=E2= =80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
}
}

This is good for some kinds of APIs, but it=E2=80=99s limiting because not all APIs dispatch bas= ed on the URL. An AS might want to divvy up access tokens to an API that=E2=80=99s keyed on headers, or verbs, or= any number of things. And it doesn=E2=80=99t tell us immedi= ately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it=E2=80=99s not univers= al. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can=E2=80=99t get= in the way of this, because if it does, there=E2=80=99s ve= ry small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I=E2=80=99m really looking forward to hearing what the community thinks about these use cases, and hopefully the people I=E2=80=99ve chatted with offline = about this can join the conversation and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s= hosted.
(2) The client knows what kind of thing it=E2=80=99s lo= oking for, but doesn=E2=80=99t know who to ask it from.= =C2=A0

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Denis


=C2=A0=E2=80=94 Justin


--=C2= =A0
Txauth mail= ing list
Txauth@ietf= ..org
https://www.ietf.org/mailman/listinfo/txauth


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

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.
-- <= br> Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--000000000000ac56fa05a8f54899-- From nobody Fri Jun 26 06:23:29 2020 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 8C99F3A0C36 for ; Fri, 26 Jun 2020 06:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 5hz_YsEfmCmC for ; Fri, 26 Jun 2020 06:23:24 -0700 (PDT) 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 626CA3A0BC8 for ; Fri, 26 Jun 2020 06:23:23 -0700 (PDT) Received: from [192.168.1.14] (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 05QDNGtN010088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Jun 2020 09:23:17 -0400 From: Justin Richer Message-Id: <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_EA17D934-BF2E-464D-BCC6-A8EDF1C55F7A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 26 Jun 2020 09:23:15 -0400 In-Reply-To: Cc: Denis , txauth@ietf.org To: Tobias Looker References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 26 Jun 2020 13:23:29 -0000 --Apple-Mail=_EA17D934-BF2E-464D-BCC6-A8EDF1C55F7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jun 25, 2020, at 9:07 PM, Tobias Looker = wrote: >=20 > I find this feature interesting and think it could be an important = pattern going forward to enable an AS to be able to describe the utility = of a token to the client, however as already pointed out in the thread I = think there is some potential hidden complexity that would need to be = ironed out such that it does not make the simple things complicated. >=20 > Justin, do you see this feature as something the client has to = explicitly request, i.e "please give me access and instructions on how = to use my access" or rather that the AS would just return this = information in conjunction with the access token if it had it available? >=20 This is something that I=E2=80=99d brought up as a possibility on the = previous thread =E2=80=94 something like a flag the client would set. = This would be especially important if the AS wants to return multiple = access tokens but the client requested 1, or the client requested N and = the AS wants to return M in response. Basically any time there=E2=80=99s = a mismatch, that=E2=80=99s extra complexity on the client that I really = don=E2=80=99t think we want to be universal. A flag to turn that kind of = direction and splitting on would be a potential start. But there are = potential snags here too, and it comes down to how you manage the = defaults... > > This is just the start, too. Things get even more complex if the = client can ask for multiple different kinds of resources at once. What = if the AS decides that the client needs a hyper-focused directed token = for one part of the API, but can use a general token for other stuff? = Can it signal that to the client? And if it can, does that mean that all = clients need to be prepared for that kind of thing? >=20 > Would a potential default be that if a client did for any reason not = support processing the additional information returned with the = access_token, just to ignore it? I think in the spirit of keeping the = simple things simple, this potentially makes sense? That=E2=80=99s the real trick, if you ask me. It has to be :safe: for a = client to ignore this information. Which means the AS can=E2=80=99t rely = on the client =E2=80=9Cdoing the right thing=E2=80=9D with the = information in the =E2=80=9Ctoken directions=E2=80=9D portion of the = response. Even setting aside the advanced and related =E2=80=9Csplit = tokens=E2=80=9D idea above, we need to make sure that an AS/RS setup is = built such that if the AS tells a client =E2=80=9Conly do X with your = token=E2=80=9D and the client does =E2=80=9CY=E2=80=9D, then there are = other protections and practices in place to prevent things from going = haywire if the client does =E2=80=9CY=E2=80=9D either by accident or = through ignorance.=20 If OAuth 2 has taught us anything, it=E2=80=99s that client applications = are going to be the laziest participants in the security model. And that = makes sense, really =E2=80=94 security isn=E2=80=99t what the client = apps are trying to do, they=E2=80=99re trying to use the RS to do = something. So we need to make sure that whatever system we design will = fail on the safe side as much as possible, and keep things simple for = the client. >=20 > > here are some worked out samples of this: > https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token = > https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ = > Peace ..tom >=20 > As one of the authors of those mentioned drafts, I am interested in = discussing that, but perhaps on a seperate thread? As at least the bound = assertion spec is primarily concerned with binding mechanisms for the = artifacts produced from an authorization flow (specifically identity = claims), whereas I think directed access tokens is just more generally = talking about whether GNAP should support an AS conveying how to use an = access_token it produces during a flow with a client. >=20 I think that these are separate issues as well. =E2=80=94 Justin > Thanks, > =09 > Tobias Looker > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > = = = > This communication, including any attachments, is confidential. If you = are not the intended recipient, you should not read it - please contact = me immediately, destroy it, and do not copy or use any part of this = communication or disclose anything about it. Thank you. Please note that = this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. >=20 >=20 > On Wed, Jun 24, 2020 at 10:14 PM Denis > wrote: > Justin, I fear we are still far away from an agreement about what this = BoF should do. >=20 > Tom Jones is saying " I am getting tired of the whack-a-mole approach = ..." >=20 > I don't agree with you when you write: "I think it=E2=80=99s going to = be overwhelmingly common that a given RS is going to trust exactly one = AS=20 > that it knows about ahead of time". Such an architecture would have = exactly the same limitations as OAuth 2.0. and would not be scalable. >=20 > Before we start, we should have a clear view of the whole picture = rather than starting from one scenario and expanding it in many = different directions. > For building an architecture, a pre-requirement is to define ALL the = trust relationships. I don't believe that we have an agreement at this = time on what=20 > these trust relationships are. >=20 > You are also using the following wording: "methods for the AS and RS = to communicate what the token=E2=80=99s good for".=20 > With such a paradigm, it would be impossible to protect the user's = privacy.=20 >=20 > A key question is : Will GNAP take care of the user's privacy or will = GNAP prevent to take care of the user's privacy ? >=20 > About "the ability for the client to get several access tokens to get = different resources from one request" is indeed a complex case. >=20 > No one (including ASs) is able to predict in advance which access = tokens will be needed, since they depend upon the kind of operation(s)=20= > the client will be willing to perform. For privacy reasons, ASs should = be kept ignorant of all the operations that a client is going to perform=20= > on one or more resource servers. I believe that every effort should be = made to avoid the AS to be in a position to be able to trace the = operations=20 > performed by its clients on various RSs. >=20 > To handle the complex case you envision, the full workflow of = operations needs to be considered with a detailed focus on the time=20 > at which the user's consent and choice happens (consent and choice is = the first privacy principle from ISO 29100). >=20 > First of all, an access token could be targeted to a service rather = than to a server. This would already solve many cases. >=20 > When a RS needs to call another RS (which does not support the same = service) then the client should be informed by the first RS. > His "consent and choice" should then be obtained by the first RS and, = when the user agrees, the client should then ask an access token=20 > to one of the ASs trusted by the second RS in order to perform the = subsequent operation. =20 >=20 > Denis >=20 > PS. In an email sent on June 23 you wrote: " I think an on-device AS = is an important use case". I am sorry, but I don't understand. > However, I do understand what "a server-based AS" is. >=20 >=20 >> Denis, thanks for the great comments. I think that your trust model = is pretty different from what I=E2=80=99d laid out initially, and while = it=E2=80=99s an interesting and important one, it is not what I meant by = =E2=80=9Cmultiple access tokens=E2=80=9D in my discussion below. I think = that might be the cause of some disconnect here, but that doesn=E2=80=99t = mean it=E2=80=99s out of reach for what the WG is after. >>=20 >> When I refer to multiple access tokens, and what the charter calls = out as multiple access tokens, is the ability for the client to get = several access tokens to get different resources from one request. I = personally see this as an optimization of a specific set of use cases, = some of which I discussed in my original email. There are others, I=E2=80=99= m sure, but all the ones I=E2=80=99ve seen are around the client needing = to get several different kinds of access through an AS.=20 >>=20 >> I think it=E2=80=99s going to be overwhelmingly common that a given = RS is going to trust exactly one AS that it knows about ahead of time. = But for RS=E2=80=99s that can trust multiple AS=E2=80=99s, then we = should have a model that can accommodate that as well. That=E2=80=99s = why the charter calls out methods for the AS and RS to communicate what = the token=E2=80=99s good for. I think the basis of those methods is = going to start with a common token model, and likely incorporate into = things like token formats and introspection-style token APIs.=20 >>=20 >> =E2=80=94 Justin >>=20 >>> On Jun 22, 2020, at 3:55 AM, Denis > wrote: >>>=20 >>> Hello Justin, >>>=20 >>> A few comments between the lines. >>>=20 >>>> One of the most important aspects to GNAP is going to be an ability = to address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t = do without significant gymnastics. So with that, I wanted to bring back = a use case discussion that originally came up while we were talking = about the possibility of multiple access tokens, a few months back. I = don=E2=80=99t know if this concept has a regular term, so I=E2=80=99m = going to call it =E2=80=9Cdirected access tokens=E2=80=9D until we come = up with something better =E2=80=94 assuming we decide this is = worthwhile.=20 >>> I don't understand what may mean "directed access tokens=E2=80=9D = but I understand what means "multiple access tokens".=20 >>> When speaking of "multiple access tokens", these access tokens may = come from one or more ASs. >>>=20 >>>> In OAuth, the client=E2=80=99s supposed to always know where to = send its access token, and that knowledge is completely outside the = protocol. This makes a lot of sense for many (if not most) deployments, = as OAuth is really there to enable the API access that the client = already knows about. >>>>=20 >>>> But we=E2=80=99re now in a world where a client could be talking to = a generic API that could be deployed at a number of different places, or = a cloud deployment that the AS wants to be able to dispatch the client = to.=20 >>> As soon the AS is placed (again) at the centre of the model, the AS = will have the ability to act as "Big Brother". >>> OAuth 2.0 has not taken care of privacy issues. On the contrary, = GNAP should take care of them. >>>=20 >>>> In order to do this, the AS needs to be able to communicate to the = client not only the token information (and any related key and = presentation information), but also a set of directions about what that = specific token is good for. This needs to be information outside the = token itself, since I believe we want to keep OAuth 2=E2=80=99s feature = of having the token be opaque to the client. Note: while we could map = all of these to different resource requests (in XYZ parlance) or scopes = (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t = enough to tell the client what to do with the token if it doesn=E2=80=99t = know already.=20 >>>>=20 >>>> I know of two use cases already in the wild, where people are = addressing things using a mix of existing standards and some proprietary = extensions to address things within their silos. I=E2=80=99ll try to = summarize here, but I know the folks I=E2=80=99ve been talking to about = this are also on the list so hopefully they can chime in with more = detail or any corrections for something I=E2=80=99ve missed.=20 >>>>=20 >>>> (1) The client knows what resource it=E2=80=99s calling, but it = doesn=E2=80=99t know where it=E2=80=99s hosted. Everything is in a = single security domain controlled by the AS,=20 >>> Speaking of "multiple access tokens" is in contradiction with single = security domain "controlled" by an AS.=20 >>> A user may need to demonstrate some of his identity attributes = granted e.g. by his bank but may also=20 >>> need to demonstrate one or more diplomas granted by one or more = universities. The bank cannot be=20 >>> the "primary issuer" of a university diploma. It should not be = either a "secondary issuer", because=20 >>> the bank does not "need to know" what are the diplomas of the user. >>>=20 >>>> but the AS needs to decide at runtime which specific instance of = the API to direct the client to. Since things are closely tied together, = the client just needs to effectively known an identifier for the RS, and = this is currently implemented as a URI. Once the client has that = identifier, it knows how to dispatch that token to that instance of the = RS. >>> There is no good reason why the AS should be involved in that step.=20= >>> OAuth 2.0 is/was implicitly mandating a strong relationship between = ASs and RSs which makes it non scalable. >>> GNAP should be based on a simple trust relationship : a given RS = trusts some ASs for access tokens that contains some types of = attributes. >>> An AS should not need to know in advance (or even at the time of an = access token request) the RSs that are trusting it. >>>=20 >>> A client could first talk to a "global service provider" which has = the knowledge of the different RSs affiliated to it.=20 >>>=20 >>>> (2) The client knows what kind of thing it=E2=80=99s looking for, = but doesn=E2=80=99t know who to ask it from.=20 >>> Once again, the client could first talk to a "global service = provider" which has the knowledge of the different RSs affiliated to it.=20= >>>=20 >>>> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the = AS, and the AS needs to dispatch to different resources depending on = which user logged in (and possibly what the user consented to). To make = things more concrete, the client needs to get driver=E2=80=99s license = information, but doesn=E2=80=99t know ahead of time which of the many = state/provincial bureaus to call to get that information because it = doesn=E2=80=99t know yet who the user is.=20 >>> When a user has a driving license, he knows its issuer. The user can = then provide some hint to the client. >>>=20 >>>> The AS will know who the user is once they log in and approve = things, and so it can direct the client to call the correct RS. Since = this is a relatively simple API with a pre-negotiated cross-domain = trust, the AS returns a URL that the client presents the token at.=20 >>> A single AS should not be aware of all the attributes a user has.=20= >>>=20 >>>>=20 >>>> As far as I know, in both of these cases, the token is only good = for that API and not others =E2=80=94 but more on that later. >>>>=20 >>>> A simple thing to do is just give back a URL with the access token, = which tells the client where to go.=20 >>>>=20 >>>> { >>>> =E2=80=9Caccess_token=E2=80=9D: { >>>> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80= =9D, >>>> =E2=80=9Cresource_uri=E2=80=9D: = =E2=80=9Chttps://example/foo " >>>> } >>>> } >>>>=20 >>>> This is good for some kinds of APIs, but it=E2=80=99s limiting = because not all APIs dispatch based on the URL. An AS might want to = divvy up access tokens to an API that=E2=80=99s keyed on headers, or = verbs, or any number of things. And it doesn=E2=80=99t tell us = immediately what to do about non-exact URL matches. Can the client add = query parameters and still use the token? What about path segments? I = like that this simple approach addresses some common deployments that we = already see today (see above), it=E2=80=99s not universal. Do we want or = need a universal description language for directing where tokens go? >>>>=20 >>>> This also opens up a whole new set of security questions. If the AS = can now direct the client where to use the token, could a rogue AS = convince a legit client to use a stolen token at the wrong RS? And what = if the client ignores the directions from the AS entirely? Could this = open up new avenues of attack? >>>>=20 >>>> This is just the start, too. Things get even more complex if the = client can ask for multiple different kinds of resources at once. What = if the AS decides that the client needs a hyper-focused directed token = for one part of the API, but can use a general token for other stuff? = Can it signal that to the client? And if it can, does that mean that all = clients need to be prepared for that kind of thing? >>>>=20 >>>> I firmly believe that whatever we build in GNAP, we need to = optimize for the overwhelmingly common use case of a client getting a = single access token to call APIs that it already knows about. Anything = we add on top of that really can=E2=80=99t get in the way of this, = because if it does, there=E2=80=99s very small chance that people will = try to use this for everyday things. Keep the simple things simple, and = the complex things possible, after all. >>>>=20 >>>> I=E2=80=99m really looking forward to hearing what the community = thinks about these use cases, and hopefully the people I=E2=80=99ve = chatted with offline about this can join the conversation and provide = more light than I was able to. >>> The two use cases which are considered above are: >>>=20 >>> (1) The client knows what resource it=E2=80=99s calling, but it = doesn=E2=80=99t know where it=E2=80=99s hosted. >>> (2) The client knows what kind of thing it=E2=80=99s looking for, = but doesn=E2=80=99t know who to ask it from.=20 >>>=20 >>> That does not mean in any way that these two use cases should be = solved by placing the AS at the centre of the solution. >>>=20 >>> Denis >>>=20 >>>>=20 >>>> =E2=80=94 Justin >>>>=20 >>>>=20 >>>=20 >>> --=20 >>> Txauth mailing list >>> Txauth@ietf.org >>> https://www.ietf.org/mailman/listinfo/txauth = >=20 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = >=20 > This communication, including any attachments, is confidential. If you = are not the intended recipient, you should not read it - please contact = me immediately, destroy it, and do not copy or use any part of this = communication or disclose anything about it. Thank you. Please note that = this communication does not designate an information system for the = purposes of the Electronic Transactions Act 2002. --Apple-Mail=_EA17D934-BF2E-464D-BCC6-A8EDF1C55F7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jun 25, 2020, at 9:07 PM, Tobias Looker <tobias.looker@mattr.global> wrote:

I find this feature interesting = and think it could be an important pattern going forward to = enable an AS to be able to describe the utility of a token to the = client, however as already pointed out in the thread I think there is = some potential hidden complexity that would need to be ironed out such = that it does not make the simple things complicated.

Justin, do you see this feature as = something the client has to explicitly request, i.e "please give me = access and instructions on how to use my access" or rather that the AS = would just return this information in conjunction with the access token = if it had it available?


This is something that I=E2=80=99d brought up as a = possibility on the previous thread =E2=80=94 something like a flag the = client would set. This would be especially important if the AS wants to = return multiple access tokens but the client requested 1, or the client = requested N and the AS wants to return M in response. Basically any time = there=E2=80=99s a mismatch, that=E2=80=99s extra complexity on the = client that I really don=E2=80=99t think we want to be universal. A flag = to turn that kind of direction and splitting on would be a potential = start. But there are potential snags here too, and it comes down to how = you manage the defaults...

> This is just the start, too. Things get even more = complex if the client can ask for multiple different kinds of resources = at once. What if the AS decides that the client needs a hyper-focused = directed token for one part of the API, but can use a general token for = other stuff? Can it signal that to the client? And if it can, does that = mean that all clients need to be prepared for that kind of = thing?

Would a = potential default be that if a client did for any reason not support = processing the additional information returned with the access_token, = just to ignore it? I think in the spirit of keeping the simple things = simple, this potentially makes = sense?

That=E2=80=99s the real trick, if you ask me. It = has to be :safe: for a client to ignore this information. Which means = the AS can=E2=80=99t rely on the client =E2=80=9Cdoing the right = thing=E2=80=9D with the information in the =E2=80=9Ctoken directions=E2=80= =9D portion of the response. Even setting aside the advanced and related = =E2=80=9Csplit tokens=E2=80=9D idea above, we need to make sure that an = AS/RS setup is built such that if the AS tells a client =E2=80=9Conly do = X with your token=E2=80=9D and the client does =E2=80=9CY=E2=80=9D, then = there are other protections and practices in place to prevent things = from going haywire if the client does =E2=80=9CY=E2=80=9D either by = accident or through ignorance. 

If OAuth 2 has taught us anything, it=E2=80=99s = that client applications are going to be the laziest participants in the = security model. And that makes sense, really =E2=80=94 security isn=E2=80=99= t what the client apps are trying to do, they=E2=80=99re trying to use = the RS to do something. So we need to make sure that whatever system we = design will fail on the safe side as much as possible, and keep things = simple for the client.

> here are some worked out samples = of this:
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
https://mattrglobal.github.io/oidc-client-bound-assertions-spec= /
Peace ..tom

As one of the authors of those = mentioned drafts, I am interested in discussing that, but perhaps on a = seperate thread? As at least the bound assertion spec = is primarily concerned with binding mechanisms for the = artifacts produced from an authorization flow (specifically identity = claims), whereas I think directed access tokens is just more generally = talking about whether GNAP should support an AS conveying how to use an = access_token it produces during a flow with a = client.


I= think that these are separate issues as well.

 =E2=80=94 Justin

Thanks,
3D"Mattr 
Tobias Looker
Mattr
+64 = (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr3D"Mattr3D"Mattr3D"Mattr

This communication, including any attachments, is = confidential. If you are not the intended recipient, you should not read = it - please contact me immediately, destroy it, and do not copy or use = any part of this communication or disclose anything about it. Thank you. = Please note that this communication does not designate an information = system for the purposes of the Electronic Transactions Act = 2002.


On Wed, Jun 24, 2020 at 10:14 PM Denis = <denis.ietf@free.fr> wrote:
=20 =20 =20
Justin, I fear we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I am getting tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it=E2=80=99s going = to be overwhelmingly common that a given RS is going to trust exactly one AS
that it knows about ahead of time". Such an architecture would have exactly the same limitations as OAuth 2.0. and would not be scalable.

Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions.
For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believe that we have an agreement at this time on what
these trust relationships are.

You are also using the following wording: "methods for the AS and RS to communicate what the token=E2=80=99s good for".
With such a paradigm, it would be impossible to protect the user's privacy.

A key question is : Will GNAP take care of the user's privacy or will GNAP prevent to = take care of the user's privacy ?

About "the ability for the client to get several access tokens to get different resources from one request" is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform
on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens = (consent and choice is the first privacy principle from ISO = 29100).

First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases.

When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS.
His "consent and choice" should then be obtained by the first RS and, when the user agrees, the client should then ask an access token
to one of the ASs trusted by the second RS in order to perform the subsequent operation. 

Denis

PS.  In an email sent on June 23 you wrote: " I think an on-device AS is an important use case".  = I am sorry, but I don't understand.
       However, I do understand what = "a server-based AS" is.


=20 Denis, thanks for the great comments. I think that your trust model is pretty different from what I=E2=80=99d laid out = initially, and while it=E2=80=99s an interesting and important one, it is not = what I meant by =E2=80=9Cmultiple access tokens=E2=80=9D in my discussion = below. I think that might be the cause of some disconnect here, but that = doesn=E2=80=99t mean it=E2=80=99s out of reach for what the WG is after.

When I refer to multiple access tokens, and what = the charter calls out as multiple access tokens, is the ability for the client to get several access tokens to get different resources from one request. I personally see this as an optimization of a specific set of use cases, some of which I discussed in my original email. There are others, I=E2=80=99m = sure, but all the ones I=E2=80=99ve seen are around the client needing to = get several different kinds of access through an AS. 

I think it=E2=80=99s going to be overwhelmingly = common that a given RS is going to trust exactly one AS that it knows about ahead of time. But for RS=E2=80=99s that can trust = multiple AS=E2=80=99s, then we should have a model that can accommodate = that as well. That=E2=80=99s why the charter calls out methods for the = AS and RS to communicate what the token=E2=80=99s good for. I think = the basis of those methods is going to start with a common token model, and likely incorporate into things like token formats and introspection-style token APIs. 

 =E2=80=94 Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the lines.

One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do = without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don=E2=80=99= t know if this concept has a regular term, so I=E2=80=99m = going to call it =E2=80=9Cdirected access tokens=E2=80=9D = until we come up with something better =E2=80=94 assuming we decide = this is worthwhile. 
=

I don't understand what may mean "directed access tokens=E2=80=9D= but I understand what means "multiple access tokens". 
When speaking of "multiple access tokens", these access tokens may come from one or more ASs.

In OAuth, the client=E2=80=99s = supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows = about.

But we=E2=80=99re now in a world where = a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to. 

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to = be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of directions about what that specific token is good for. This needs to be information outside the token itself, since I believe we want to keep OAuth 2=E2=80=99s = feature of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t enough to tell the client what to do = with the token if = it doesn=E2=80=99t know already. 

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I=E2=80=99ll try to summarize here, but I know the = folks I=E2=80=99ve been talking to about this are also on = the list so hopefully they can chime in with more detail or any corrections for something I=E2=80=99ve = missed. 

(1) The client knows what resource = it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99= s hosted. Everything is in a single security domain controlled by the AS, 

Speaking of "multiple access tokens" is in contradiction with single security domain "controlled" by an AS. 
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also 
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be 
the "primary issuer" of a university diploma. It should not be either a "secondary issuer", = because 
the bank does not "need to = know" what are the diplomas of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved in that = step. 
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to = it. 

(2) The client knows what kind of = thing it=E2=80=99s looking for, but doesn=E2=80=99t know = who to ask it from. 

Once again, the client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it. 

There=E2=80=99s a cross-domain trust = that=E2=80=99s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver=E2=80=99s license information, but doesn=E2=80=99= t know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn=E2=80= =99t know yet who the user is. 

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at. 

 A single AS should not be aware of all the attributes a user = has. 


As far as I know, in both of these cases, the token is only good for that API and not others =E2=80=94 but more on that later.

A simple thing to do is just give back = a URL with the access token, which tells the client where to go. 

{
=E2=80=9Caccess_token=E2=80=9D: {
=E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
=E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
}
}

This is good for some kinds of APIs, = but it=E2=80=99s limiting because not all APIs dispatch = based on the URL. An AS might want to divvy up access tokens to an API that=E2=80=99s keyed on headers, or verbs, = or any number of things. And it doesn=E2=80=99t tell us = immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it=E2=80=99s not = universal. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things = get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we = build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can=E2=80=99t = get in the way of this, because if it does, there=E2=80=99s = very small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I=E2=80=99m really looking forward to = hearing what the community thinks about these use cases, and hopefully the people I=E2=80=99ve chatted with = offline about this can join the conversation and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what = resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99= s hosted.
(2) The client knows what kind of thing it=E2=80=99s = looking for, but doesn=E2=80=99t know who to ask it = from. 

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Denis


 =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
= 

This communication, including any attachments, is =
confidential. If you are not the intended recipient, you should not read =
it - please contact me immediately, destroy it, and do not copy or use =
any part of this communication or disclose anything about it. Thank you. =
Please note that this communication does not designate an information =
system for the purposes of the Electronic Transactions Act =
2002.

= --Apple-Mail=_EA17D934-BF2E-464D-BCC6-A8EDF1C55F7A-- From nobody Fri Jun 26 08:17:52 2020 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 AE01A3A080F for ; Fri, 26 Jun 2020 08:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 f0tFShVzzuSj for ; Fri, 26 Jun 2020 08:17:47 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CBB3A080A for ; Fri, 26 Jun 2020 08:17:47 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id k6so4470853oij.11 for ; Fri, 26 Jun 2020 08:17:47 -0700 (PDT) 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=iUR4w0phaaHtQUpRrOYnNTpXA03Veg3rKaADOjFVh54=; b=LYzVvIifKsisy7IWSqfs4CnVL+uObgmOa8G+9XS/mbgEi+iXz9++kNI6wJC+V8lATq XMLSy2qJp9D0j7GHm45jPX4loKKfBJypzMb/dOZ2OuiHlYFplMG/m69AK9mr0AVkF954 F1HU5fKqMT+y916v/Kw0ELlX5/EA8fZH8IQSn2zzkzRW9qFvfA4lEMlNIUGX3xvgvD+q FAiqM8r5R2ETuGP1rD6eT+5WkO5L9M53Q2Lq69Hblg1kFIsCKmajpDlYn5KlQ0lRV96g EZdo+jOSXP0ukKuA8v6Y/cZLo4CksKHWp4mtqqLcXGGpnqTalQhsJPfcdRVStXmo7HMT tysA== 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=iUR4w0phaaHtQUpRrOYnNTpXA03Veg3rKaADOjFVh54=; b=XlTsMixZvkSp1fi8nNC7KgoseF9ibu5lgLNnuq4L1RwAYetB7uF5B/pVdqO39+KebC NCq2ZEG2Rhpi6meS4447O7ho0HrSOUbbkrlooNdl+6Z6ZtC1wYqykzz1AncxNQeQQ43S IR/VukfexgH+hPy+tifnSWSAknpR845Hwi2fiMbIdeCSTkWcYQG/q5jdPxPSHUB073Od Br+3Ck+o8gvvB+jhtBlwIMkD5425NrpwiTxTMkC4JHjEzUjqmvmMAGCPA1xAdAb7zVdg AgFsIumxIu1fpsJbNn0cecirj7YfS9/zuWtJfiyUivSDUxyeLgwbFcqTm79IOuP5Z1Nk N6Gw== X-Gm-Message-State: AOAM5319nYQYTsiOyXgzEZNfci8qGguOtfDL2EINjNDC+nQSkdCQEvW6 DLnhfYgZ/cGzfywPrwBJqYb83m9BLGhRytU5GLg= X-Google-Smtp-Source: ABdhPJwM6M4KBhja+8M3J8yL7l5nTYinKLRXyZgguTdRgSzJBF1k63jfdoDsxw3fD81khNbzHmLa45eBO2eixFkOENM= X-Received: by 2002:aca:554c:: with SMTP id j73mr2912230oib.172.1593184666537; Fri, 26 Jun 2020 08:17:46 -0700 (PDT) MIME-Version: 1.0 References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> In-Reply-To: <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> From: Tom Jones Date: Fri, 26 Jun 2020 08:17:34 -0700 Message-ID: To: Justin Richer Cc: Tobias Looker , Denis , txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000001c580005a8fe36b2" Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 26 Jun 2020 15:17:51 -0000 --0000000000001c580005a8fe36b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While there are multiple reasons for bound tokens, each with their own needs, I strongly encourage an effort to create a single broad spec that could address the common security issues. Tobias, this is the general idea you were pushing on application level networking. As a general rule, I believe that the current effort to base security on channel binding has already been extended beyond its capabilities. (That is the concept that the HTTPS key is used as the security for the messages.) So, can't we focus on the problem of identifying the participants to an extended set of interchanges. This would formalize the earlier statements that the as and rs most likely have an ongoing security context on which to build subsequent interchanges. Peace ..tom On Fri, Jun 26, 2020 at 6:23 AM Justin Richer wrote: > On Jun 25, 2020, at 9:07 PM, Tobias Looker > wrote: > > > I find this feature interesting and think it could be an important patter= n > going forward to enable an AS to be able to describe the utility of a tok= en > to the client, however as already pointed out in the thread I think there > is some potential hidden complexity that would need to be ironed out such > that it does not make the simple things complicated. > > Justin, do you see this feature as something the client has to explicitly > request, i.e "please give me access and instructions on how to use my > access" or rather that the AS would just return this information in > conjunction with the access token if it had it available? > > > This is something that I=E2=80=99d brought up as a possibility on the pre= vious > thread =E2=80=94 something like a flag the client would set. This would b= e > especially important if the AS wants to return multiple access tokens but > the client requested 1, or the client requested N and the AS wants to > return M in response. Basically any time there=E2=80=99s a mismatch, that= =E2=80=99s extra > complexity on the client that I really don=E2=80=99t think we want to be = universal. > A flag to turn that kind of direction and splitting on would be a potenti= al > start. But there are potential snags here too, and it comes down to how y= ou > manage the defaults... > > > This is just the start, too. Things get even more complex if the client > can ask for multiple different kinds of resources at once. What if the AS > decides that the client needs a hyper-focused directed token for one part > of the API, but can use a general token for other stuff? Can it signal th= at > to the client? And if it can, does that mean that all clients need to be > prepared for that kind of thing? > > Would a potential default be that if a client did for any reason not > support processing the additional information returned with the > access_token, just to ignore it? I think in the spirit of keeping the > simple things simple, this potentially makes sense? > > > That=E2=80=99s the real trick, if you ask me. It has to be :safe: for a c= lient to > ignore this information. Which means the AS can=E2=80=99t rely on the cli= ent =E2=80=9Cdoing > the right thing=E2=80=9D with the information in the =E2=80=9Ctoken direc= tions=E2=80=9D portion of > the response. Even setting aside the advanced and related =E2=80=9Csplit = tokens=E2=80=9D > idea above, we need to make sure that an AS/RS setup is built such that i= f > the AS tells a client =E2=80=9Conly do X with your token=E2=80=9D and the= client does =E2=80=9CY=E2=80=9D, > then there are other protections and practices in place to prevent things > from going haywire if the client does =E2=80=9CY=E2=80=9D either by accid= ent or through > ignorance. > > If OAuth 2 has taught us anything, it=E2=80=99s that client applications = are going > to be the laziest participants in the security model. And that makes sens= e, > really =E2=80=94 security isn=E2=80=99t what the client apps are trying t= o do, they=E2=80=99re > trying to use the RS to do something. So we need to make sure that whatev= er > system we design will fail on the safe side as much as possible, and keep > things simple for the client. > > > > here are some worked out samples of this: > https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token > https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ > Peace ..tom > > As one of the authors of those mentioned drafts, I am interested in > discussing that, but perhaps on a seperate thread? As at least the bound > assertion spec is primarily concerned with binding mechanisms for the > artifacts produced from an authorization flow (specifically identity > claims), whereas I think directed access tokens is just more generally > talking about whether GNAP should support an AS conveying how to use an > access_token it produces during a flow with a client. > > > I think that these are separate issues as well. > > =E2=80=94 Justin > > Thanks, > [image: Mattr website] > *Tobias Looker* > Mattr > +64 (0) 27 378 0461 > tobias.looker@mattr.global > [image: Mattr website] [image: Mattr on LinkedIn] > [image: Mattr on Twitter] > [image: Mattr on Github] > > This communication, including any attachments, is confidential. If you ar= e > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > > On Wed, Jun 24, 2020 at 10:14 PM Denis wrote: > >> Justin, I fear we are still far away from an agreement about what this >> BoF should do. >> >> Tom Jones is saying " I am getting tired of the whack-a-mole approach ..= ." >> >> I don't agree with you when you write: "I think it=E2=80=99s going to be >> overwhelmingly common that a given RS is going to trust exactly one AS >> that it knows about ahead of time". Such an architecture would have >> exactly the same limitations as OAuth 2.0. and would not be scalable. >> >> Before we start, we should have a clear view of the whole picture rather >> than starting from one scenario and expanding it in many different >> directions. >> For building an architecture, a pre-requirement is to define ALL the >> trust relationships. I don't believe that we have an agreement at this t= ime >> on what >> these trust relationships are. >> >> You are also using the following wording: "methods for the AS and RS to >> communicate what the token=E2=80=99s good for". >> With such a paradigm, it would be impossible to protect the user's >> privacy. >> >> A key question is : Will GNAP take care of the user's privacy or will >> GNAP *prevent *to take care of the user's privacy ? >> >> About "the ability for the client to get several access tokens to get >> different resources from one request" is indeed a complex case. >> >> No one (including ASs) is able to predict in advance which access tokens >> will be needed, since they depend upon the kind of operation(s) >> the client will be willing to perform. For privacy reasons, ASs should b= e >> kept ignorant of all the operations that a client is going to perform >> on one or more resource servers. I believe that every effort should be >> made to avoid the AS to be in a position to be able to trace the operati= ons >> performed by its clients on various RSs. >> >> To handle the complex case you envision, the full workflow of operations >> needs to be considered with a detailed focus on the time >> at which the user's *consent and choice* happens (*consent and choice* >> is the first privacy principle from ISO 29100). >> >> First of all, an access token could be targeted to a service rather than >> to a server. This would already solve many cases. >> >> When a RS needs to call another RS (which does not support the same >> service) then the client should be informed by the first RS. >> His "consent and choice" should then be obtained by the first RS and, >> when the user agrees, the client should then ask an access token >> to one of the ASs trusted by the second RS in order to perform the >> subsequent operation. >> >> Denis >> >> PS. In an email sent on June 23 you wrote: " I think an on-device AS is >> an important use case". I am sorry, but I don't understand. >> However, I do understand what "a server-based AS" is. >> >> >> Denis, thanks for the great comments. I think that your trust model is >> pretty different from what I=E2=80=99d laid out initially, and while it= =E2=80=99s an >> interesting and important one, it is not what I meant by =E2=80=9Cmultip= le access >> tokens=E2=80=9D in my discussion below. I think that might be the cause = of some >> disconnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of reach= for what the WG is >> after. >> >> When I refer to multiple access tokens, and what the charter calls out a= s >> multiple access tokens, is the ability for the client to get several acc= ess >> tokens to get different resources from one request. I personally see thi= s >> as an optimization of a specific set of use cases, some of which I >> discussed in my original email. There are others, I=E2=80=99m sure, but = all the >> ones I=E2=80=99ve seen are around the client needing to get several diff= erent kinds >> of access through an AS. >> >> I think it=E2=80=99s going to be overwhelmingly common that a given RS i= s going >> to trust exactly one AS that it knows about ahead of time. But for RS=E2= =80=99s >> that can trust multiple AS=E2=80=99s, then we should have a model that c= an >> accommodate that as well. That=E2=80=99s why the charter calls out metho= ds for the >> AS and RS to communicate what the token=E2=80=99s good for. I think the = basis of >> those methods is going to start with a common token model, and likely >> incorporate into things like token formats and introspection-style token >> APIs. >> >> =E2=80=94 Justin >> >> On Jun 22, 2020, at 3:55 AM, Denis wrote: >> >> Hello Justin, >> >> A few comments between the lines. >> >> One of the most important aspects to GNAP is going to be an ability to >> address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do = without significant >> gymnastics. So with that, I wanted to bring back a use case discussion t= hat >> originally came up while we were talking about the possibility of multip= le >> access tokens, a few months back. I don=E2=80=99t know if this concept h= as a >> regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access t= okens=E2=80=9D until we >> come up with something better =E2=80=94 assuming we decide this is worth= while. >> >> I don't understand what may mean "directed access tokens=E2=80=9D but I >> understand what means "multiple access tokens". >> When speaking of "multiple access tokens", these access tokens may come >> from one or more ASs. >> >> In OAuth, the client=E2=80=99s supposed to always know where to send its= access >> token, and that knowledge is completely outside the protocol. This makes= a >> lot of sense for many (if not most) deployments, as OAuth is really ther= e >> to enable the API access that the client already knows about. >> >> But we=E2=80=99re now in a world where a client could be talking to a ge= neric API >> that could be deployed at a number of different places, or a cloud >> deployment that the AS wants to be able to dispatch the client to. >> >> As soon the AS is placed (again) at the centre of the model, the AS will >> have the ability to act as "Big Brother". >> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP >> should take care of them. >> >> In order to do this, the AS needs to be able to communicate to the clien= t >> not only the token information (and any related key and presentation >> information), but also a set of *directions* about what that specific >> token is good for. This needs to be information outside the token itself= , >> since I believe we want to keep OAuth 2=E2=80=99s feature of having the = token be >> opaque to the client. Note: while we could map all of these to different >> resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlanc= e) >> on the request side, this isn=E2=80=99t enough to tell the client what t= o do with >> the token *if it doesn=E2=80=99t know already*. >> >> I know of two use cases already in the wild, where people are addressing >> things using a mix of existing standards and some proprietary extensions= to >> address things within their silos. I=E2=80=99ll try to summarize here, b= ut I know >> the folks I=E2=80=99ve been talking to about this are also on the list s= o hopefully >> they can chime in with more detail or any corrections for something I=E2= =80=99ve >> missed. >> >> (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2= =80=99t know >> where it=E2=80=99s hosted. Everything is in a single security domain con= trolled by >> the AS, >> >> Speaking of "multiple access tokens" is in contradiction with single >> security domain "controlled" by an AS. >> A user may need to demonstrate some of his identity attributes granted >> e.g. by his bank but may also >> need to demonstrate one or more diplomas granted by one or more >> universities. The bank cannot be >> the "primary issuer" of a university diploma. It should not be either a >> "secondary issuer", because >> the bank does not "*need to know"* what are the diplomas of the user. >> >> but the AS needs to decide at runtime which specific instance of the API >> to direct the client to. Since things are closely tied together, the cli= ent >> just needs to effectively known an identifier for the RS, and this is >> currently implemented as a URI. Once the client has that identifier, it >> knows how to dispatch that token to that instance of the RS. >> >> There is no good reason why the AS should be involved in that step. >> OAuth 2.0 is/was implicitly mandating a strong relationship between ASs >> and RSs which makes it non scalable. >> GNAP should be based on a simple trust relationship : a given RS trusts >> some ASs for access tokens that contains some types of attributes. >> An AS should not need to know in advance (or even at the time of an >> access token request) the RSs that are trusting it. >> >> A client could first talk to a "global service provider" which has the >> knowledge of the different RSs affiliated to it. >> >> (2) The client knows what kind of thing it=E2=80=99s looking for, but do= esn=E2=80=99t >> know who to ask it from. >> >> Once again, the client could first talk to a "global service provider" >> which has the knowledge of the different RSs affiliated to it. >> >> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, a= nd the AS needs >> to dispatch to different resources depending on which user logged in (an= d >> possibly what the user consented to). To make things more concrete, the >> client needs to get driver=E2=80=99s license information, but doesn=E2= =80=99t know ahead of >> time which of the many state/provincial bureaus to call to get that >> information because it doesn=E2=80=99t know yet who the user is. >> >> When a user has a driving license, he knows its issuer. The user can the= n >> provide some hint to the client. >> >> The AS will know who the user is once they log in and approve things, an= d >> so it can direct the client to call the correct RS. Since this is a >> relatively simple API with a pre-negotiated cross-domain trust, the AS >> returns a URL that the client presents the token at. >> >> A single AS should not be aware of all the attributes a user has. >> >> >> As far as I know, in both of these cases, the token is only good for tha= t >> API and not others =E2=80=94 but more on that later. >> >> A simple thing to do is just give back a URL with the access token, whic= h >> tells the client where to go. >> >> { >> =E2=80=9Caccess_token=E2=80=9D: { >> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D, >> =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo" >> } >> } >> >> This is good for some kinds of APIs, but it=E2=80=99s limiting because n= ot all >> APIs dispatch based on the URL. An AS might want to divvy up access toke= ns >> to an API that=E2=80=99s keyed on headers, or verbs, or any number of th= ings. And >> it doesn=E2=80=99t tell us immediately what to do about non-exact URL ma= tches. Can >> the client add query parameters and still use the token? What about path >> segments? I like that this simple approach addresses some common >> deployments that we already see today (see above), it=E2=80=99s not univ= ersal. Do >> we want or need a universal description language for directing where tok= ens >> go? >> >> This also opens up a whole new set of security questions. If the AS can >> now direct the client where to use the token, could a rogue AS convince = a >> legit client to use a stolen token at the wrong RS? And what if the clie= nt >> ignores the directions from the AS entirely? Could this open up new aven= ues >> of attack? >> >> This is just the start, too. Things get even more complex if the client >> can ask for multiple different kinds of resources at once. What if the A= S >> decides that the client needs a hyper-focused directed token for one par= t >> of the API, but can use a general token for other stuff? Can it signal t= hat >> to the client? And if it can, does that mean that all clients need to be >> prepared for that kind of thing? >> >> I firmly believe that whatever we build in GNAP, we need to optimize for >> the overwhelmingly common use case of a client getting a single access >> token to call APIs that it already knows about. Anything we add on top o= f >> that really can=E2=80=99t get in the way of this, because if it does, th= ere=E2=80=99s very >> small chance that people will try to use this for everyday things. Keep = the >> simple things simple, and the complex things possible, after all. >> >> I=E2=80=99m really looking forward to hearing what the community thinks = about >> these use cases, and hopefully the people I=E2=80=99ve chatted with offl= ine about >> this can join the conversation and provide more light than I was able to= . >> >> The two use cases which are considered above are: >> >> (1) The client knows what resource it=E2=80=99s calling, but it doesn=E2= =80=99t know >> where it=E2=80=99s hosted. >> (2) The client knows what kind of thing it=E2=80=99s looking for, but do= esn=E2=80=99t >> know who to ask it from. >> >> That does not mean in any way that these two use cases should be solved >> by placing the AS at the centre of the solution. >> >> Denis >> >> >> =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 >> > > This communication, including any attachments, is confidential. If you ar= e not the intended recipient, you should not read it - please contact me im= mediately, destroy it, and do not copy or use any part of this communicatio= n or disclose anything about it. Thank you. Please note that this communica= tion does not designate an information system for the purposes of the Elect= ronic Transactions Act 2002. > > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --0000000000001c580005a8fe36b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While there are multiple reasons for bound tokens, each wi= th their own needs, I strongly encourage an effort to create a single broad= spec that could address the common security issues. Tobias, this is the ge= neral idea you were pushing on application level networking. As a general r= ule, I believe=C2=A0that the current effort to base security on channel bin= ding has already been extended beyond=C2=A0its capabilities. (That is the c= oncept that the HTTPS key is used as the security for the messages.) So, ca= n't we focus on the problem of identifying the participants to an exten= ded set of interchanges. This would formalize the earlier statements that t= he as and rs most likely have an ongoing=C2=A0security context on which to = build subsequent interchanges.
Peace ..tom


On Fri, Jun 26, 2020 at 6:23 AM J= ustin Richer <jricher@mit.edu>= wrote:
On Jun 25, 2020, at 9:07 PM, Tobias Looke= r <tobia= s.looker@mattr.global> wrote:

=
I find this feature interesting and think it could be= an important=C2=A0pattern going=C2=A0forward to enable an AS to be able to= describe the utility of a token to the client, however as already pointed = out in the thread I think there is some potential hidden complexity that wo= uld need to be ironed out such that it does not make the simple things comp= licated.

Justin, do you see this feature as something th= e client has to explicitly request, i.e "please give me access and ins= tructions on how to use my access" or rather that the AS would just re= turn this information in conjunction with the access token if it had it ava= ilable?


Th= is is something that I=E2=80=99d brought up as a possibility on the previou= s thread =E2=80=94 something like a flag the client would set. This would b= e especially important if the AS wants to return multiple access tokens but= the client requested 1, or the client requested N and the AS wants to retu= rn M in response. Basically any time there=E2=80=99s a mismatch, that=E2=80= =99s extra complexity on the client that I really don=E2=80=99t think we wa= nt to be universal. A flag to turn that kind of direction and splitting on = would be a potential start. But there are potential snags here too, and it = comes down to how you manage the defaults...

> This is just the start, too. Things ge= t even more complex if the client can ask for multiple different kinds of r= esources at once. What if the AS decides that the client needs a hyper-focu= sed directed token for one part of the API, but can use a general token for= other stuff? Can it signal that to the client? And if it can, does that me= an that all clients need to be prepared for that kind of thing?
<= br>
Would a potential default be that if a client did for any rea= son not support processing the additional information returned with the acc= ess_token, just to ignore it? I think in the spirit of keeping the simple t= hings simple, this potentially makes sense?
<= div>
That=E2=80=99s the real trick, if you ask me. It has to = be :safe: for a client to ignore this information. Which means the AS can= =E2=80=99t rely on the client =E2=80=9Cdoing the right thing=E2=80=9D with = the information in the =E2=80=9Ctoken directions=E2=80=9D portion of the re= sponse. Even setting aside the advanced and related =E2=80=9Csplit tokens= =E2=80=9D idea above, we need to make sure that an AS/RS setup is built suc= h that if the AS tells a client =E2=80=9Conly do X with your token=E2=80=9D= and the client does =E2=80=9CY=E2=80=9D, then there are other protections = and practices in place to prevent things from going haywire if the client d= oes =E2=80=9CY=E2=80=9D either by accident or through ignorance.=C2=A0

If OAuth 2 has taught us anything, it=E2=80=99s that c= lient applications are going to be the laziest participants in the security= model. And that makes sense, really =E2=80=94 security isn=E2=80=99t what = the client apps are trying to do, they=E2=80=99re trying to use the RS to d= o something. So we need to make sure that whatever system we design will fa= il on the safe side as much as possible, and keep things simple for the cli= ent.


> here are some worked out samples of this:
https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token
Peace= ..tom

As one of the authors of those mentioned dr= afts, I am interested in discussing that, but perhaps on a seperate thread?= As at least=C2=A0the bound assertion spec is=C2=A0primarily=C2=A0concerned= with binding mechanisms for the artifacts produced from an authorization f= low (specifically identity claims), whereas I think directed access tokens = is just more generally talking about whether GNAP should support an AS conv= eying how to use an access_token it produces during a flow with a client.


I think that these are separate issues as well.
<= div>
=C2=A0=E2=80=94 Justin

Thanks,=
3D==C2=A0
Tobias Looker
Matt= r
+64 (0) 27 378 0461
= tobias.looker@mattr.global
3D"Mat=3D"Mattr=

This communication, including any att= achments, is confidential. If you are not the intended recipient, you shoul= d not read it - please contact me immediately, destroy it, and do not copy = or use any part of this communication or disclose anything about it. Thank = you. Please note that this communication does not designate an information = system for the purposes of the Electronic Transactions Act 2002.


On Wed, Jun 24, 2020 at 10:14 PM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Justin, I fear we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I am getting tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it=E2=80=99s g= oing to be overwhelmingly common that a given RS is going to trust exactly one AS
that it knows about ahead of time". Such an architecture would have exactly the same limitations as OAuth 2.0. and would not be scalable.

Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions.
For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believe that we have an agreement at this time on what these trust relationships are.

You are also using the following wording: "methods for the AS and RS to communicate what the token=E2=80=99s good for".
With such a paradigm, it would be impossible to protect the user'= s privacy.

A key question is : Will GNAP take care of the user's privacy or will GNAP prevent to take care of the user's privacy ?

About "the ability for the client to get several access tokens to get different resources from one request" is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform
on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).

First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases.

When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS.
His "consent and choice" should then be obtained by the first RS and, when the user agrees, the client should then ask an access token
to one of the ASs trusted by the second RS in order to perform the subsequent operation.=C2=A0

Denis

PS.=C2=A0 In an email sent on June 23 you wrote: " I think an on-device AS is an important use case".= =C2=A0 I am sorry, but I don't understand.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 However, I do understand what &q= uot;a server-based AS" is.


=20 Denis, thanks for the great comments. I think that your trust model is pretty different from what I=E2=80=99d laid out initially, a= nd while it=E2=80=99s an interesting and important one, it is not what I meant by =E2=80=9Cmultiple access tokens=E2=80=9D in my discussion be= low. I think that might be the cause of some disconnect here, but that doesn=E2=80= =99t mean it=E2=80=99s out of reach for what the WG is after.

When I refer to multiple access tokens, and what the charter calls out as multiple access tokens, is the ability for the client to get several access tokens to get different resources from one request. I personally see this as an optimization of a specific set of use cases, some of which I discussed in my original email. There are others, I=E2=80=99m sure,= but all the ones I=E2=80=99ve seen are around the client needing to get several different kinds of access through an AS.=C2=A0

I think it=E2=80=99s going to be overwhelmingly common that a given RS is going to trust exactly one AS that it knows about ahead of time. But for RS=E2=80=99s that can trust multiple AS=E2=80=99s, then we should have a model that can accommodate th= at as well. That=E2=80=99s why the charter calls out methods for the AS= and RS to communicate what the token=E2=80=99s good for. I think the = basis of those methods is going to start with a common token model, and likely incorporate into things like token formats and introspection-style token APIs.=C2=A0

=C2=A0=E2=80=94 Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the lines.

One of the most i= mportant aspects to GNAP is going to be an ability to address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do witho= ut significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don=E2=80=99= t know if this concept has a regular term, so I=E2=80=99m g= oing to call it =E2=80=9Cdirected access tokens=E2=80=9D until= we come up with something better =E2=80=94 assuming we decide this i= s worthwhile.=C2=A0

I don't understand what may mean "directed access tokens=E2= =80=9D but I understand what means "multiple access tokens"= ;.=C2=A0
When speaking of "multiple access tokens", thes= e access tokens may come from one or more ASs.

In OAuth, the client=E2=80=99s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we=E2=80=99re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.=C2=A0

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".<= br> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of=C2=A0di= rections=C2=A0about what that specific token is good for. This needs to be information outside the token itself, since I=C2=A0believe we want to keep OAuth 2=E2=80=99s featur= e of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t enough to tell the client what to do with= the token=C2=A0if it doesn=E2=80=99t know a= lready.=C2=A0

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I=E2=80=99ll try to summarize here, but I know the folk= s I=E2=80=99ve been talking to about this are also on the= list so hopefully they can chime in with more detail or any corrections for something I=E2=80=99ve missed.=C2= =A0

(1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s= hosted. Everything is in a single security domain controlled by the AS,=C2=A0

Speaking of "multiple access tokens" is in contradiction wi= th single security domain "controlled" by an AS.=C2=A0
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also=C2= =A0
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be=C2=A0<= /span>
the "primary issuer" of a university diploma. I= t should not be either a "secondary issuer", beca= use=C2=A0
the bank does not "need to know"= =C2=A0what are the diplomas of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved in that step.= =C2=A0
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" which= has the knowledge of the different RSs affiliated to it.=C2=A0

(2) The client knows what kind of thing it=E2=80=99s looking for, but doesn=E2=80=99t know who = to ask it from.=C2=A0

Once again, the client could first talk to a "global service provide= r" which has the knowledge of the different RSs affiliated to it.=C2=A0

There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver=E2=80=99s license information, but doesn=E2=80= =99t know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn=E2=80= =99t know yet who the user is.=C2=A0

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at.=C2=A0

=C2=A0A single AS should not be aware of all the attributes a user has.=C2=A0


As far as I know, in both of these cases, the token is only good for that API and not others =E2=80=94 but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go.=C2=A0

{
=E2=80= =9Caccess_token=E2=80=9D: {
=E2= =80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
=E2= =80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
}
}

This is good for some kinds of APIs, but it=E2=80=99s limiting because not all APIs dispatch bas= ed on the URL. An AS might want to divvy up access tokens to an API that=E2=80=99s keyed on headers, or verbs, or= any number of things. And it doesn=E2=80=99t tell us immedi= ately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it=E2=80=99s not univers= al. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can=E2=80=99t get= in the way of this, because if it does, there=E2=80=99s ve= ry small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I=E2=80=99m really looking forward to hearing what the community thinks about these use cases, and hopefully the people I=E2=80=99ve chatted with offline = about this can join the conversation and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what re= source it=E2=80=99s calling, but it doesn=E2=80=99t know where it=E2=80=99s= hosted.
(2) The client knows what kind of thing it=E2=80=99s lo= oking for, but doesn=E2=80=99t know who to ask it from.= =C2=A0

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Denis


=C2=A0=E2=80=94 Justin


--=C2= =A0
Txauth mail= ing list
Txauth@ietf= .org
https://www.ietf.org/mailman/listinfo/txauth


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

This communication, including any at=
tachments, is confidential. If you are not the intended recipient, you shou=
ld not read it - please contact me immediately, destroy it, and do not copy=
 or use any part of this communication or disclose anything about it. Thank=
 you. Please note that this communication does not designate an information=
 system for the purposes of the Electronic Transactions Act 2002.

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--0000000000001c580005a8fe36b2-- From nobody Fri Jun 26 08:57:24 2020 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 0DAD73A08DC; Fri, 26 Jun 2020 08:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 pkVbFO9_tyE2; Fri, 26 Jun 2020 08:57:15 -0700 (PDT) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (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 AB6513A0845; Fri, 26 Jun 2020 08:57:14 -0700 (PDT) Received: by mail-io1-f43.google.com with SMTP id v8so10253601iox.2; Fri, 26 Jun 2020 08:57:14 -0700 (PDT) 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=PYcCt+hJS51U8YR8Yu/HcWUMzMgdyP6C+PaNig8E7xM=; b=dbZ2gmCZhxOJR4rXar04ICc8RN/vOmQ37NwYaWupXAkNoDvyH0YG3bDnmRjYvkI1gQ Nop5vGsLrLZEpKYSXUQhuL9mmpK0dMxX+WYc16j1ZEEe1mkAP9Lmi2V1dbkgFDCaL8yw 6JdM/xmKxkeI8ERtayQollI2DfoTiNYkfK8K1EB3qtL7UlPyM+JgZZXLbuepxD3fKXzg gmUJlrhOL6pUBFaOt/K6b/BDMDbsfDX7m709TWbb0XIA6bX8qVk8eJaBOKbb7tEUyyPD hVMliyIXmYm6ak6TARabs2BBeDV7dmmP3+eAyVP6W3GpRunFxC4M7bI/IWga30NPSYcS XQ9w== X-Gm-Message-State: AOAM533fkIhA4LYaFWXatjS8BucCi/uaSUQoDJ+ivR7FnlQQ3xdmX2NA nrVcpy8d6wTdkBwSo5fLL5RCMyfefNVfj/uyikI= X-Google-Smtp-Source: ABdhPJy86dDO+OHNBJW/RDAnptXSMxF+OXg9WqsbXlQP+SzSHllSAv+sYzta5TYvEWyCuiITyFHdgyE99DWrxM747+4= X-Received: by 2002:a5d:8c8f:: with SMTP id g15mr4135576ion.206.1593187033762; Fri, 26 Jun 2020 08:57:13 -0700 (PDT) MIME-Version: 1.0 References: <159302228054.20699.8970656798339535215@ietfa.amsl.com> <486B1729-AC7B-4A34-9592-B8E23AFAC2D9@mit.edu> In-Reply-To: From: Barry Leiba Date: Fri, 26 Jun 2020 11:57:02 -0400 Message-ID: To: Roman Danyliw Cc: Justin Richer , "txauth@ietf.org" , The IESG , "gnap-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Txauth] Barry Leiba's No Objection on charter-ietf-gnap-00-01: (with COMMENT) 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, 26 Jun 2020 15:57:19 -0000 > Barry: I believe this addresses all of your feedback. D'accord. b From nobody Fri Jun 26 09:04:36 2020 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 4E3DF3A08EE for ; Fri, 26 Jun 2020 09:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 hLazq-RuW8qp for ; Fri, 26 Jun 2020 09:04:29 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614363A0801 for ; Fri, 26 Jun 2020 09:04:24 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d18 with ME id vs4L2201G4FMSmm03s4M2k; Fri, 26 Jun 2020 18:04:22 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 26 Jun 2020 18:04:22 +0200 X-ME-IP: 86.238.65.197 To: Tom Jones , Justin Richer Cc: Tobias Looker , txauth@ietf.org References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> From: Denis Message-ID: <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr> Date: Fri, 26 Jun 2020 18:04:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------51EECCCE1F1FD6F062B668C3" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 26 Jun 2020 16:04:35 -0000 This is a multi-part message in MIME format. --------------51EECCCE1F1FD6F062B668C3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Tom and Justin, Why do want to make things complicated when they are quite simple ? The statement saying "the as and rs most likely have an ongoing security context on which to build subsequent interchanges" would have severe limitations in terms of scalability and privacy. The principle where a RS would only have relationships with one AS would make the model non scalable. It would prevent to get attributes from two different ASs,  for example: identity attributes from a bank and a master degree diploma from a university. For privacy reasons, every AS should know as little as possible about the interactions between a client and multiple RSs. It is even possible that this goes as little as knowing /nothing at all/. The OAuth 2.0 assumption where the AS is in a position to know all the interactions of a given user has with all the RSs that an AS server has a relationship with should not be re-iterated. The relationships between RSs may change at any time and it would not be reasonable to inform the ASs in real time about these interactions. As already stated in an earlier email: No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s) the client will be willing to perform. (...) To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time at which the user's *consent and choice* happens (/consent and choice/ is the first privacy principle from ISO 29100). A RS whether the first one of a RS chain and a subsequent one, taking into consideration the kind of operation that will be requested by the client, should be is able to inform the user about which kind of attributes are needed and from which AS(s) [note the plural], they may be obtained. Denis > While there are multiple reasons for bound tokens, each with their own > needs, I strongly encourage an effort to create a single broad spec > that could address the common security issues. Tobias, this is the > general idea you were pushing on application level networking. As a > general rule, I believe that the current effort to base security on > channel binding has already been extended beyond its capabilities. > (That is the concept that the HTTPS key is used as the security for > the messages.) So, can't we focus on the problem of identifying the > participants to an extended set of interchanges. This would formalize > the earlier statements that the as and rs most likely have an > ongoing security context on which to build subsequent interchanges. > Peace ..tom > > > On Fri, Jun 26, 2020 at 6:23 AM Justin Richer > wrote: > > On Jun 25, 2020, at 9:07 PM, Tobias Looker > > > wrote: >> >> I find this feature interesting and think it could be an >> important pattern going forward to enable an AS to be able to >> describe the utility of a token to the client, however as already >> pointed out in the thread I think there is some potential hidden >> complexity that would need to be ironed out such that it does not >> make the simple things complicated. >> >> Justin, do you see this feature as something the client has to >> explicitly request, i.e "please give me access and instructions >> on how to use my access" or rather that the AS would just return >> this information in conjunction with the access token if it had >> it available? >> > > This is something that I’d brought up as a possibility on the > previous thread — something like a flag the client would set. This > would be especially important if the AS wants to return multiple > access tokens but the client requested 1, or the client requested > N and the AS wants to return M in response. Basically any time > there’s a mismatch, that’s extra complexity on the client that I > really don’t think we want to be universal. A flag to turn that > kind of direction and splitting on would be a potential start. But > there are potential snags here too, and it comes down to how you > manage the defaults... > >> > This is just the start, too. Things get even more complex if >> the client can ask for multiple different kinds of resources at >> once. What if the AS decides that the client needs a >> hyper-focused directed token for one part of the API, but can use >> a general token for other stuff? Can it signal that to the >> client? And if it can, does that mean that all clients need to be >> prepared for that kind of thing? >> >> Would a potential default be that if a client did for any reason >> not support processing the additional information returned with >> the access_token, just to ignore it? I think in the spirit of >> keeping the simple things simple, this potentially makes sense? > > That’s the real trick, if you ask me. It has to be :safe: for a > client to ignore this information. Which means the AS can’t rely > on the client “doing the right thing” with the information in the > “token directions” portion of the response. Even setting aside the > advanced and related “split tokens” idea above, we need to make > sure that an AS/RS setup is built such that if the AS tells a > client “only do X with your token” and the client does “Y”, then > there are other protections and practices in place to prevent > things from going haywire if the client does “Y” either by > accident or through ignorance. > > If OAuth 2 has taught us anything, it’s that client applications > are going to be the laziest participants in the security model. > And that makes sense, really — security isn’t what the client apps > are trying to do, they’re trying to use the RS to do something. So > we need to make sure that whatever system we design will fail on > the safe side as much as possible, and keep things simple for the > client. > >> >> > here are some worked out samples of this: >> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token >> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ >> Peace ..tom >> >> As one of the authors of those mentioned drafts, I am interested >> in discussing that, but perhaps on a seperate thread? As at >> least the bound assertion spec is primarily concerned with >> binding mechanisms for the artifacts produced from an >> authorization flow (specifically identity claims), whereas I >> think directed access tokens is just more generally talking about >> whether GNAP should support an AS conveying how to use an >> access_token it produces during a flow with a client. >> > > I think that these are separate issues as well. > >  — Justin > >> Thanks, >> Mattr website >> *Tobias Looker* >> Mattr >> +64 (0) 27 378 0461 >> tobias.looker@mattr.global >> Mattr website Mattr on LinkedIn >> Mattr on Twitter >> Mattr on Github >> >> >> >> This communication, including any attachments, is confidential. >> If you are not the intended recipient, you should not read it - >> please contact me immediately, destroy it, and do not copy or use >> any part of this communication or disclose anything about it. >> Thank you. Please note that this communication does not designate >> an information system for the purposes of the Electronic >> Transactions Act 2002. >> >> >> On Wed, Jun 24, 2020 at 10:14 PM Denis > > wrote: >> >> Justin, I fear we are still far away from an agreement about >> what this BoF should do. >> >> Tom Jones is saying " I am getting tired of the whack-a-mole >> approach ..." >> >> I don't agree with you when you write: "I think it’s going to >> be overwhelmingly common that a given RS is going to trust >> exactly one AS >> that it knows about ahead of time". Such an architecture >> would have exactly the same limitations as OAuth 2.0. and >> would not be scalable. >> >> Before we start, we should have a clear view of the whole >> picture rather than starting from one scenario and expanding >> it in many different directions. >> For building an architecture, a pre-requirement is to define >> ALL the trust relationships. I don't believe that we have an >> agreement at this time on what >> these trust relationships are. >> >> You are also using the following wording: "methods for the AS >> and RS to communicate what the token’s good for". >> With such a paradigm, it would be impossible to protect the >> user's privacy. >> >> A key question is : Will GNAP take care of the user's privacy >> or will GNAP *prevent *to take care of the user's privacy ? >> >> About "the ability for the client to get several access >> tokens to get different resources from one request" is indeed >> a complex case. >> >> No one (including ASs) is able to predict in advance which >> access tokens will be needed, since they depend upon the kind >> of operation(s) >> the client will be willing to perform. For privacy reasons, >> ASs should be kept ignorant of all the operations that a >> client is going to perform >> on one or more resource servers. I believe that every effort >> should be made to avoid the AS to be in a position to be able >> to trace the operations >> performed by its clients on various RSs. >> >> To handle the complex case you envision, the full workflow of >> operations needs to be considered with a detailed focus on >> the time >> at which the user's *consent and choice* happens (/consent >> and choice/ is the first privacy principle from ISO 29100). >> >> First of all, an access token could be targeted to a service >> rather than to a server. This would already solve many cases. >> >> When a RS needs to call another RS (which does not support >> the same service) then the client should be informed by the >> first RS. >> His "consent and choice" should then be obtained by the first >> RS and, when the user agrees, the client should then ask an >> access token >> to one of the ASs trusted by the second RS in order to >> perform the subsequent operation. >> >> Denis >> >> PS.  In an email sent on June 23 you wrote: " I think an >> on-device AS is an important use case".  I am sorry, but I >> don't understand. >>        However, I do understand what "a server-based AS" is. >> >> >>> Denis, thanks for the great comments. I think that your >>> trust model is pretty different from what I’d laid out >>> initially, and while it’s an interesting and important one, >>> it is not what I meant by “multiple access tokens” in my >>> discussion below. I think that might be the cause of some >>> disconnect here, but that doesn’t mean it’s out of reach for >>> what the WG is after. >>> >>> When I refer to multiple access tokens, and what the charter >>> calls out as multiple access tokens, is the ability for the >>> client to get several access tokens to get different >>> resources from one request. I personally see this as an >>> optimization of a specific set of use cases, some of which I >>> discussed in my original email. There are others, I’m sure, >>> but all the ones I’ve seen are around the client needing to >>> get several different kinds of access through an AS. >>> >>> I think it’s going to be overwhelmingly common that a given >>> RS is going to trust exactly one AS that it knows about >>> ahead of time. But for RS’s that can trust multiple AS’s, >>> then we should have a model that can accommodate that as >>> well. That’s why the charter calls out methods for the AS >>> and RS to communicate what the token’s good for. I think the >>> basis of those methods is going to start with a common token >>> model, and likely incorporate into things like token formats >>> and introspection-style token APIs. >>> >>>  — Justin >>> >>>> On Jun 22, 2020, at 3:55 AM, Denis >>> > wrote: >>>> >>>> Hello Justin, >>>> >>>> A few comments between the lines. >>>> >>>>> One of the most important aspects to GNAP is going to be >>>>> an ability to address things that OAuth 2 can’t, or at >>>>> least can’t do without significant gymnastics. So with >>>>> that, I wanted to bring back a use case discussion that >>>>> originally came up while we were talking about the >>>>> possibility of multiple access tokens, a few months back. >>>>> I don’t know if this concept has a regular term, so I’m >>>>> going to call it “directed access tokens” until we come up >>>>> with something better — assuming we decide this is worthwhile. >>>> >>>> I don't understand what may mean "directed access tokens” >>>> but I understand what means "multiple access tokens". >>>> When speaking of "multiple access tokens", these access >>>> tokens may come from one or more ASs. >>>> >>>>> In OAuth, the client’s supposed to always know where to >>>>> send its access token, and that knowledge is completely >>>>> outside the protocol. This makes a lot of sense for many >>>>> (if not most) deployments, as OAuth is really there to >>>>> enable the API access that the client already knows about. >>>>> >>>>> But we’re now in a world where a client could be talking >>>>> to a generic API that could be deployed at a number of >>>>> different places, or a cloud deployment that the AS wants >>>>> to be able to dispatch the client to. >>>> >>>> As soon the AS is placed (again) at the centre of the >>>> model, the AS will have the ability to act as "Big Brother". >>>> OAuth 2.0 has not taken care of privacy issues. On the >>>> contrary, GNAP should take care of them. >>>> >>>>> In order to do this, the AS needs to be able to >>>>> communicate to the client not only the token information >>>>> (and any related key and presentation information), but >>>>> also a set of/directions/ about what that specific token >>>>> is good for. This needs to be information outside the >>>>> token itself, since I believe we want to keep OAuth 2’s >>>>> feature of having the token be opaque to the client. Note: >>>>> while we could map all of these to different resource >>>>> requests (in XYZ parlance) or scopes (in OAuth 2 legacy >>>>> parlance) on the request side, this isn’t enough to tell >>>>> the client what to do with the token/if it doesn’t know >>>>> already/. >>>>> >>>>> I know of two use cases already in the wild, where people >>>>> are addressing things using a mix of existing standards >>>>> and some proprietary extensions to address things within >>>>> their silos. I’ll try to summarize here, but I know the >>>>> folks I’ve been talking to about this are also on the list >>>>> so hopefully they can chime in with more detail or any >>>>> corrections for something I’ve missed. >>>>> >>>>> (1) The client knows what resource it’s calling, but it >>>>> doesn’t know where it’s hosted. Everything is in a single >>>>> security domain controlled by the AS, >>>> >>>> Speaking of "multiple access tokens" is in contradiction >>>> with single security domain "controlled" by an AS. >>>> A user may need to demonstrate some of his identity >>>> attributes granted e.g. by his bank but may also >>>> need to demonstrate one or more diplomas granted by one or >>>> more universities. The bank cannot be >>>> the "primary issuer" of a university diploma. It should not >>>> be either a "secondary issuer", because >>>> the bank does not "/need to know"/what are the diplomas of >>>> the user. >>>> >>>>> but the AS needs to decide at runtime which specific >>>>> instance of the API to direct the client to. Since things >>>>> are closely tied together, the client just needs to >>>>> effectively known an identifier for the RS, and this is >>>>> currently implemented as a URI. Once the client has that >>>>> identifier, it knows how to dispatch that token to that >>>>> instance of the RS. >>>> >>>> There is no good reason why the AS should be involved in >>>> that step. >>>> OAuth 2.0 is/was implicitly mandating a strong relationship >>>> between ASs and RSs which makes it non scalable. >>>> GNAP should be based on a simple trust relationship : a >>>> given RS trusts some ASs for access tokens that contains >>>> some types of attributes. >>>> An AS should not need to know in advance (or even at the >>>> time of an access token request) the RSs that are trusting it. >>>> >>>> A client could first talk to a "global service provider" >>>> which has the knowledge of the different RSs affiliated to it. >>>> >>>>> (2) The client knows what kind of thing it’s looking for, >>>>> but doesn’t know who to ask it from. >>>> >>>> Once again, the client could first talk to a "global >>>> service provider" which has the knowledge of the different >>>> RSs affiliated to it. >>>> >>>>> There’s a cross-domain trust that’s bridged by the AS, and >>>>> the AS needs to dispatch to different resources depending >>>>> on which user logged in (and possibly what the user >>>>> consented to). To make things more concrete, the client >>>>> needs to get driver’s license information, but doesn’t >>>>> know ahead of time which of the many state/provincial >>>>> bureaus to call to get that information because it doesn’t >>>>> know yet who the user is. >>>> >>>> When a user has a driving license, he knows its issuer. The >>>> user can then provide some hint to the client. >>>> >>>>> The AS will know who the user is once they log in and >>>>> approve things, and so it can direct the client to call >>>>> the correct RS. Since this is a relatively simple API with >>>>> a pre-negotiated cross-domain trust, the AS returns a URL >>>>> that the client presents the token at. >>>> >>>>  A single AS should not be aware of all the attributes a >>>> user has. >>>> >>>>> >>>>> As far as I know, in both of these cases, the token is >>>>> only good for that API and not others — but more on that >>>>> later. >>>>> >>>>> A simple thing to do is just give back a URL with the >>>>> access token, which tells the client where to go. >>>>> >>>>> { >>>>> “access_token”: { >>>>> “value”: “87yui843yfer”, >>>>> “resource_uri”: “https://example/foo" >>>>> } >>>>> } >>>>> >>>>> This is good for some kinds of APIs, but it’s limiting >>>>> because not all APIs dispatch based on the URL. An AS >>>>> might want to divvy up access tokens to an API that’s >>>>> keyed on headers, or verbs, or any number of things. And >>>>> it doesn’t tell us immediately what to do about non-exact >>>>> URL matches. Can the client add query parameters and still >>>>> use the token? What about path segments? I like that this >>>>> simple approach addresses some common deployments that we >>>>> already see today (see above), it’s not universal. Do we >>>>> want or need a universal description language for >>>>> directing where tokens go? >>>>> >>>>> This also opens up a whole new set of security questions. >>>>> If the AS can now direct the client where to use the >>>>> token, could a rogue AS convince a legit client to use a >>>>> stolen token at the wrong RS? And what if the client >>>>> ignores the directions from the AS entirely? Could this >>>>> open up new avenues of attack? >>>>> >>>>> This is just the start, too. Things get even more complex >>>>> if the client can ask for multiple different kinds of >>>>> resources at once. What if the AS decides that the client >>>>> needs a hyper-focused directed token for one part of the >>>>> API, but can use a general token for other stuff? Can it >>>>> signal that to the client? And if it can, does that mean >>>>> that all clients need to be prepared for that kind of thing? >>>>> >>>>> I firmly believe that whatever we build in GNAP, we need >>>>> to optimize for the overwhelmingly common use case of a >>>>> client getting a single access token to call APIs that it >>>>> already knows about. Anything we add on top of that really >>>>> can’t get in the way of this, because if it does, there’s >>>>> very small chance that people will try to use this for >>>>> everyday things. Keep the simple things simple, and the >>>>> complex things possible, after all. >>>>> >>>>> I’m really looking forward to hearing what the community >>>>> thinks about these use cases, and hopefully the people >>>>> I’ve chatted with offline about this can join the >>>>> conversation and provide more light than I was able to. >>>> >>>> The two use cases which are considered above are: >>>> >>>> (1) The client knows what resource it’s calling, but it >>>> doesn’t know where it’s hosted. >>>> (2) The client knows what kind of thing it’s looking >>>> for, but doesn’t know who to ask it from. >>>> >>>> That does not mean in any way that these two use cases >>>> should be solved by placing the AS at the centre of the >>>> solution. >>>> >>>> Denis >>>> >>>>> >>>>>  — 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 >> >> >> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. > > -- > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --------------51EECCCE1F1FD6F062B668C3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Tom and Justin,

Why do want to make things complicated when they are quite simple ?

The statement saying "the as and rs most likely have an ongoing security context on which to build subsequent interchanges"
would have severe limitations in terms of scalability and privacy.

The principle where a RS would only have relationships with one AS would make the model non scalable.
It would prevent to get attributes from two different ASs,  for example: 
identity attributes from a bank and a master degree diploma from a university.

For privacy reasons, every AS should know as little as possible about the interactions between a client and multiple RSs.
It is even possible that this goes as little as knowing nothing at all.

The OAuth 2.0 assumption where the AS is in a position to know all the interactions of a given user has with all the RSs
that an AS server has a relationship with should not be re-iterated.

The relationships between RSs may change at any time and it would not be reasonable to inform the ASs in real time
about these interactions.

As already stated in an earlier email:
No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. (...)

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).
A RS whether the first one of a RS chain and a subsequent one, taking into consideration the kind of operation that will be requested by the client,
should be is able to inform the user about which kind of attributes are needed and from which AS(s) [note the plural], they may be obtained.

Denis


While there are multiple reasons for bound tokens, each with their own needs, I strongly encourage an effort to create a single broad spec that could address the common security issues. Tobias, this is the general idea you were pushing on application level networking. As a general rule, I believe that the current effort to base security on channel binding has already been extended beyond its capabilities. (That is the concept that the HTTPS key is used as the security for the messages.) So, can't we focus on the problem of identifying the participants to an extended set of interchanges. This would formalize the earlier statements that the as and rs most likely have an ongoing security context on which to build subsequent interchanges.
Peace ..tom


On Fri, Jun 26, 2020 at 6:23 AM Justin Richer <jricher@mit.edu> wrote:
On Jun 25, 2020, at 9:07 PM, Tobias Looker <tobias.looker@mattr.global> wrote:

I find this feature interesting and think it could be an important pattern going forward to enable an AS to be able to describe the utility of a token to the client, however as already pointed out in the thread I think there is some potential hidden complexity that would need to be ironed out such that it does not make the simple things complicated.

Justin, do you see this feature as something the client has to explicitly request, i.e "please give me access and instructions on how to use my access" or rather that the AS would just return this information in conjunction with the access token if it had it available?


This is something that I’d brought up as a possibility on the previous thread — something like a flag the client would set. This would be especially important if the AS wants to return multiple access tokens but the client requested 1, or the client requested N and the AS wants to return M in response. Basically any time there’s a mismatch, that’s extra complexity on the client that I really don’t think we want to be universal. A flag to turn that kind of direction and splitting on would be a potential start. But there are potential snags here too, and it comes down to how you manage the defaults...

> This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

Would a potential default be that if a client did for any reason not support processing the additional information returned with the access_token, just to ignore it? I think in the spirit of keeping the simple things simple, this potentially makes sense?

That’s the real trick, if you ask me. It has to be :safe: for a client to ignore this information. Which means the AS can’t rely on the client “doing the right thing” with the information in the “token directions” portion of the response. Even setting aside the advanced and related “split tokens” idea above, we need to make sure that an AS/RS setup is built such that if the AS tells a client “only do X with your token” and the client does “Y”, then there are other protections and practices in place to prevent things from going haywire if the client does “Y” either by accident or through ignorance. 

If OAuth 2 has taught us anything, it’s that client applications are going to be the laziest participants in the security model. And that makes sense, really — security isn’t what the client apps are trying to do, they’re trying to use the RS to do something. So we need to make sure that whatever system we design will fail on the safe side as much as possible, and keep things simple for the client.


> here are some worked out samples of this:
Peace ..tom

As one of the authors of those mentioned drafts, I am interested in discussing that, but perhaps on a seperate thread? As at least the bound assertion spec is primarily concerned with binding mechanisms for the artifacts produced from an authorization flow (specifically identity claims), whereas I think directed access tokens is just more generally talking about whether GNAP should support an AS conveying how to use an access_token it produces during a flow with a client.


I think that these are separate issues as well.

 — Justin

Thanks,
Mattr website  
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
Mattr website Mattr on LinkedIn Mattr on Twitter Mattr on Github

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Wed, Jun 24, 2020 at 10:14 PM Denis <denis.ietf@free.fr> wrote:
Justin, I fear we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I am getting tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it’s going to be overwhelmingly common that a given RS is going to trust exactly one AS
that it knows about ahead of time". Such an architecture would have exactly the same limitations as OAuth 2.0. and would not be scalable.

Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions.
For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believe that we have an agreement at this time on what
these trust relationships are.

You are also using the following wording: "methods for the AS and RS to communicate what the token’s good for".
With such a paradigm, it would be impossible to protect the user's privacy.

A key question is : Will GNAP take care of the user's privacy or will GNAP prevent to take care of the user's privacy ?

About "the ability for the client to get several access tokens to get different resources from one request" is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform
on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).

First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases.

When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS.
His "consent and choice" should then be obtained by the first RS and, when the user agrees, the client should then ask an access token
to one of the ASs trusted by the second RS in order to perform the subsequent operation. 

Denis

PS.  In an email sent on June 23 you wrote: " I think an on-device AS is an important use case".  I am sorry, but I don't understand.
       However, I do understand what "a server-based AS" is.


Denis, thanks for the great comments. I think that your trust model is pretty different from what I’d laid out initially, and while it’s an interesting and important one, it is not what I meant by “multiple access tokens” in my discussion below. I think that might be the cause of some disconnect here, but that doesn’t mean it’s out of reach for what the WG is after.

When I refer to multiple access tokens, and what the charter calls out as multiple access tokens, is the ability for the client to get several access tokens to get different resources from one request. I personally see this as an optimization of a specific set of use cases, some of which I discussed in my original email. There are others, I’m sure, but all the ones I’ve seen are around the client needing to get several different kinds of access through an AS. 

I think it’s going to be overwhelmingly common that a given RS is going to trust exactly one AS that it knows about ahead of time. But for RS’s that can trust multiple AS’s, then we should have a model that can accommodate that as well. That’s why the charter calls out methods for the AS and RS to communicate what the token’s good for. I think the basis of those methods is going to start with a common token model, and likely incorporate into things like token formats and introspection-style token APIs. 

 — Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the lines.

One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can’t, or at least can’t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don’t know if this concept has a regular term, so I’m going to call it “directed access tokens” until we come up with something better — assuming we decide this is worthwhile. 

I don't understand what may mean "directed access tokens” but I understand what means "multiple access tokens". 
When speaking of "multiple access tokens", these access tokens may come from one or more ASs.

In OAuth, the client’s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we’re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to. 

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of directions about what that specific token is good for. This needs to be information outside the token itself, since I believe we want to keep OAuth 2’s feature of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn’t enough to tell the client what to do with the token if it doesn’t know already. 

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I’ll try to summarize here, but I know the folks I’ve been talking to about this are also on the list so hopefully they can chime in with more detail or any corrections for something I’ve missed. 

(1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted. Everything is in a single security domain controlled by the AS, 

Speaking of "multiple access tokens" is in contradiction with single security domain "controlled" by an AS. 
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also 
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be 
the "primary issuer" of a university diploma. It should not be either a "secondary issuer", because 
the bank does not "need to know" what are the diplomas of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved in that step. 
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it. 

(2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from. 

Once again, the client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it. 

There’s a cross-domain trust that’s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver’s license information, but doesn’t know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn’t know yet who the user is. 

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at. 

 A single AS should not be aware of all the attributes a user has. 


As far as I know, in both of these cases, the token is only good for that API and not others — but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go. 

{
“access_token”: {
“value”: “87yui843yfer”,
“resource_uri”: “https://example/foo"
}
}

This is good for some kinds of APIs, but it’s limiting because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that’s keyed on headers, or verbs, or any number of things. And it doesn’t tell us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it’s not universal. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can’t get in the way of this, because if it does, there’s very small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I’m really looking forward to hearing what the community thinks about these use cases, and hopefully the people I’ve chatted with offline about this can join the conversation and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted.
(2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from. 

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Denis


 — 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

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

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


--------------51EECCCE1F1FD6F062B668C3-- From nobody Fri Jun 26 09:09:46 2020 Return-Path: X-Original-To: txauth@ietf.org Delivered-To: txauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 194423A0873; Fri, 26 Jun 2020 09:09:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Cc: txauth@ietf.org Reply-To: iesg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <159318778098.29096.6482921706088845432@ietfa.amsl.com> Date: Fri, 26 Jun 2020 09:09:41 -0700 Archived-At: Subject: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 16:09:41 -0000 A new IETF WG has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-07-06. Grant Negotiation and Authorization Protocol (gnap) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Yaron Sheffer Leif Johansson Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: txauth@ietf.org To subscribe: ​https://www.ietf.org/mailman/listinfo/txauth Archive: https://mailarchive.ietf.org/arch/browse/txauth/ Group page: https://datatracker.ietf.org/group/gnap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/ This group is chartered to develop a fine-grained delegation protocol for authorization and API access, as well as requesting and providing user identifiers and claims. This protocol will allow an authorizing party to delegate access to client software through an authorization server. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions. The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the interaction channels, such as the end user’s browser, from the delegation channel, which happens directly between the client and the authorization server (in contrast with OAuth 2.0, which is initiated by the client redirecting the user’s browser). The protocol will include a means of specifying how the user can potentially be involved in an interactive fashion during the delegation process. The client and Authorization Server (AS) will use these interaction mechanisms to involve the user, as necessary, to make authorization decisions. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types of clients and interaction channels. The group will define interoperability for this protocol between different parties, including - client and authorization server; - client and resource server; and - authorization server and resource server. The group will seek to minimize assumptions about the form of client applications, allowing for: - Fine-grained specification of access - Approval of AS attestation to identifiers and other identity claims - Approval of access to multiple resources and APIs in a single interaction - Support for multiple access tokens in a single request and response - Support for directed, audience-restricted access tokens - Separation between the party authorizing access and the party operating the client requesting access 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 - Mechanisms for conveying user, software, organization, and other information used in authorization decisions - Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys - Optimized inclusion of additional information (including identifiers and identity assertions) through the delegation process Additionally, the group will provide mechanisms for management of the protocol lifecycle including: - Discovery of the authorization server - Revocation of active tokens - Mechanisms for the AS and RS to communicate the access granted by an access token Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible. This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be directed to the OAuth Working Group, including functionality back-ported from the protocol developed here to OAuth 2.0. The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. This group is not chartered to develop new cryptographic methods. The group is chartered to develop mechanisms for conveying identity information within the protocol including existing identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available. The initial work will focus on using HTTPS for communication between the client and the authorization server, taking advantage of optimization features of HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to other protocols such as COAP when doing so does not conflict with the primary focus. Milestones to include: - Core delegation protocol - Key presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded HTTP signatures - Conveyance mechanisms for identifiers and assertions - Guidelines for use of protocol extension points - (if needed) Guidelines on migration paths, implementation, and operations Where possible, the group will seek to make use of tools to guide and inform the standardization process including formal analysis, architecture documents, and use case documents. These artifacts will not be considered as working group milestones or deliverables. The working group will cooperate and coordinate with other IETF WGs such as OAUTH, and work with external organizations, such as the OpenID Foundation, as appropriate. Milestones: Jul 2021 - Core delegation protocol in WGLC Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to WGLC Oct 2021 - Key presentation mechanism binding to the core protocol, detached HTTP signatures, to WGLC Oct 2021 - Key presentation mechanism binding to the core protocol, embedded HTTP signature, to WGLC Dec 2021 - Guidelines for use of protocol extension points to WGLC Feb 2022 - Guidelines on migration paths, implementation, and operations to WGLC From nobody Fri Jun 26 09:43:52 2020 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 8E7943A0972 for ; Fri, 26 Jun 2020 09:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.38 X-Spam-Level: X-Spam-Status: No, score=0.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, PDS_OTHER_BAD_TLD=2, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 a8ncgotH3QVb for ; Fri, 26 Jun 2020 09:42:29 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862C03A096B for ; Fri, 26 Jun 2020 09:42:28 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d18 with ME id vsiS2200L4FMSmm03siScv; Fri, 26 Jun 2020 18:42:26 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 26 Jun 2020 18:42:26 +0200 X-ME-IP: 86.238.65.197 To: iesg@ietf.org, IETF-Announce Cc: txauth@ietf.org References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> From: Denis Message-ID: Date: Fri, 26 Jun 2020 18:42:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <159318778098.29096.6482921706088845432@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------2690AF39587430BFED08F207" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 26 Jun 2020 16:42:33 -0000 This is a multi-part message in MIME format. --------------2690AF39587430BFED08F207 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The current proposed charter is two pages long, which is far too long, while the OAuth 2.0 charter was half a page long. We should attempt to make the charter shorter ... and understandable. Hereafter is a full rewording of the charter, while the justification of its rewording is placed at the very end of this email. *New proposed charter* This group is chartered to develop a fine-grained protocol in a client, authorization server and resource server model, where a client can request to one or more authorization servers one or more attributes that it needs in order to perform one or more operations on a resource server, at the time it needs it. The attributes issued by an authorization server are provided in the form of an attributes token that is cryptographically signed. The protocol supports attributes tokens usable for multiple operations as well as narrowly as for a single operation. Since the privacy of the user is a concern, privacy by default and privacy by design are considered. The group is chartered to develop mechanisms for conveying target information and identity information within the protocol including identity attributes such as pseudonyms, email addresses, user names, home addresses, business addresses, phone numbers, date of birth, age. When a viable existing format is not available for these attributes, the group is chartered to define such format. Resource servers inform their clients about which access token formats are acceptable and depending upon the king of operation that is requested, which kind of attributes are needed and from which ASs that my be obtained. Through interaction mechanisms supported by the protocol, the resource server allows a user to make a decision whether it is willing or not to disclose some attributes to perform one or more operations. This group is not chartered to develop extensions to OAuth 2.0. and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. A major difference with OAuth 2.0 is that there is no bilateral trust relationship between an authorization server and a resource server: for a given category of attributes, a resource server may trust one or more authorization servers. Another major difference with OAuth 2.0. is that the content of an attributes token is meant to be accessible to the client. The group will define interoperable protocols between different parties, including: * client and authorization server; and * client and resource server. Milestones to include: * Architecture of the model, * Attributes token definition, including mechanism bindings * Core protocol between the different parties *Justification for the rewording* I have re-used the original text whenever it was adequate and concise. I also read "Identity in XYZ" from: https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz* *The good: "Rather than returning an ID token with potentially stale or large amounts of user information in the authorization response, let's return only the minimum necessary for the application to function, and let it request additional information that it needs when it needs it". _Comment_: This is a "privacy by default" principle which is indeed important. The good: "The value MAY vary for the same user when logging in to different applications in order to preserve the user's privacy, preventing different applications from cross-correlating users between apps". _Comment_: This is a privacy principle which is also indeed important. The bad: "The transaction response can include just the unique user identifier along with the access token. (...) This property is analogous to the "sub" property in an ID token. This value MUST uniquely identify this user within the system, and MUST be consistent when the same user logs in to the same application". _Comment_: This is in contradiction with the previous privacy principle. I also read https://oauth.xyz/. The bad: "In XYZ, a client that needs to talk to an API first begins an authorization transaction with the authorization server". _Comment_: IMHO, this workflow scenario is lincorrect. A client that needs to talk to an API first begins a dialog with ... the resource server. Depending upon the kind of operation the client wants to perform, the resource server informs the client about the categories of the attributes that are needed and about the authorization servers that are able to issue such attributes. I also browsed through previous emails from the mailing list: The bad: "The client is identified by its key". _Comment _: With such a paradigm, key rollover would be either impossible or rather complicated. A client is identified by ... an identifier. There are diffrent kinds of identifiers whether they are :      (1) temporarily unique,      (2) unique to the resource server,      (3) unique to the authorization server, or      (4) globally unique. *About the new proposed text of the charter * There is a need to introduce the components of the model and the trust relationships (which are different from those of Auth 2.0 which, by the way, are not mentioned in the charter). OAuth 2.0 did not (and still does not) consider privacy as being important. In this BoF/WG, we should consider the user's privacy as being important. I got rid of the word "delegation": the client does not delegate anything to an authorization server. If it would, this would mean that the authorization server would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy. I used the wording "attributes token" in order to make a wording difference with "access token". It is similar (but different) since its content is meant to be accessible by the client (whereas it is not allowed to be accessible in OAuth 2.0, which makes its content's verification impossible by the user). An authorization server / resource server protocol has not been explicitly mentioned (but has not been explicitly excluded). Such a protocol, if it would be related to a client, would come into contradiction with the user's privacy. Denis Pinkas DP Security Consulting France > A new IETF WG has been proposed in the Security Area. The IESG has not made > any determination yet. The following draft charter was submitted, and is > provided for informational purposes only. Please send your comments to the > IESG mailing list (iesg@ietf.org) by 2020-07-06. > > Grant Negotiation and Authorization Protocol (gnap) > ----------------------------------------------------------------------- > Current status: Proposed WG > > Chairs: > Yaron Sheffer > Leif Johansson > > Assigned Area Director: > Roman Danyliw > > Security Area Directors: > Benjamin Kaduk > Roman Danyliw > > Mailing list: > Address: txauth@ietf.org > To subscribe: ​https://www.ietf.org/mailman/listinfo/txauth > Archive: https://mailarchive.ietf.org/arch/browse/txauth/ > > Group page: https://datatracker.ietf.org/group/gnap/ > > Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/ > > This group is chartered to develop a fine-grained delegation protocol for > authorization and API access, as well as requesting and providing user > identifiers and claims. This protocol will allow an authorizing party to > delegate access to client software through an authorization server. It will > expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect > (itself an extension of OAuth 2.0) to support authorizations scoped as > narrowly as a single transaction, provide a clear framework for interaction > among all parties involved in the protocol flow, and remove unnecessary > dependence on a browser or user-agent for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the protocol, > each performing a specific role. The protocol will decouple the interaction > channels, such as the end user’s browser, from the delegation channel, which > happens directly between the client and the authorization server (in contrast > with OAuth 2.0, which is initiated by the client redirecting the user’s > browser). The protocol will include a means of specifying how the user can > potentially be involved in an interactive fashion during the delegation > process. The client and Authorization Server (AS) will use these interaction > mechanisms to involve the user, as necessary, to make authorization decisions. > This decoupling avoids many of the security concerns and technical challenges > of OAuth 2.0 and provides a non-invasive path for supporting future types of > clients and interaction channels. > > The group will define interoperability for this protocol between different > parties, including > - client and authorization server; > - client and resource server; and > - authorization server and resource server. > > The group will seek to minimize assumptions about the form of client > applications, allowing for: > - Fine-grained specification of access > - Approval of AS attestation to identifiers and other identity claims > - Approval of access to multiple resources and APIs in a single interaction > - Support for multiple access tokens in a single request and response > - Support for directed, audience-restricted access tokens > - Separation between the party authorizing access and the party operating the > client requesting access > > 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 > - Mechanisms for conveying user, software, organization, and other > information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding resource > requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information (including identifiers and > identity assertions) through the delegation process > > Additionally, the group will provide mechanisms for management of the protocol > lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Mechanisms for the AS and RS to communicate the access granted by an access > token > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt > to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol > where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as such > will focus on new technological solutions not necessarily compatible with > OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be directed > to the OAuth Working Group, including functionality back-ported from the > protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is not > chartered to develop new cryptographic methods. > > The group is chartered to develop mechanisms for conveying identity > information within the protocol including existing identifiers (such as email > addresses, phone numbers, usernames, and subject identifiers) and assertions > (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable > Credentials). The group is not chartered to develop new formats for > identifiers or assertions, nor is the group chartered to develop schemas for > user information, profiles, or other identity attributes, unless a viable > existing format is not available. > > The initial work will focus on using HTTPS for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP/2 and HTTP/3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol including TLS, > detached HTTP signature, and embedded HTTP signatures > - Conveyance mechanisms for identifiers and assertions > - Guidelines for use of protocol extension points > - (if needed) Guidelines on migration paths, implementation, and operations > > Where possible, the group will seek to make use of tools to guide and inform > the standardization process including formal analysis, architecture documents, > and use case documents. These artifacts will not be considered as working > group milestones or deliverables. > > The working group will cooperate and coordinate with other IETF WGs such as > OAUTH, and work with external organizations, such as the OpenID Foundation, > as appropriate. > > Milestones: > > Jul 2021 - Core delegation protocol in WGLC > > Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to > WGLC > > Oct 2021 - Key presentation mechanism binding to the core protocol, > detached HTTP signatures, to WGLC > > Oct 2021 - Key presentation mechanism binding to the core protocol, > embedded HTTP signature, to WGLC > > Dec 2021 - Guidelines for use of protocol extension points to WGLC > > Feb 2022 - Guidelines on migration paths, implementation, and operations to > WGLC > > > --------------2690AF39587430BFED08F207 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

The current proposed charter is two pages long, which is far too long, while the OAuth 2.0 charter was half a page long.

We should attempt to make the charter shorter ... and understandable. Hereafter is a full rewording of the charter,
while the justification of its rewording is placed at the very end of this email.

New proposed charter

This group is chartered to develop a fine-grained protocol in a client, authorization server and resource server model,
where a client can request to one or more authorization servers one or more attributes that it needs in order to perform
one or more operations on a resource server, at the time it needs it.

The attributes issued by an authorization server are provided in the form of an attributes token that is cryptographically signed.

The protocol supports attributes tokens usable for multiple operations as well as narrowly as for a single operation.

Since the privacy of the user is a concern, privacy by default and privacy by design are considered.
 
The group is chartered to develop mechanisms for conveying target information and identity information within the protocol
including identity attributes such as pseudonyms, email addresses, user names, home addresses, business addresses, phone numbers,
date of birth, age. When a viable existing format is not available for these attributes, the group is chartered to define such format.

Resource servers inform their clients about which access token formats are acceptable and depending upon the king of operation
that is requested, which kind of attributes are needed and from which ASs that my be obtained.

Through interaction mechanisms supported by the protocol, the resource server allows a user to make a decision whether it is willing or not
to disclose some attributes to perform one or more operations.

This group is not chartered to develop extensions to OAuth 2.0. and as such will focus on new technological solutions not necessarily
compatible with OAuth 2.0.

A major difference with OAuth 2.0 is that there is no bilateral trust relationship between an authorization server and a resource server:
for a given category of attributes, a resource server may trust one or more authorization servers. Another major difference with OAuth 2.0.
is that the content of an attributes token is meant to be accessible to the client.

The group will define interoperable protocols between different parties, including:
  • client and authorization server; and
  • client and resource server.

Milestones to include:

  • Architecture of the model,
  • Attributes token definition, including mechanism bindings
  • Core protocol between the different parties


Justification for the rewording

I have re-used the original text whenever it was adequate and concise.

I also read "Identity in XYZ" from: https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz

The good:

"Rather than returning an ID token with potentially stale or large amounts of user information in the authorization response,
let's return only the minimum necessary for the application to function, and let it request additional information that it needs when it needs it".

Comment: This is a "privacy by default" principle which is indeed important.

The good:

"The value MAY vary for the same user when logging in to different applications in order to preserve the user's privacy,
preventing different applications from cross-correlating users between apps".

Comment: This is a privacy principle which is also indeed important.

The bad:

"The transaction response can include just the unique user identifier along with the access token. (...)
This property is analogous to the "sub" property in an ID token. This value MUST uniquely identify this user within the system,
and MUST be consistent when the same user logs in to the same application".

Comment: This is in contradiction with the previous privacy principle.

I also read https://oauth.xyz/.

The bad:

"In XYZ, a client that needs to talk to an API first begins an authorization transaction with the authorization server".

Comment: IMHO, this workflow scenario is lincorrect. A client that needs to talk to an API first begins a dialog
with ... the resource server. Depending upon the kind of operation the client wants to perform, the resource server informs the client
about the categories of the attributes that are needed and about the authorization servers that are able to issue such attributes.

I also browsed through previous emails from the mailing list:

The bad:

"The client is identified by its key".

Comment : With such a paradigm, key rollover would be either impossible or rather complicated. A client is identified by ... an identifier.
There are diffrent kinds of identifiers whether they are :

     (1) temporarily unique,
     (2) unique to the resource server,
     (3) unique to the authorization server, or
     (4) globally unique.

About the new proposed text of the charter

There is a need to introduce the components of the model and the trust relationships (which are different from those of Auth 2.0 which,
by the way, are not mentioned in the charter).

OAuth 2.0 did not (and still does not) consider privacy as being important. In this BoF/WG, we should consider the user's privacy as being important.

I got rid of the word "delegation": the client does not delegate anything to an authorization server. If it would, this would mean that the authorization server
would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy.

I used the wording "attributes token" in order to make a wording difference with "access token". It is similar (but different) since its content is meant
to be accessible by the client (whereas it is not allowed to be accessible in OAuth 2.0, which makes its content's verification impossible by the user).

An authorization server / resource server protocol has not been explicitly mentioned (but has not been explicitly excluded).
Such a protocol, if it would be related to a client, would come into contradiction with the user's privacy.

Denis Pinkas

DP Security Consulting France

A new IETF WG has been proposed in the Security Area. The IESG has not made
any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list (iesg@ietf.org) by 2020-07-06.

Grant Negotiation and Authorization Protocol (gnap)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Yaron Sheffer <yaronf.ietf@gmail.com>
  Leif Johansson <leifj@sunet.se>

Assigned Area Director:
  Roman Danyliw <rdd@cert.org>

Security Area Directors:
  Benjamin Kaduk <kaduk@mit.edu>
  Roman Danyliw <rdd@cert.org>

Mailing list:
  Address: txauth@ietf.org
  To subscribe: ​https://www.ietf.org/mailman/listinfo/txauth
  Archive: https://mailarchive.ietf.org/arch/browse/txauth/

Group page: https://datatracker.ietf.org/group/gnap/

Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/

This group is chartered to develop a fine-grained delegation protocol for
authorization and API access, as well as requesting and providing user
identifiers and claims. This protocol will allow an authorizing party to
delegate access to client software through an authorization server. It will
expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect
(itself an extension of OAuth 2.0) to support authorizations scoped as
narrowly as a single transaction, provide a clear framework for interaction
among all parties involved in the protocol flow, and remove unnecessary
dependence on a browser or user-agent for coordinating interactions.

The delegation process will be acted upon by multiple parties in the protocol,
each performing a specific role. The protocol will decouple the interaction
channels, such as the end user’s browser, from the delegation channel, which
happens directly between the client and the authorization server (in contrast
with OAuth 2.0, which is initiated by the client redirecting the user’s
browser). The protocol will include a means of specifying how the user can
potentially be involved in an interactive fashion during the delegation
process. The client and Authorization Server (AS) will use these interaction
mechanisms to involve the user, as necessary, to make authorization decisions.
This decoupling avoids many of the security concerns and technical challenges
of OAuth 2.0 and provides a non-invasive path for supporting future types of
clients and interaction channels.

The group will define interoperability for this protocol between different
parties, including
 - client and authorization server;
 - client and resource server; and
 - authorization server and resource server.

The group will seek to minimize assumptions about the form of client
applications, allowing for:
- Fine-grained specification of access
- Approval of AS attestation to identifiers and other identity claims
- Approval of access to multiple resources and APIs in a single interaction
- Support for multiple access tokens in a single request and response
- Support for directed, audience-restricted access tokens
- Separation between the party authorizing access and the party operating the
client requesting access

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
- Mechanisms for conveying user, software, organization, and other
information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource
requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information (including identifiers and
identity assertions) through the delegation process

Additionally, the group will provide mechanisms for management of the protocol
lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Mechanisms for the AS and RS to communicate the access granted by an access
token

Although the artifacts for this work are not intended or expected to be
backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt
to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol
where possible.

This group is not chartered to develop extensions to OAuth 2.0, and as such
will focus on new technological solutions not necessarily compatible with
OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be directed
to the OAuth Working Group, including functionality back-ported from the
protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic
methods, such as JOSE and COSE, to the delegation process. This group is not
chartered to develop new cryptographic methods.

The group is chartered to develop mechanisms for conveying identity
information within the protocol including existing identifiers (such as email
addresses, phone numbers, usernames, and subject identifiers) and assertions
(such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
Credentials). The group is not chartered to develop new formats for
identifiers or assertions, nor is the group chartered to develop schemas for
user information, profiles, or other identity attributes, unless a viable
existing format is not available.

The initial work will focus on using HTTPS for communication between the
client and the authorization server, taking advantage of optimization
features of HTTP/2 and HTTP/3 where possible, and will strive to enable
simple mapping to other protocols such as COAP when doing so does not
conflict with the primary focus.

Milestones to include:
- Core delegation protocol
- Key presentation mechanism bindings to the core protocol including TLS,
detached HTTP signature, and embedded HTTP signatures
- Conveyance mechanisms for identifiers and assertions
- Guidelines for use of protocol extension points
- (if needed) Guidelines on migration paths, implementation, and operations

Where possible, the group will seek to make use of tools to guide and inform
the standardization process including formal analysis, architecture documents,
and use case documents. These artifacts will not be considered as working
group milestones or deliverables.

The working group will cooperate and coordinate with other IETF WGs such as
OAUTH, and work with external organizations, such as the OpenID Foundation,
as appropriate.

Milestones:

  Jul 2021 - Core delegation protocol in WGLC

  Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to
  WGLC

  Oct 2021 - Key presentation mechanism binding to the core protocol, 
  detached HTTP signatures, to WGLC

  Oct 2021 - Key presentation mechanism binding to the core protocol,
  embedded HTTP signature, to WGLC

  Dec 2021 - Guidelines for use of protocol extension points to WGLC

  Feb 2022 - Guidelines on migration paths, implementation, and operations to
   WGLC


--------------2690AF39587430BFED08F207-- From nobody Fri Jun 26 09:44:26 2020 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 4F8E93A096B for ; Fri, 26 Jun 2020 09:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 XE_g_79ksKwn for ; Fri, 26 Jun 2020 09:44:21 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C977A3A082F for ; Fri, 26 Jun 2020 09:44:20 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id x83so1020604oif.10 for ; Fri, 26 Jun 2020 09:44:20 -0700 (PDT) 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=5brbrPt2/oRtl2W/A2HhDLur7tSvq2F/3B7YPPm6m2A=; b=T64/61D6bbG0lKDPQPMExyroe/yBnYbr6BwCfu2qF2ZWvpCVdABgXowcZZ6s/ofFwY bSAViwIbBg7muoDNvG/l0QuNC4r3u7JRKAepDMopCTGP8uAEF5j8MPiMkPV1gVD8O0o2 6AeBZ0wszlgmPn3RP0uYAWgUm9vBXgvsBNC2iz8rwNA049bXYnBbSrSGOpk6IPTiIP7C Wq7GxQHGHXvcwdGlLWtZHwFYfFXUvMocbGjxO78EPhYX6SC+7Xgw7Vi/wgrn46JUKuRw xMCtJFWdP/E60cVr3caA+3Hk20lWWfUMIS4QyC7K+aBxpTerHQ/NuSlnFcDnA0ma1XmT NjXg== 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=5brbrPt2/oRtl2W/A2HhDLur7tSvq2F/3B7YPPm6m2A=; b=UKvY7AwYiOKvR3uaQc+Y6dPCPBqN7AC6kKe+ahg3WR2LuAHT1+Hn5gary6dQ0jjiwL IOmzdouAYby+xG1OLrAyhhObkmDXCcv0Uwu+LIZ/OtZZY6oqIfAAWDFxjSbtxE1ewJlI wDPLGtxK6gMUJnNc4qx83bMW4hIzXJaOWL3d2W5egpqgSBOJVIUKmJo4HNXJGpPOWo7H RCdZ6ZtBZE4ySpQKg7C+FgT+wSpKRGWRGcRX22kMXN3+KzkmYg0LgfaR80yp5RU9sN5T Bk9v2unJPAQZWgc6kGcrudyyotibWj/+wMyRpQKJrMxL4ES9u1B6ii8onUYvbq3cZUb4 JZtg== X-Gm-Message-State: AOAM533JUK9T0YH75byp2c9SqdoZx2JM1vVI3q1YvGfZxQ0R8ksGJD0z llPuuHVil23EA4ZL30tSBro8AsmjeZn94+h/QENkBZnItVc= X-Google-Smtp-Source: ABdhPJzuJPaSYH7+SewU9q6QCLkqaauewnPL+QLMnfyS+W13Tt3ozv4LNSdVzPOaj73oliZVqydOe3k3dWNWxoVGeEA= X-Received: by 2002:aca:280c:: with SMTP id 12mr3206483oix.131.1593189859845; Fri, 26 Jun 2020 09:44:19 -0700 (PDT) MIME-Version: 1.0 References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr> In-Reply-To: <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr> From: Tom Jones Date: Fri, 26 Jun 2020 09:44:05 -0700 Message-ID: To: Denis Cc: Justin Richer , txauth@ietf.org, Tobias Looker Content-Type: multipart/alternative; boundary="000000000000a7e7d205a8ff6ba0" Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 26 Jun 2020 16:44:24 -0000 --000000000000a7e7d205a8ff6ba0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You cannot assume that the rs is in communication with the user/resource owner during the other interchanges. That would not be the case in my implementation. thx ..Tom (mobile) On Fri, Jun 26, 2020, 9:04 AM Denis wrote: > Tom and Justin, > > Why do want to make things complicated when they are quite simple ? > > The statement saying "the as and rs most likely have an ongoing security > context on which to build subsequent interchanges" > would have severe limitations in terms of scalability and privacy. > > The principle where a RS would only have relationships with one AS would > make the model non scalable. > It would prevent to get attributes from two different ASs, for example: > identity attributes from a bank and a master degree diploma from a > university. > > For privacy reasons, every AS should know as little as possible about the > interactions between a client and multiple RSs. > It is even possible that this goes as little as knowing *nothing at all*. > > The OAuth 2.0 assumption where the AS is in a position to know all the > interactions of a given user has with all the RSs > that an AS server has a relationship with should not be re-iterated. > > The relationships between RSs may change at any time and it would not be > reasonable to inform the ASs in real time > about these interactions. > > As already stated in an earlier email: > > No one (including ASs) is able to predict in advance which access tokens > will be needed, since they depend upon the kind of operation(s) > the client will be willing to perform. (...) > > To handle the complex case you envision, the full workflow of operations > needs to be considered with a detailed focus on the time > at which the user's *consent and choice* happens (*consent and choice* is > the first privacy principle from ISO 29100). > > A RS whether the first one of a RS chain and a subsequent one, taking int= o > consideration the kind of operation that will be requested by the client, > should be is able to inform the user about which kind of attributes are > needed and from which AS(s) [note the plural], they may be obtained. > > Denis > > > While there are multiple reasons for bound tokens, each with their own > needs, I strongly encourage an effort to create a single broad spec that > could address the common security issues. Tobias, this is the general ide= a > you were pushing on application level networking. As a general rule, I > believe that the current effort to base security on channel binding has > already been extended beyond its capabilities. (That is the concept that > the HTTPS key is used as the security for the messages.) So, can't we foc= us > on the problem of identifying the participants to an extended set of > interchanges. This would formalize the earlier statements that the as and > rs most likely have an ongoing security context on which to build > subsequent interchanges. > Peace ..tom > > > On Fri, Jun 26, 2020 at 6:23 AM Justin Richer wrote: > >> On Jun 25, 2020, at 9:07 PM, Tobias Looker >> wrote: >> >> >> I find this feature interesting and think it could be an >> important pattern going forward to enable an AS to be able to describe t= he >> utility of a token to the client, however as already pointed out in the >> thread I think there is some potential hidden complexity that would need= to >> be ironed out such that it does not make the simple things complicated. >> >> Justin, do you see this feature as something the client has to explicitl= y >> request, i.e "please give me access and instructions on how to use my >> access" or rather that the AS would just return this information in >> conjunction with the access token if it had it available? >> >> >> This is something that I=E2=80=99d brought up as a possibility on the pr= evious >> thread =E2=80=94 something like a flag the client would set. This would = be >> especially important if the AS wants to return multiple access tokens bu= t >> the client requested 1, or the client requested N and the AS wants to >> return M in response. Basically any time there=E2=80=99s a mismatch, tha= t=E2=80=99s extra >> complexity on the client that I really don=E2=80=99t think we want to be= universal. >> A flag to turn that kind of direction and splitting on would be a potent= ial >> start. But there are potential snags here too, and it comes down to how = you >> manage the defaults... >> >> > This is just the start, too. Things get even more complex if the clien= t >> can ask for multiple different kinds of resources at once. What if the A= S >> decides that the client needs a hyper-focused directed token for one par= t >> of the API, but can use a general token for other stuff? Can it signal t= hat >> to the client? And if it can, does that mean that all clients need to be >> prepared for that kind of thing? >> >> Would a potential default be that if a client did for any reason not >> support processing the additional information returned with the >> access_token, just to ignore it? I think in the spirit of keeping the >> simple things simple, this potentially makes sense? >> >> >> That=E2=80=99s the real trick, if you ask me. It has to be :safe: for a = client to >> ignore this information. Which means the AS can=E2=80=99t rely on the cl= ient =E2=80=9Cdoing >> the right thing=E2=80=9D with the information in the =E2=80=9Ctoken dire= ctions=E2=80=9D portion of >> the response. Even setting aside the advanced and related =E2=80=9Csplit= tokens=E2=80=9D >> idea above, we need to make sure that an AS/RS setup is built such that = if >> the AS tells a client =E2=80=9Conly do X with your token=E2=80=9D and th= e client does =E2=80=9CY=E2=80=9D, >> then there are other protections and practices in place to prevent thing= s >> from going haywire if the client does =E2=80=9CY=E2=80=9D either by acci= dent or through >> ignorance. >> >> If OAuth 2 has taught us anything, it=E2=80=99s that client applications= are >> going to be the laziest participants in the security model. And that mak= es >> sense, really =E2=80=94 security isn=E2=80=99t what the client apps are = trying to do, >> they=E2=80=99re trying to use the RS to do something. So we need to make= sure that >> whatever system we design will fail on the safe side as much as possible= , >> and keep things simple for the client. >> >> >> > here are some worked out samples of this: >> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token >> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ >> Peace ..tom >> >> As one of the authors of those mentioned drafts, I am interested in >> discussing that, but perhaps on a seperate thread? As at least the bound >> assertion spec is primarily concerned with binding mechanisms for the >> artifacts produced from an authorization flow (specifically identity >> claims), whereas I think directed access tokens is just more generally >> talking about whether GNAP should support an AS conveying how to use an >> access_token it produces during a flow with a client. >> >> >> I think that these are separate issues as well. >> >> =E2=80=94 Justin >> >> Thanks, >> [image: Mattr website] >> *Tobias Looker* >> Mattr >> +64 (0) 27 378 0461 >> tobias.looker@mattr.global >> [image: Mattr website] [image: Mattr on LinkedIn= ] >> [image: Mattr on Twitter] >> [image: Mattr on Github] >> >> This communication, including any attachments, is confidential. If you >> are not the intended recipient, you should not read it - please contact = me >> immediately, destroy it, and do not copy or use any part of this >> communication or disclose anything about it. Thank you. Please note that >> this communication does not designate an information system for the >> purposes of the Electronic Transactions Act 2002. >> >> >> On Wed, Jun 24, 2020 at 10:14 PM Denis wrote: >> >>> Justin, I fear we are still far away from an agreement about what this >>> BoF should do. >>> >>> Tom Jones is saying " I am getting tired of the whack-a-mole approach >>> ..." >>> >>> I don't agree with you when you write: "I think it=E2=80=99s going to b= e >>> overwhelmingly common that a given RS is going to trust exactly one AS >>> that it knows about ahead of time". Such an architecture would have >>> exactly the same limitations as OAuth 2.0. and would not be scalable. >>> >>> Before we start, we should have a clear view of the whole picture rathe= r >>> than starting from one scenario and expanding it in many different >>> directions. >>> For building an architecture, a pre-requirement is to define ALL the >>> trust relationships. I don't believe that we have an agreement at this = time >>> on what >>> these trust relationships are. >>> >>> You are also using the following wording: "methods for the AS and RS to >>> communicate what the token=E2=80=99s good for". >>> With such a paradigm, it would be impossible to protect the user's >>> privacy. >>> >>> A key question is : Will GNAP take care of the user's privacy or will >>> GNAP *prevent *to take care of the user's privacy ? >>> >>> About "the ability for the client to get several access tokens to get >>> different resources from one request" is indeed a complex case. >>> >>> No one (including ASs) is able to predict in advance which access token= s >>> will be needed, since they depend upon the kind of operation(s) >>> the client will be willing to perform. For privacy reasons, ASs should >>> be kept ignorant of all the operations that a client is going to perfor= m >>> on one or more resource servers. I believe that every effort should be >>> made to avoid the AS to be in a position to be able to trace the operat= ions >>> performed by its clients on various RSs. >>> >>> To handle the complex case you envision, the full workflow of operation= s >>> needs to be considered with a detailed focus on the time >>> at which the user's *consent and choice* happens (*consent and choice* >>> is the first privacy principle from ISO 29100). >>> >>> First of all, an access token could be targeted to a service rather tha= n >>> to a server. This would already solve many cases. >>> >>> When a RS needs to call another RS (which does not support the same >>> service) then the client should be informed by the first RS. >>> His "consent and choice" should then be obtained by the first RS and, >>> when the user agrees, the client should then ask an access token >>> to one of the ASs trusted by the second RS in order to perform the >>> subsequent operation. >>> >>> Denis >>> >>> PS. In an email sent on June 23 you wrote: " I think an on-device AS i= s >>> an important use case". I am sorry, but I don't understand. >>> However, I do understand what "a server-based AS" is. >>> >>> >>> Denis, thanks for the great comments. I think that your trust model is >>> pretty different from what I=E2=80=99d laid out initially, and while it= =E2=80=99s an >>> interesting and important one, it is not what I meant by =E2=80=9Cmulti= ple access >>> tokens=E2=80=9D in my discussion below. I think that might be the cause= of some >>> disconnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of reac= h for what the WG is >>> after. >>> >>> When I refer to multiple access tokens, and what the charter calls out >>> as multiple access tokens, is the ability for the client to get several >>> access tokens to get different resources from one request. I personally= see >>> this as an optimization of a specific set of use cases, some of which I >>> discussed in my original email. There are others, I=E2=80=99m sure, but= all the >>> ones I=E2=80=99ve seen are around the client needing to get several dif= ferent kinds >>> of access through an AS. >>> >>> I think it=E2=80=99s going to be overwhelmingly common that a given RS = is going >>> to trust exactly one AS that it knows about ahead of time. But for RS= =E2=80=99s >>> that can trust multiple AS=E2=80=99s, then we should have a model that = can >>> accommodate that as well. That=E2=80=99s why the charter calls out meth= ods for the >>> AS and RS to communicate what the token=E2=80=99s good for. I think the= basis of >>> those methods is going to start with a common token model, and likely >>> incorporate into things like token formats and introspection-style toke= n >>> APIs. >>> >>> =E2=80=94 Justin >>> >>> On Jun 22, 2020, at 3:55 AM, Denis wrote: >>> >>> Hello Justin, >>> >>> A few comments between the lines. >>> >>> One of the most important aspects to GNAP is going to be an ability to >>> address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t do= without significant >>> gymnastics. So with that, I wanted to bring back a use case discussion = that >>> originally came up while we were talking about the possibility of multi= ple >>> access tokens, a few months back. I don=E2=80=99t know if this concept = has a >>> regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access = tokens=E2=80=9D until we >>> come up with something better =E2=80=94 assuming we decide this is wort= hwhile. >>> >>> I don't understand what may mean "directed access tokens=E2=80=9D but I >>> understand what means "multiple access tokens". >>> When speaking of "multiple access tokens", these access tokens may come >>> from one or more ASs. >>> >>> In OAuth, the client=E2=80=99s supposed to always know where to send it= s access >>> token, and that knowledge is completely outside the protocol. This make= s a >>> lot of sense for many (if not most) deployments, as OAuth is really the= re >>> to enable the API access that the client already knows about. >>> >>> But we=E2=80=99re now in a world where a client could be talking to a g= eneric >>> API that could be deployed at a number of different places, or a cloud >>> deployment that the AS wants to be able to dispatch the client to. >>> >>> As soon the AS is placed (again) at the centre of the model, the AS wil= l >>> have the ability to act as "Big Brother". >>> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP >>> should take care of them. >>> >>> In order to do this, the AS needs to be able to communicate to the >>> client not only the token information (and any related key and presenta= tion >>> information), but also a set of *directions* about what that specific >>> token is good for. This needs to be information outside the token itsel= f, >>> since I believe we want to keep OAuth 2=E2=80=99s feature of having the= token be >>> opaque to the client. Note: while we could map all of these to differen= t >>> resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlan= ce) >>> on the request side, this isn=E2=80=99t enough to tell the client what = to do with >>> the token *if it doesn=E2=80=99t know already*. >>> >>> I know of two use cases already in the wild, where people are addressin= g >>> things using a mix of existing standards and some proprietary extension= s to >>> address things within their silos. I=E2=80=99ll try to summarize here, = but I know >>> the folks I=E2=80=99ve been talking to about this are also on the list = so hopefully >>> they can chime in with more detail or any corrections for something I= =E2=80=99ve >>> missed. >>> >>> (1) The client knows what resource it=E2=80=99s calling, but it doesn= =E2=80=99t know >>> where it=E2=80=99s hosted. Everything is in a single security domain co= ntrolled by >>> the AS, >>> >>> Speaking of "multiple access tokens" is in contradiction with single >>> security domain "controlled" by an AS. >>> A user may need to demonstrate some of his identity attributes granted >>> e.g. by his bank but may also >>> need to demonstrate one or more diplomas granted by one or more >>> universities. The bank cannot be >>> the "primary issuer" of a university diploma. It should not be either a >>> "secondary issuer", because >>> the bank does not "*need to know"* what are the diplomas of the user. >>> >>> but the AS needs to decide at runtime which specific instance of the AP= I >>> to direct the client to. Since things are closely tied together, the cl= ient >>> just needs to effectively known an identifier for the RS, and this is >>> currently implemented as a URI. Once the client has that identifier, it >>> knows how to dispatch that token to that instance of the RS. >>> >>> There is no good reason why the AS should be involved in that step. >>> OAuth 2.0 is/was implicitly mandating a strong relationship between ASs >>> and RSs which makes it non scalable. >>> GNAP should be based on a simple trust relationship : a given RS trusts >>> some ASs for access tokens that contains some types of attributes. >>> An AS should not need to know in advance (or even at the time of an >>> access token request) the RSs that are trusting it. >>> >>> A client could first talk to a "global service provider" which has the >>> knowledge of the different RSs affiliated to it. >>> >>> (2) The client knows what kind of thing it=E2=80=99s looking for, but d= oesn=E2=80=99t >>> know who to ask it from. >>> >>> Once again, the client could first talk to a "global service provider" >>> which has the knowledge of the different RSs affiliated to it. >>> >>> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS, = and the AS needs >>> to dispatch to different resources depending on which user logged in (a= nd >>> possibly what the user consented to). To make things more concrete, the >>> client needs to get driver=E2=80=99s license information, but doesn=E2= =80=99t know ahead of >>> time which of the many state/provincial bureaus to call to get that >>> information because it doesn=E2=80=99t know yet who the user is. >>> >>> When a user has a driving license, he knows its issuer. The user can >>> then provide some hint to the client. >>> >>> The AS will know who the user is once they log in and approve things, >>> and so it can direct the client to call the correct RS. Since this is a >>> relatively simple API with a pre-negotiated cross-domain trust, the AS >>> returns a URL that the client presents the token at. >>> >>> A single AS should not be aware of all the attributes a user has. >>> >>> >>> As far as I know, in both of these cases, the token is only good for >>> that API and not others =E2=80=94 but more on that later. >>> >>> A simple thing to do is just give back a URL with the access token, >>> which tells the client where to go. >>> >>> { >>> =E2=80=9Caccess_token=E2=80=9D: { >>> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D, >>> =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo" >>> } >>> } >>> >>> This is good for some kinds of APIs, but it=E2=80=99s limiting because = not all >>> APIs dispatch based on the URL. An AS might want to divvy up access tok= ens >>> to an API that=E2=80=99s keyed on headers, or verbs, or any number of t= hings. And >>> it doesn=E2=80=99t tell us immediately what to do about non-exact URL m= atches. Can >>> the client add query parameters and still use the token? What about pat= h >>> segments? I like that this simple approach addresses some common >>> deployments that we already see today (see above), it=E2=80=99s not uni= versal. Do >>> we want or need a universal description language for directing where to= kens >>> go? >>> >>> This also opens up a whole new set of security questions. If the AS can >>> now direct the client where to use the token, could a rogue AS convince= a >>> legit client to use a stolen token at the wrong RS? And what if the cli= ent >>> ignores the directions from the AS entirely? Could this open up new ave= nues >>> of attack? >>> >>> This is just the start, too. Things get even more complex if the client >>> can ask for multiple different kinds of resources at once. What if the = AS >>> decides that the client needs a hyper-focused directed token for one pa= rt >>> of the API, but can use a general token for other stuff? Can it signal = that >>> to the client? And if it can, does that mean that all clients need to b= e >>> prepared for that kind of thing? >>> >>> I firmly believe that whatever we build in GNAP, we need to optimize fo= r >>> the overwhelmingly common use case of a client getting a single access >>> token to call APIs that it already knows about. Anything we add on top = of >>> that really can=E2=80=99t get in the way of this, because if it does, t= here=E2=80=99s very >>> small chance that people will try to use this for everyday things. Keep= the >>> simple things simple, and the complex things possible, after all. >>> >>> I=E2=80=99m really looking forward to hearing what the community thinks= about >>> these use cases, and hopefully the people I=E2=80=99ve chatted with off= line about >>> this can join the conversation and provide more light than I was able t= o. >>> >>> The two use cases which are considered above are: >>> >>> (1) The client knows what resource it=E2=80=99s calling, but it doesn= =E2=80=99t know >>> where it=E2=80=99s hosted. >>> (2) The client knows what kind of thing it=E2=80=99s looking for, but d= oesn=E2=80=99t >>> know who to ask it from. >>> >>> That does not mean in any way that these two use cases should be solved >>> by placing the AS at the centre of the solution. >>> >>> Denis >>> >>> >>> =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 >>> >> >> This communication, including any attachments, is confidential. If you a= re not the intended recipient, you should not read it - please contact me i= mmediately, destroy it, and do not copy or use any part of this communicati= on or disclose anything about it. Thank you. Please note that this communic= ation does not designate an information system for the purposes of the Elec= tronic Transactions Act 2002. >> >> >> -- >> 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 > --000000000000a7e7d205a8ff6ba0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You cannot assume that the rs is in communication with th= e user/resource owner during the other interchanges. That would not be the = case in my implementation.

t= hx ..Tom (mobile)

On Fri, Jun 26, 2020, 9:04 AM Denis <denis.ietf@free.fr> wrote:
=20 =20 =20
Tom and Justin,

Why do want to make things complicated when they are quite simple ?

The statement saying "the as and rs most likely have an ongoing=C2=A0security context on which to build subsequent interchanges"
would have severe limitations in terms of scalability and privacy.

The principle where a RS would only have relationships with one AS would make the model non scalable.
It would prevent to get attributes from two different ASs,=C2=A0 for example:=C2=A0
identity attributes from a bank and a master degree diploma from a university.

For privacy reasons, every AS should know as little as possible about the interactions between a client and multiple RSs.
It is even possible that this goes as little as knowing nothing at all.

The OAuth 2.0 assumption where the AS is in a position to know all the interactions of a given user has with all the RSs
that an AS server has a relationship with should not be re-iterated.

The relationships between RSs may change at any time and it would not be reasonable to inform the ASs in real time
about these interactions.

As already stated in an earlier email:
No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. (...)

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (con= sent and choice is the first privacy principle from ISO 29100).
A RS whether the first one of a RS chain and a subsequent one, taking into consideration the kind of operation that will be requested by the client,
should be is able to inform the user about which kind of attributes are needed and from which AS(s) [note the plural], they may be obtained.

Denis


=20
While there are multiple reasons for bound tokens, each with their own needs, I strongly encourage an effort to create a single broad spec that could address the common security issues. Tobias, this is the general idea you were pushing on application level networking. As a general rule, I believe=C2=A0that the current effort to base security on channel binding has already been extended beyond=C2=A0its capabilities. (Th= at is the concept that the HTTPS key is used as the security for the messages.) So, can't we focus on the problem of identifying the participants to an extended set of interchanges. This would formalize the earlier statements that the as and rs most likely have an ongoing=C2=A0security context on which to build subsequent interchanges.
Peace ..tom


On Fri, Jun 26, 2020 at 6:23 AM Justin Richer <jricher@mit.edu> wrote:
On Jun 25, 2020, at 9:07 PM, Tobias Looker <tobias.looker@mattr.global> wrote:

I find this feature interesting and think it could be an important=C2=A0pattern going=C2=A0= forward to enable an AS to be able to describe the utility of a token to the client, however as already pointed out in the thread I think there is some potential hidden complexity that would need to be ironed out such that it does not make the simple things complicated.

Justin, do you see this feature as something the client has to explicitly request, i.e "pleas= e give me access and instructions on how to use my access" or rather that the AS would just return this information in conjunction with the access token if it had it available?


This is something that I=E2=80=99d brought up as a possibility on the previous thread =E2=80=94 something like= a flag the client would set. This would be especially important if the AS wants to return multiple access tokens but the client requested 1, or the client requested N and the AS wants to return M in response. Basically any time there=E2=80=99s a mismatch, that=E2=80= =99s extra complexity on the client that I really don=E2=80=99t think = we want to be universal. A flag to turn that kind of direction and splitting on would be a potential start. But there are potential snags here too, and it comes down to how you manage the defaults...

> This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

Would a potential default be that if a client did for any reason not support processing the additional information returned with the access_token, just to ignore it? I think in the spirit of keeping the simple things simple, this potentially makes sense?

That=E2=80=99s the real trick, if you ask me. It has to = be :safe: for a client to ignore this information. Which means the AS can=E2=80=99t rely on the client =E2=80=9Cdoin= g the right thing=E2=80=9D with the information in the =E2=80=9Ctoken d= irections=E2=80=9D portion of the response. Even setting aside the advanced and related =E2=80=9Csplit tokens=E2=80=9D idea above, we n= eed to make sure that an AS/RS setup is built such that if the AS tells a client =E2=80=9Conly do X with your token=E2=80=9D = and the client does =E2=80=9CY=E2=80=9D, then there are other prote= ctions and practices in place to prevent things from going haywire if the client does =E2=80=9CY=E2=80=9D either by accident o= r through ignorance.=C2=A0

If OAuth 2 has taught us anything, it=E2=80=99s that cli= ent applications are going to be the laziest participants in the security model. And that makes sense, really =E2=80=94 security isn=E2=80=99t what the client apps are trying to d= o, they=E2=80=99re trying to use the RS to do something. So we= need to make sure that whatever system we design will fail on the safe side as much as possible, and keep things simple for the client.


> here are some worked out samples of this:
Peace ..tom

As one of the authors of those mentioned drafts, I am interested in discussing that, but perhaps on a seperate thread? As at least=C2=A0the bound assertion spec is=C2=A0primarily=C2=A0concerned with binding mechanisms for the artifacts produced from an authorization flow (specifically identity claims), whereas I think directed access tokens is just more generally talking about whether GNAP should support an AS conveying how to use an access_token it produces during a flow with a client.


I think that these are separate issues as well.

=C2=A0=E2=80=94 Justin

Thanks,
3D"Mattr =C2=A0
Tobias Looker
Ma= ttr
+64 (0) 27 378 0461
tobias.looker@mattr.global
3D"Mattr 3D"Mattr 3D"Mattr

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Wed, Jun 24, 2020 at 10:14 PM Denis <denis.ietf@free.fr> wrote:
Justin, I fear we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I am getting tired = of the whack-a-mole approach ..."

I don't agree with you when you write: "I = think it=E2=80=99s going to be overwhelmingly common that= a given RS is going to trust exactly one AS
that it knows about ahead of time". Such = an architecture would have exactly the same limitations as OAuth 2.0. and would not be scalable.

Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions.
For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believe that we have an agreement at this time on what
these trust relationships are.

You are also using the following wording: "methods for the AS and RS to communicate wh= at the token=E2=80=99s good for".
With such a paradigm, it would be impossible to protect the user's privacy.

A key question is : Will GNAP take care of the user's privacy or will GNAP prevent to take care of the user's privacy ?

About "the ability for the client to get several access tokens to get different resources from one request" is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform
on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).

First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases.

When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS.
His "consent and choice" should then= be obtained by the first RS and, when the user agrees, the client should then ask an access token
to one of the ASs trusted by the second RS in order to perform the subsequent operation.=C2=A0 =

Denis

PS.=C2=A0 In an email sent on June 23 you wrot= e: " I think an on-device AS is an important us= e case".=C2=A0 I am sorry, but I don't und= erstand.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 However, I d= o understand what "a server-based AS" is.


Denis, thanks for the great comments. I think that your trust model is pretty different from what I=E2=80=99d laid ou= t initially, and while it=E2=80=99s an interesting = and important one, it is not what I meant by =E2=80=9Cmultiple access tokens=E2=80=9D in my di= scussion below. I think that might be the cause of some disconnect here, but that doesn=E2=80=99t mean it= =E2=80=99s out of reach for what the WG is after.

When I refer to multiple access tokens, and what the charter calls out as multiple access tokens, is the ability for the client to get several access tokens to get different resources from one request. I personally see this as an optimization of a specific set of use cases, some of which I discussed in my original email. There are others, I=E2=80=99m sure, but all the ones I=E2= =80=99ve seen are around the client needing to get several different kinds of access through an AS.=C2=A0<= br>

I think it=E2=80=99s going to be overwhelm= ingly common that a given RS is going to trust exactly one AS that it knows about ahead of time. But for RS=E2=80=99s that can trust multiple AS=E2=80=99s, then we should have a = model that can accommodate that as well. That=E2=80= =99s why the charter calls out methods for the AS and RS to communicate what the token=E2=80= =99s good for. I think the basis of those methods is going to start with a common token model, and likely incorporate into things like token formats and introspection-style token APIs.=C2=A0

=C2=A0=E2=80=94 Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the lines.

One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can=E2=80= =99t, or at least can=E2=80=99t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don=E2=80=99t know if this concept = has a regular term, so I=E2=80=99m going to= call it =E2=80=9Cdirected access tokens=E2= =80=9D until we come up with something better =E2= =80=94 assuming we decide this is worthwhile.=C2=A0

I don't understand what may mean "directed access tokens=E2=80=9D= but I understand what means "multiple access tokens".=C2=A0
When speaking of "multiple acces= s tokens", these access tokens may come from one or more ASs.

In OAuth, the client=E2=80=99s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we=E2=80=99re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.=C2=A0

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of=C2=A0directions=C2=A0about what that specific token is good for. This needs to be information outside the token itself, since I=C2=A0believe we wan= t to keep OAuth 2=E2=80=99s feature o= f having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t enough to = tell the client what to do with the token=C2=A0if it doesn=E2=80=99t know already.= =C2=A0

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I=E2=80=99ll tr= y to summarize here, but I know the folks I=E2=80=99ve been talking to = about this are also on the list so hopefully they can chime in with more detail or any corrections for something I=E2=80=99ve missed.= =C2=A0

(1) The client knows what resource it=E2=80=99s calling, but = it doesn=E2=80=99t know where it=E2=80= =99s hosted. Everything is in a single security domain controlled by the AS,=C2=A0

Speaking of "multiple access tokens"= is in contradiction with single security domain "controlled" by an A= S.=C2=A0
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also=C2=A0
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be=C2=A0
the "primary issuer" of a university diploma. It should not be either a "secondary issuer&qu= ot;, because=C2=A0
the bank does not "need to know"=C2=A0wh= at are the diplomas of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved in that step.=C2=A0
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" w= hich has the knowledge of the different RSs affiliated to it.=C2=A0

(2) The client knows what kind of thing it=E2=80=99s looking = for, but doesn=E2=80=99t know who to ask= it from.=C2=A0

Once again, the client could first talk to a "global service provider&qu= ot; which has the knowledge of the different RSs affiliated to it.= =C2=A0

There=E2=80=99s a cross-domain t= rust that=E2=80=99s bridged by the AS, a= nd the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver=E2=80=99s license information, but doesn=E2=80=99t kn= ow ahead of time which of the many state/provincial bureaus to call to get that information because it doesn=E2=80=99t know yet who the= user is.=C2=A0

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at.=C2=A0<= /span>

=C2=A0A single AS should not be aware of all the attributes a user has.= =C2=A0


As far as I know, in both of these cases, the token is only good for that API and not others =E2=80=94 but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go.=C2=A0

{
=E2=80=9Caccess_token=E2=80=9D: {
=E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D,
=E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo"
}
}

This is good for some kinds of APIs, but it=E2=80=99s limiting because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that=E2=80=99s keyed on headers, or verbs, or any number of things. And it doesn=E2=80=99t t= ell us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it=E2=80=99s not universal. Do we w= ant or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can=E2=80=99t get in the way of thi= s, because if it does, there=E2=80=99s= very small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I=E2=80=99m really looking forwa= rd to hearing what the community thinks about these use cases, and hopefully the people I=E2=80=99= ve chatted with offline about this can join the conversation and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what resource it=E2=80=99s calling, but = it doesn=E2=80=99t know where it=E2=80= =99s hosted.
(2) The client knows what kind of thing it=E2=80=99s looking for, = but doesn=E2=80=99t know who to ask it = from.=C2=A0

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Denis


=C2=A0=E2=80=94 Justin


--=C2=A0
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mail= man/listinfo/txauth


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

This communication=
, including any attachments, is confidential. If you are not the intended r=
ecipient, you should not read it - please contact me immediately, destroy i=
t, and do not copy or use any part of this communication or disclose anythi=
ng about it. Thank you. Please note that this communication does not design=
ate an information system for the purposes of the Electronic Transactions A=
ct 2002.

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


--
Txauth mailing list
Txa= uth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth<= /a>
--000000000000a7e7d205a8ff6ba0-- From nobody Fri Jun 26 09:51:51 2020 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 D13203A0BB6 for ; Fri, 26 Jun 2020 09:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 fUrfe1YUI2an for ; Fri, 26 Jun 2020 09:51:44 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85DD43A0BA9 for ; Fri, 26 Jun 2020 09:51:43 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d18 with ME id vsrh2200L4FMSmm03srhf5; Fri, 26 Jun 2020 18:51:41 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 26 Jun 2020 18:51:41 +0200 X-ME-IP: 86.238.65.197 To: Tom Jones Cc: Justin Richer , txauth@ietf.org, Tobias Looker References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr> From: Denis Message-ID: <4fab6b2b-c860-350e-476b-60372dd946c3@free.fr> Date: Fri, 26 Jun 2020 18:51:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------79C241DC4558E8DD4403618D" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 26 Jun 2020 16:51:50 -0000 This is a multi-part message in MIME format. --------------79C241DC4558E8DD4403618D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Tom, Should I understand that you are willing to rubber-stamp an existing implementation ? Since we are not yet a WG, it is not my understanding that it is what a WG should attempt to do. Denis > You cannot assume that the rs is in communication with the > user/resource owner during the other interchanges. That would not be > the case in my implementation. > > thx ..Tom (mobile) > > On Fri, Jun 26, 2020, 9:04 AM Denis > wrote: > > Tom and Justin, > > Why do want to make things complicated when they are quite simple ? > > The statement saying "the as and rs most likely have an > ongoing security context on which to build subsequent interchanges" > would have severe limitations in terms of scalability and privacy. > > The principle where a RS would only have relationships with one AS > would make the model non scalable. > It would prevent to get attributes from two different ASs,  for > example: > identity attributes from a bank and a master degree diploma from a > university. > > For privacy reasons, every AS should know as little as possible > about the interactions between a client and multiple RSs. > It is even possible that this goes as little as knowing /nothing > at all/. > > The OAuth 2.0 assumption where the AS is in a position to know all > the interactions of a given user has with all the RSs > that an AS server has a relationship with should not be re-iterated. > > The relationships between RSs may change at any time and it woauld > not be reasonable to inform the ASs in real time > about these interactions. > > As already stated in an earlier email: > > No one (including ASs) is able to predict in advance which > access tokens will be needed, since they depend upon the kind > of operation(s) > the client will be willing to perform. (...) > > To handle the complex case you envision, the full workflow of > operations needs to be considered with a detailed focus on the > time > at which the user's *consent and choice* happens (/consent and > choice/ is the first privacy principle from ISO 29100). > > A RS whether the first one of a RS chain and a subsequent one, > taking into consideration the kind of operation that will be > requested by the client, > should be is able to inform the user about which kind of > attributes are needed and from which AS(s) [note the plural], they > may be obtained. > > Denis > > >> While there are multiple reasons for bound tokens, each with >> their own needs, I strongly encourage an effort to create a >> single broad spec that could address the common security issues. >> Tobias, this is the general idea you were pushing on application >> level networking. As a general rule, I believe that the current >> effort to base security on channel binding has already been >> extended beyond its capabilities. (That is the concept that the >> HTTPS key is used as the security for the messages.) So, can't we >> focus on the problem of identifying the participants to an >> extended set of interchanges. This would formalize the earlier >> statements that the as and rs most likely have an >> ongoing security context on which to build subsequent interchanges. >> Peace ..tom >> >> >> On Fri, Jun 26, 2020 at 6:23 AM Justin Richer > > wrote: >> >> On Jun 25, 2020, at 9:07 PM, Tobias Looker >> > > wrote: >>> >>> I find this feature interesting and think it could be an >>> important pattern going forward to enable an AS to be able >>> to describe the utility of a token to the client, however as >>> already pointed out in the thread I think there is some >>> potential hidden complexity that would need to be ironed out >>> such that it does not make the simple things complicated. >>> >>> Justin, do you see this feature as something the client has >>> to explicitly request, i.e "please give me access and >>> instructions on how to use my access" or rather that the AS >>> would just return this information in conjunction with the >>> access token if it had it available? >>> >> >> This is something that I’d brought up as a possibility on the >> previous thread — something like a flag the client would set. >> This would be especially important if the AS wants to return >> multiple access tokens but the client requested 1, or the >> client requested N and the AS wants to return M in response. >> Basically any time there’s a mismatch, that’s extra >> complexity on the client that I really don’t think we want to >> be universal. A flag to turn that kind of direction and >> splitting on would be a potential start. But there are >> potential snags here too, and it comes down to how you manage >> the defaults... >> >>> > This is just the start, too. Things get even more complex >>> if the client can ask for multiple different kinds of >>> resources at once. What if the AS decides that the client >>> needs a hyper-focused directed token for one part of the >>> API, but can use a general token for other stuff? Can it >>> signal that to the client? And if it can, does that mean >>> that all clients need to be prepared for that kind of thing? >>> >>> Would a potential default be that if a client did for any >>> reason not support processing the additional information >>> returned with the access_token, just to ignore it? I think >>> in the spirit of keeping the simple things simple, this >>> potentially makes sense? >> >> That’s the real trick, if you ask me. It has to be :safe: for >> a client to ignore this information. Which means the AS can’t >> rely on the client “doing the right thing” with the >> information in the “token directions” portion of the >> response. Even setting aside the advanced and related “split >> tokens” idea above, we need to make sure that an AS/RS setup >> is built such that if the AS tells a client “only do X with >> your token” and the client does “Y”, then there are other >> protections and practices in place to prevent things from >> going haywire if the client does “Y” either by accident or >> through ignorance. >> >> If OAuth 2 has taught us anything, it’s that client >> applications are going to be the laziest participants in the >> security model. And that makes sense, really — security isn’t >> what the client apps are trying to do, they’re trying to use >> the RS to do something. So we need to make sure that whatever >> system we design will fail on the safe side as much as >> possible, and keep things simple for the client. >> >>> >>> > here are some worked out samples of this: >>> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token >>> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ >>> Peace ..tom >>> >>> As one of the authors of those mentioned drafts, I am >>> interested in discussing that, but perhaps on a seperate >>> thread? As at least the bound assertion spec >>> is primarily concerned with binding mechanisms for the >>> artifacts produced from an authorization flow (specifically >>> identity claims), whereas I think directed access tokens is >>> just more generally talking about whether GNAP should >>> support an AS conveying how to use an access_token it >>> produces during a flow with a client. >>> >> >> I think that these are separate issues as well. >> >>  — Justin >> >>> Thanks, >>> Mattr website >>> *Tobias Looker* >>> Mattr >>> +64 (0) 27 378 0461 >>> tobias.looker@mattr.global >>> Mattr website Mattr on LinkedIn >>> Mattr on >>> Twitter Mattr on Github >>> >>> >>> >>> This communication, including any attachments, is >>> confidential. If you are not the intended recipient, you >>> should not read it - please contact me immediately, destroy >>> it, and do not copy or use any part of this communication or >>> disclose anything about it. Thank you. Please note that this >>> communication does not designate an information system for >>> the purposes of the Electronic Transactions Act 2002. >>> >>> >>> On Wed, Jun 24, 2020 at 10:14 PM Denis >> > wrote: >>> >>> Justin, I fear we are still far away from an agreement >>> about what this BoF should do. >>> >>> Tom Jones is saying " I am getting tired of the >>> whack-a-mole approach ..." >>> >>> I don't agree with you when you write: "I think it’s >>> going to be overwhelmingly common that a given RS is >>> going to trust exactly one AS >>> that it knows about ahead of time". Such an architecture >>> would have exactly the same limitations as OAuth 2.0. >>> and would not be scalable. >>> >>> Before we start, we should have a clear view of the >>> whole picture rather than starting from one scenario and >>> expanding it in many different directions. >>> For building an architecture, a pre-requirement is to >>> define ALL the trust relationships. I don't believe that >>> we have an agreement at this time on what >>> these trust relationships are. >>> >>> You are also using the following wording: "methods for >>> the AS and RS to communicate what the token’s good for". >>> With such a paradigm, it would be impossible to protect >>> the user's privacy. >>> >>> A key question is : Will GNAP take care of the user's >>> privacy or will GNAP *prevent *to take care of the >>> user's privacy ? >>> >>> About "the ability for the client to get several access >>> tokens to get different resources from one request" is >>> indeed a complex case. >>> >>> No one (including ASs) is able to predict in advance >>> which access tokens will be needed, since they depend >>> upon the kind of operation(s) >>> the client will be willing to perform. For privacy >>> reasons, ASs should be kept ignorant of all the >>> operations that a client is going to perform >>> on one or more resource servers. I believe that every >>> effort should be made to avoid the AS to be in a >>> position to be able to trace the operations >>> performed by its clients on various RSs. >>> >>> To handle the complex case you envision, the full >>> workflow of operations needs to be considered with a >>> detailed focus on the time >>> at which the user's *consent and choice* happens >>> (/consent and choice/ is the first privacy principle >>> from ISO 29100). >>> >>> First of all, an access token could be targeted to a >>> service rather than to a server. This would already >>> solve many cases. >>> >>> When a RS needs to call another RS (which does not >>> support the same service) then the client should be >>> informed by the first RS. >>> His "consent and choice" should then be obtained by the >>> first RS and, when the user agrees, the client should >>> then ask an access token >>> to one of the ASs trusted by the second RS in order to >>> perform the subsequent operation. >>> >>> Denis >>> >>> PS.  In an email sent on June 23 you wrote: " I think an >>> on-device AS is an important use case".  I am sorry, but >>> I don't understand. >>>        However, I do understand what "a server-based AS" is. >>> >>> >>>> Denis, thanks for the great comments. I think that your >>>> trust model is pretty different from what I’d laid out >>>> initially, and while it’s an interesting and important >>>> one, it is not what I meant by “multiple access tokens” >>>> in my discussion below. I think that might be the cause >>>> of some disconnect here, but that doesn’t mean it’s out >>>> of reach for what the WG is after. >>>> >>>> When I refer to multiple access tokens, and what the >>>> charter calls out as multiple access tokens, is the >>>> ability for the client to get several access tokens to >>>> get different resources from one request. I personally >>>> see this as an optimization of a specific set of use >>>> cases, some of which I discussed in my original email. >>>> There are others, I’m sure, but all the ones I’ve seen >>>> are around the client needing to get several different >>>> kinds of access through an AS. >>>> >>>> I think it’s going to be overwhelmingly common that a >>>> given RS is going to trust exactly one AS that it knows >>>> about ahead of time. But for RS’s that can trust >>>> multiple AS’s, then we should have a model that can >>>> accommodate that as well. That’s why the charter calls >>>> out methods for the AS and RS to communicate what the >>>> token’s good for. I think the basis of those methods is >>>> going to start with a common token model, and likely >>>> incorporate into things like token formats and >>>> introspection-style token APIs. >>>> >>>>  — Justin >>>> >>>>> On Jun 22, 2020, at 3:55 AM, Denis >>>> > wrote: >>>>> >>>>> Hello Justin, >>>>> >>>>> A few comments between the lines. >>>>> >>>>>> One of the most important aspects to GNAP is going to >>>>>> be an ability to address things that OAuth 2 can’t, >>>>>> or at least can’t do without significant gymnastics. >>>>>> So with that, I wanted to bring back a use case >>>>>> discussion that originally came up while we were >>>>>> talking about the possibility of multiple access >>>>>> tokens, a few months back. I don’t know if this >>>>>> concept has a regular term, so I’m going to call it >>>>>> “directed access tokens” until we come up with >>>>>> something better — assuming we decide this is worthwhile. >>>>> >>>>> I don't understand what may mean "directed access >>>>> tokens” but I understand what means "multiple access >>>>> tokens". >>>>> When speaking of "multiple access tokens", these >>>>> access tokens may come from one or more ASs. >>>>> >>>>>> In OAuth, the client’s supposed to always know where >>>>>> to send its access token, and that knowledge is >>>>>> completely outside the protocol. This makes a lot of >>>>>> sense for many (if not most) deployments, as OAuth is >>>>>> really there to enable the API access that the client >>>>>> already knows about. >>>>>> >>>>>> But we’re now in a world where a client could be >>>>>> talking to a generic API that could be deployed at a >>>>>> number of different places, or a cloud deployment >>>>>> that the AS wants to be able to dispatch the client to. >>>>> >>>>> As soon the AS is placed (again) at the centre of the >>>>> model, the AS will have the ability to act as "Big >>>>> Brother". >>>>> OAuth 2.0 has not taken care of privacy issues. On the >>>>> contrary, GNAP should take care of them. >>>>> >>>>>> In order to do this, the AS needs to be able to >>>>>> communicate to the client not only the token >>>>>> information (and any related key and presentation >>>>>> information), but also a set of/directions/ about >>>>>> what that specific token is good for. This needs to >>>>>> be information outside the token itself, since >>>>>> I believe we want to keep OAuth 2’s feature of having >>>>>> the token be opaque to the client. Note: while we >>>>>> could map all of these to different resource requests >>>>>> (in XYZ parlance) or scopes (in OAuth 2 legacy >>>>>> parlance) on the request side, this isn’t enough to >>>>>> tell the client what to do with the token/if it >>>>>> doesn’t know already/. >>>>>> >>>>>> I know of two use cases already in the wild, where >>>>>> people are addressing things using a mix of existing >>>>>> standards and some proprietary extensions to address >>>>>> things within their silos. I’ll try to summarize >>>>>> here, but I know the folks I’ve been talking to about >>>>>> this are also on the list so hopefully they can chime >>>>>> in with more detail or any corrections for something >>>>>> I’ve missed. >>>>>> >>>>>> (1) The client knows what resource it’s calling, but >>>>>> it doesn’t know where it’s hosted. Everything is in a >>>>>> single security domain controlled by the AS, >>>>> >>>>> Speaking of "multiple access tokens" is in >>>>> contradiction with single security domain "controlled" >>>>> by an AS. >>>>> A user may need to demonstrate some of his identity >>>>> attributes granted e.g. by his bank but may also >>>>> need to demonstrate one or more diplomas granted by >>>>> one or more universities. The bank cannot be >>>>> the "primary issuer" of a university diploma. It >>>>> should not be either a "secondary issuer", because >>>>> the bank does not "/need to know"/what are the >>>>> diplomas of the user. >>>>> >>>>>> but the AS needs to decide at runtime which specific >>>>>> instance of the API to direct the client to. Since >>>>>> things are closely tied together, the client just >>>>>> needs to effectively known an identifier for the RS, >>>>>> and this is currently implemented as a URI. Once the >>>>>> client has that identifier, it knows how to dispatch >>>>>> that token to that instance of the RS. >>>>> >>>>> There is no good reason why the AS should be involved >>>>> in that step. >>>>> OAuth 2.0 is/was implicitly mandating a strong >>>>> relationship between ASs and RSs which makes it non >>>>> scalable. >>>>> GNAP should be based on a simple trust relationship : >>>>> a given RS trusts some ASs for access tokens that >>>>> contains some types of attributes. >>>>> An AS should not need to know in advance (or even at >>>>> the time of an access token request) the RSs that are >>>>> trusting it. >>>>> >>>>> A client could first talk to a "global service >>>>> provider" which has the knowledge of the different RSs >>>>> affiliated to it. >>>>> >>>>>> (2) The client knows what kind of thing it’s looking >>>>>> for, but doesn’t know who to ask it from. >>>>> >>>>> Once again, the client could first talk to a "global >>>>> service provider" which has the knowledge of the >>>>> different RSs affiliated to it. >>>>> >>>>>> There’s a cross-domain trust that’s bridged by the >>>>>> AS, and the AS needs to dispatch to different >>>>>> resources depending on which user logged in (and >>>>>> possibly what the user consented to). To make things >>>>>> more concrete, the client needs to get driver’s >>>>>> license information, but doesn’t know ahead of time >>>>>> which of the many state/provincial bureaus to call to >>>>>> get that information because it doesn’t know yet who >>>>>> the user is. >>>>> >>>>> When a user has a driving license, he knows its >>>>> issuer. The user can then provide some hint to the client. >>>>> >>>>>> The AS will know who the user is once they log in and >>>>>> approve things, and so it can direct the client to >>>>>> call the correct RS. Since this is a relatively >>>>>> simple API with a pre-negotiated cross-domain trust, >>>>>> the AS returns a URL that the client presents the >>>>>> token at. >>>>> >>>>>  A single AS should not be aware of all the attributes >>>>> a user has. >>>>> >>>>>> >>>>>> As far as I know, in both of these cases, the token >>>>>> is only good for that API and not others — but more >>>>>> on that later. >>>>>> >>>>>> A simple thing to do is just give back a URL with the >>>>>> access token, which tells the client where to go. >>>>>> >>>>>> { >>>>>> “access_token”: { >>>>>> “value”: “87yui843yfer”, >>>>>> “resource_uri”: “https://example/foo" >>>>>> } >>>>>> } >>>>>> >>>>>> This is good for some kinds of APIs, but it’s >>>>>> limiting because not all APIs dispatch based on the >>>>>> URL. An AS might want to divvy up access tokens to an >>>>>> API that’s keyed on headers, or verbs, or any number >>>>>> of things. And it doesn’t tell us immediately what to >>>>>> do about non-exact URL matches. Can the client add >>>>>> query parameters and still use the token? What about >>>>>> path segments? I like that this simple approach >>>>>> addresses some common deployments that we already see >>>>>> today (see above), it’s not universal. Do we want or >>>>>> need a universal description language for directing >>>>>> where tokens go? >>>>>> >>>>>> This also opens up a whole new set of security >>>>>> questions. If the AS can now direct the client where >>>>>> to use the token, could a rogue AS convince a legit >>>>>> client to use a stolen token at the wrong RS? And >>>>>> what if the client ignores the directions from the AS >>>>>> entirely? Could this open up new avenues of attack? >>>>>> >>>>>> This is just the start, too. Things get even more >>>>>> complex if the client can ask for multiple different >>>>>> kinds of resources at once. What if the AS decides >>>>>> that the client needs a hyper-focused directed token >>>>>> for one part of the API, but can use a general token >>>>>> for other stuff? Can it signal that to the client? >>>>>> And if it can, does that mean that all clients need >>>>>> to be prepared for that kind of thing? >>>>>> >>>>>> I firmly believe that whatever we build in GNAP, we >>>>>> need to optimize for the overwhelmingly common use >>>>>> case of a client getting a single access token to >>>>>> call APIs that it already knows about. Anything we >>>>>> add on top of that really can’t get in the way of >>>>>> this, because if it does, there’s very small chance >>>>>> that people will try to use this for everyday things. >>>>>> Keep the simple things simple, and the complex things >>>>>> possible, after all. >>>>>> >>>>>> I’m really looking forward to hearing what the >>>>>> community thinks about these use cases, and hopefully >>>>>> the people I’ve chatted with offline about this can >>>>>> join the conversation and provide more light than I >>>>>> was able to. >>>>> >>>>> The two use cases which are considered above are: >>>>> >>>>> (1) The client knows what resource it’s calling, >>>>> but it doesn’t know where it’s hosted. >>>>> (2) The client knows what kind of thing it’s >>>>> looking for, but doesn’t know who to ask it from. >>>>> >>>>> That does not mean in any way that these two use cases >>>>> should be solved by placing the AS at the centre of >>>>> the solution. >>>>> >>>>> Denis >>>>> >>>>>> >>>>>>  — 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 >>> >>> >>> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. >> >> -- >> 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 > --------------79C241DC4558E8DD4403618D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Tom,

Should I understand that you are willing to rubber-stamp an existing implementation ?

Since we are not yet a WG, it is not my understanding that it is what a WG should attempt to do.

Denis

You cannot assume that the rs is in communication with the user/resource owner during the other interchanges. That would not be the case in my implementation.

thx ..Tom (mobile)

On Fri, Jun 26, 2020, 9:04 AM Denis <denis.ietf@free.fr> wrote:
Tom and Justin,

Why do want to make things complicated when they are quite simple ?

The statement saying "the as and rs most likely have an ongoing security context on which to build subsequent interchanges"
would have severe limitations in terms of scalability and privacy.

The principle where a RS would only have relationships with one AS would make the model non scalable.
It would prevent to get attributes from two different ASs,  for example: 
identity attributes from a bank and a master degree diploma from a university.

For privacy reasons, every AS should know as little as possible about the interactions between a client and multiple RSs.
It is even possible that this goes as little as knowing nothing at all.

The OAuth 2.0 assumption where the AS is in a position to know all the interactions of a given user has with all the RSs
that an AS server has a relationship with should not be re-iterated.

The relationships between RSs may change at any time and it woauld not be reasonable to inform the ASs in real time
about these interactions.

As already stated in an earlier email:
No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. (...)

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).
A RS whether the first one of a RS chain and a subsequent one, taking into consideration the kind of operation that will be requested by the client,
should be is able to inform the user about which kind of attributes are needed and from which AS(s) [note the plural], they may be obtained.

Denis


While there are multiple reasons for bound tokens, each with their own needs, I strongly encourage an effort to create a single broad spec that could address the common security issues. Tobias, this is the general idea you were pushing on application level networking. As a general rule, I believe that the current effort to base security on channel binding has already been extended beyond its capabilities. (That is the concept that the HTTPS key is used as the security for the messages.) So, can't we focus on the problem of identifying the participants to an extended set of interchanges. This would formalize the earlier statements that the as and rs most likely have an ongoing security context on which to build subsequent interchanges.
Peace ..tom


On Fri, Jun 26, 2020 at 6:23 AM Justin Richer <jricher@mit.edu> wrote:
On Jun 25, 2020, at 9:07 PM, Tobias Looker <tobias.looker@mattr.global> wrote:

I find this feature interesting and think it could be an important pattern going forward to enable an AS to be able to describe the utility of a token to the client, however as already pointed out in the thread I think there is some potential hidden complexity that would need to be ironed out such that it does not make the simple things complicated.

Justin, do you see this feature as something the client has to explicitly request, i.e "please give me access and instructions on how to use my access" or rather that the AS would just return this information in conjunction with the access token if it had it available?


This is something that I’d brought up as a possibility on the previous thread — something like a flag the client would set. This would be especially important if the AS wants to return multiple access tokens but the client requested 1, or the client requested N and the AS wants to return M in response. Basically any time there’s a mismatch, that’s extra complexity on the client that I really don’t think we want to be universal. A flag to turn that kind of direction and splitting on would be a potential start. But there are potential snags here too, and it comes down to how you manage the defaults...

> This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

Would a potential default be that if a client did for any reason not support processing the additional information returned with the access_token, just to ignore it? I think in the spirit of keeping the simple things simple, this potentially makes sense?

That’s the real trick, if you ask me. It has to be :safe: for a client to ignore this information. Which means the AS can’t rely on the client “doing the right thing” with the information in the “token directions” portion of the response. Even setting aside the advanced and related “split tokens” idea above, we need to make sure that an AS/RS setup is built such that if the AS tells a client “only do X with your token” and the client does “Y”, then there are other protections and practices in place to prevent things from going haywire if the client does “Y” either by accident or through ignorance. 

If OAuth 2 has taught us anything, it’s that client applications are going to be the laziest participants in the security model. And that makes sense, really — security isn’t what the client apps are trying to do, they’re trying to use the RS to do something. So we need to make sure that whatever system we design will fail on the safe side as much as possible, and keep things simple for the client.


> here are some worked out samples of this:
Peace ..tom

As one of the authors of those mentioned drafts, I am interested in discussing that, but perhaps on a seperate thread? As at least the bound assertion spec is primarily concerned with binding mechanisms for the artifacts produced from an authorization flow (specifically identity claims), whereas I think directed access tokens is just more generally talking about whether GNAP should support an AS conveying how to use an access_token it produces during a flow with a client.


I think that these are separate issues as well.

 — Justin

Thanks,
Mattr website  
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
Mattr website Mattr on LinkedIn Mattr on Twitter Mattr on Github

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Wed, Jun 24, 2020 at 10:14 PM Denis <denis.ietf@free.fr> wrote:
Justin, I fear we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I am getting tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it’s going to be overwhelmingly common that a given RS is going to trust exactly one AS
that it knows about ahead of time". Such an architecture would have exactly the same limitations as OAuth 2.0. and would not be scalable.

Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions.
For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believe that we have an agreement at this time on what
these trust relationships are.

You are also using the following wording: "methods for the AS and RS to communicate what the token’s good for".
With such a paradigm, it would be impossible to protect the user's privacy.

A key question is : Will GNAP take care of the user's privacy or will GNAP prevent to take care of the user's privacy ?

About "the ability for the client to get several access tokens to get different resources from one request" is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform
on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).

First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases.

When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS.
His "consent and choice" should then be obtained by the first RS and, when the user agrees, the client should then ask an access token
to one of the ASs trusted by the second RS in order to perform the subsequent operation. 

Denis

PS.  In an email sent on June 23 you wrote: " I think an on-device AS is an important use case".  I am sorry, but I don't understand.
       However, I do understand what "a server-based AS" is.


Denis, thanks for the great comments. I think that your trust model is pretty different from what I’d laid out initially, and while it’s an interesting and important one, it is not what I meant by “multiple access tokens” in my discussion below. I think that might be the cause of some disconnect here, but that doesn’t mean it’s out of reach for what the WG is after.

When I refer to multiple access tokens, and what the charter calls out as multiple access tokens, is the ability for the client to get several access tokens to get different resources from one request. I personally see this as an optimization of a specific set of use cases, some of which I discussed in my original email. There are others, I’m sure, but all the ones I’ve seen are around the client needing to get several different kinds of access through an AS. 

I think it’s going to be overwhelmingly common that a given RS is going to trust exactly one AS that it knows about ahead of time. But for RS’s that can trust multiple AS’s, then we should have a model that can accommodate that as well. That’s why the charter calls out methods for the AS and RS to communicate what the token’s good for. I think the basis of those methods is going to start with a common token model, and likely incorporate into things like token formats and introspection-style token APIs. 

 — Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the lines.

One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can’t, or at least can’t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don’t know if this concept has a regular term, so I’m going to call it “directed access tokens” until we come up with something better — assuming we decide this is worthwhile. 

I don't understand what may mean "directed access tokens” but I understand what means "multiple access tokens". 
When speaking of "multiple access tokens", these access tokens may come from one or more ASs.

In OAuth, the client’s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we’re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to. 

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of directions about what that specific token is good for. This needs to be information outside the token itself, since I believe we want to keep OAuth 2’s feature of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn’t enough to tell the client what to do with the token if it doesn’t know already. 

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I’ll try to summarize here, but I know the folks I’ve been talking to about this are also on the list so hopefully they can chime in with more detail or any corrections for something I’ve missed. 

(1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted. Everything is in a single security domain controlled by the AS, 

Speaking of "multiple access tokens" is in contradiction with single security domain "controlled" by an AS. 
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also 
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be 
the "primary issuer" of a university diploma. It should not be either a "secondary issuer", because 
the bank does not "need to know" what are the diplomas of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved in that step. 
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it. 

(2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from. 

Once again, the client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it. 

There’s a cross-domain trust that’s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver’s license information, but doesn’t know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn’t know yet who the user is. 

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at. 

 A single AS should not be aware of all the attributes a user has. 


As far as I know, in both of these cases, the token is only good for that API and not others — but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go. 

{
“access_token”: {
“value”: “87yui843yfer”,
“resource_uri”: “https://example/foo"
}
}

This is good for some kinds of APIs, but it’s limiting because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that’s keyed on headers, or verbs, or any number of things. And it doesn’t tell us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it’s not universal. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can’t get in the way of this, because if it does, there’s very small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I’m really looking forward to hearing what the community thinks about these use cases, and hopefully the people I’ve chatted with offline about this can join the conversation and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted.
(2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from. 

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Denis


 — 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

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

--
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


--------------79C241DC4558E8DD4403618D-- From nobody Fri Jun 26 09:54:48 2020 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 48B113A0964 for ; Fri, 26 Jun 2020 09:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 ywuN-ZYiyRBI for ; Fri, 26 Jun 2020 09:54:42 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 E564C3A0941 for ; Fri, 26 Jun 2020 09:54:41 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id 5so7225441oty.11 for ; Fri, 26 Jun 2020 09:54:41 -0700 (PDT) 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=B2lNJvyQV3NgdJ+n+2USRiyYz8LGESRkVFmmwvrSbcI=; b=Wu4vksFvu/UVmArOYY6pAM7pDcRW12lf8XlLS/J3RIrQTOAYMcD+LJMTNnSHP1sjTb IT9CPo10741cIGvsM1gAB4ZhTpaBsP5WN5P8hBW2eooy1MX99qMiRLmsKZuM2AlLDuR6 Zp4ZK5JVNIdJnIKwG+lFxAzdXwxhubgpCpxVHKLuOpzedw86cvpwJCZoE3oaqksGbb1p jxbayXnSbBk4nGGzTa6CKkovFC6xIwU83xcsY6R16+8zWFQRiZmfZ0yiwRmlhFQJFc2R GbuRztnHgXRCagvxtitWrIJgdPnB4svqsILUHcGu6Vw0UuHjYHRW5dQ3LGaEhXMy8NSR g+Iw== 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=B2lNJvyQV3NgdJ+n+2USRiyYz8LGESRkVFmmwvrSbcI=; b=Q76x+emhUb3my9WDF3AqE5PBDgvfh/+j8dW3UPge1jWb1EdwN/aOit7I42DCtcMlwn Gyhay9wvu/sGYpbdavjDF09ugLQbmPMQ5aFAidMepg1sLYSRMDCHiUTg05XeYFZ9C/ts 6fUzF/foOIcdh36Qx07+iZrWNestek887V4OIFNc9Sdt6TTi8RQlAwfH9/3iBSR/QUho M+zQ415bMcUqJnyDZGxPCZdhHCIS5XG6hGXKmgy7Esx3fwXC3zdm2heLFaRXiqdBfjpu o0gL622UAMxiA3JFuDwQrpPE+koHQ2o2qWRVd1P0dM+2VqpE28YUh9TcJvhJ/wMAiFVe LP0w== X-Gm-Message-State: AOAM530jWcgVailHq54uPa+ffquk3nG2idJTfudWA3h8icEU98788pl6 mHX1PbFEm9LYebJcMe9Oi122H7Ktk8wppE7DiC0= X-Google-Smtp-Source: ABdhPJzVnA91CComT9BXCAyD9ymf9dL9MvHznE1LbvtjPHHI4nnDrUHJiPuGbf4bEEq6LvnoyYKtOpCgqVDkzWfzaUo= X-Received: by 2002:a4a:bd10:: with SMTP id n16mr3216781oop.27.1593190480943; Fri, 26 Jun 2020 09:54:40 -0700 (PDT) MIME-Version: 1.0 References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr> <4fab6b2b-c860-350e-476b-60372dd946c3@free.fr> In-Reply-To: <4fab6b2b-c860-350e-476b-60372dd946c3@free.fr> From: Tom Jones Date: Fri, 26 Jun 2020 09:54:28 -0700 Message-ID: To: Denis Cc: Justin Richer , txauth@ietf.org, Tobias Looker Content-Type: multipart/alternative; boundary="000000000000ad1e6705a8ff9062" Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 26 Jun 2020 16:54:47 -0000 --000000000000ad1e6705a8ff9062 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable no you should not assume that. But if your standard demands communications between the ro & rs for every release of data, then i could not use the standard. Peace ..tom On Fri, Jun 26, 2020 at 9:51 AM Denis wrote: > Tom, > > Should I understand that you are willing to rubber-stamp an existing > implementation ? > > Since we are not yet a WG, it is not my understanding that it is what a W= G > should attempt to do. > > Denis > > You cannot assume that the rs is in communication with the user/resource > owner during the other interchanges. That would not be the case in my > implementation. > > thx ..Tom (mobile) > > On Fri, Jun 26, 2020, 9:04 AM Denis wrote: > >> Tom and Justin, >> >> Why do want to make things complicated when they are quite simple ? >> >> The statement saying "the as and rs most likely have an ongoing security >> context on which to build subsequent interchanges" >> would have severe limitations in terms of scalability and privacy. >> >> The principle where a RS would only have relationships with one AS would >> make the model non scalable. >> It would prevent to get attributes from two different ASs, for example: >> identity attributes from a bank and a master degree diploma from a >> university. >> >> For privacy reasons, every AS should know as little as possible about th= e >> interactions between a client and multiple RSs. >> It is even possible that this goes as little as knowing *nothing at all*= . >> >> The OAuth 2.0 assumption where the AS is in a position to know all the >> interactions of a given user has with all the RSs >> that an AS server has a relationship with should not be re-iterated. >> >> The relationships between RSs may change at any time and it woauld not b= e >> reasonable to inform the ASs in real time >> about these interactions. >> >> As already stated in an earlier email: >> >> No one (including ASs) is able to predict in advance which access tokens >> will be needed, since they depend upon the kind of operation(s) >> the client will be willing to perform. (...) >> >> To handle the complex case you envision, the full workflow of operations >> needs to be considered with a detailed focus on the time >> at which the user's *consent and choice* happens (*consent and choice* >> is the first privacy principle from ISO 29100). >> >> A RS whether the first one of a RS chain and a subsequent one, taking >> into consideration the kind of operation that will be requested by the >> client, >> should be is able to inform the user about which kind of attributes are >> needed and from which AS(s) [note the plural], they may be obtained. >> >> Denis >> >> >> While there are multiple reasons for bound tokens, each with their own >> needs, I strongly encourage an effort to create a single broad spec that >> could address the common security issues. Tobias, this is the general id= ea >> you were pushing on application level networking. As a general rule, I >> believe that the current effort to base security on channel binding has >> already been extended beyond its capabilities. (That is the concept that >> the HTTPS key is used as the security for the messages.) So, can't we fo= cus >> on the problem of identifying the participants to an extended set of >> interchanges. This would formalize the earlier statements that the as an= d >> rs most likely have an ongoing security context on which to build >> subsequent interchanges. >> Peace ..tom >> >> >> On Fri, Jun 26, 2020 at 6:23 AM Justin Richer wrote: >> >>> On Jun 25, 2020, at 9:07 PM, Tobias Looker >>> wrote: >>> >>> >>> I find this feature interesting and think it could be an >>> important pattern going forward to enable an AS to be able to describe = the >>> utility of a token to the client, however as already pointed out in the >>> thread I think there is some potential hidden complexity that would nee= d to >>> be ironed out such that it does not make the simple things complicated. >>> >>> Justin, do you see this feature as something the client has to >>> explicitly request, i.e "please give me access and instructions on how = to >>> use my access" or rather that the AS would just return this information= in >>> conjunction with the access token if it had it available? >>> >>> >>> This is something that I=E2=80=99d brought up as a possibility on the p= revious >>> thread =E2=80=94 something like a flag the client would set. This would= be >>> especially important if the AS wants to return multiple access tokens b= ut >>> the client requested 1, or the client requested N and the AS wants to >>> return M in response. Basically any time there=E2=80=99s a mismatch, th= at=E2=80=99s extra >>> complexity on the client that I really don=E2=80=99t think we want to b= e universal. >>> A flag to turn that kind of direction and splitting on would be a poten= tial >>> start. But there are potential snags here too, and it comes down to how= you >>> manage the defaults... >>> >>> > This is just the start, too. Things get even more complex if the >>> client can ask for multiple different kinds of resources at once. What = if >>> the AS decides that the client needs a hyper-focused directed token for= one >>> part of the API, but can use a general token for other stuff? Can it si= gnal >>> that to the client? And if it can, does that mean that all clients need= to >>> be prepared for that kind of thing? >>> >>> Would a potential default be that if a client did for any reason not >>> support processing the additional information returned with the >>> access_token, just to ignore it? I think in the spirit of keeping the >>> simple things simple, this potentially makes sense? >>> >>> >>> That=E2=80=99s the real trick, if you ask me. It has to be :safe: for a= client >>> to ignore this information. Which means the AS can=E2=80=99t rely on th= e client >>> =E2=80=9Cdoing the right thing=E2=80=9D with the information in the =E2= =80=9Ctoken directions=E2=80=9D >>> portion of the response. Even setting aside the advanced and related = =E2=80=9Csplit >>> tokens=E2=80=9D idea above, we need to make sure that an AS/RS setup is= built such >>> that if the AS tells a client =E2=80=9Conly do X with your token=E2=80= =9D and the client >>> does =E2=80=9CY=E2=80=9D, then there are other protections and practice= s in place to >>> prevent things from going haywire if the client does =E2=80=9CY=E2=80= =9D either by accident >>> or through ignorance. >>> >>> If OAuth 2 has taught us anything, it=E2=80=99s that client application= s are >>> going to be the laziest participants in the security model. And that ma= kes >>> sense, really =E2=80=94 security isn=E2=80=99t what the client apps are= trying to do, >>> they=E2=80=99re trying to use the RS to do something. So we need to mak= e sure that >>> whatever system we design will fail on the safe side as much as possibl= e, >>> and keep things simple for the client. >>> >>> >>> > here are some worked out samples of this: >>> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token >>> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ >>> Peace ..tom >>> >>> As one of the authors of those mentioned drafts, I am interested in >>> discussing that, but perhaps on a seperate thread? As at least the boun= d >>> assertion spec is primarily concerned with binding mechanisms for the >>> artifacts produced from an authorization flow (specifically identity >>> claims), whereas I think directed access tokens is just more generally >>> talking about whether GNAP should support an AS conveying how to use an >>> access_token it produces during a flow with a client. >>> >>> >>> I think that these are separate issues as well. >>> >>> =E2=80=94 Justin >>> >>> Thanks, >>> [image: Mattr website] >>> *Tobias Looker* >>> Mattr >>> +64 (0) 27 378 0461 >>> tobias.looker@mattr.global >>> [image: Mattr website] [image: Mattr on >>> LinkedIn] [image: Mattr >>> on Twitter] [image: Mattr on Github] >>> >>> This communication, including any attachments, is confidential. If you >>> are not the intended recipient, you should not read it - please contact= me >>> immediately, destroy it, and do not copy or use any part of this >>> communication or disclose anything about it. Thank you. Please note tha= t >>> this communication does not designate an information system for the >>> purposes of the Electronic Transactions Act 2002. >>> >>> >>> On Wed, Jun 24, 2020 at 10:14 PM Denis wrote: >>> >>>> Justin, I fear we are still far away from an agreement about what this >>>> BoF should do. >>>> >>>> Tom Jones is saying " I am getting tired of the whack-a-mole approach >>>> ..." >>>> >>>> I don't agree with you when you write: "I think it=E2=80=99s going to = be >>>> overwhelmingly common that a given RS is going to trust exactly one AS >>>> that it knows about ahead of time". Such an architecture would have >>>> exactly the same limitations as OAuth 2.0. and would not be scalable. >>>> >>>> Before we start, we should have a clear view of the whole picture >>>> rather than starting from one scenario and expanding it in many differ= ent >>>> directions. >>>> For building an architecture, a pre-requirement is to define ALL the >>>> trust relationships. I don't believe that we have an agreement at this= time >>>> on what >>>> these trust relationships are. >>>> >>>> You are also using the following wording: "methods for the AS and RS t= o >>>> communicate what the token=E2=80=99s good for". >>>> With such a paradigm, it would be impossible to protect the user's >>>> privacy. >>>> >>>> A key question is : Will GNAP take care of the user's privacy or will >>>> GNAP *prevent *to take care of the user's privacy ? >>>> >>>> About "the ability for the client to get several access tokens to get >>>> different resources from one request" is indeed a complex case. >>>> >>>> No one (including ASs) is able to predict in advance which access >>>> tokens will be needed, since they depend upon the kind of operation(s) >>>> the client will be willing to perform. For privacy reasons, ASs should >>>> be kept ignorant of all the operations that a client is going to perfo= rm >>>> on one or more resource servers. I believe that every effort should be >>>> made to avoid the AS to be in a position to be able to trace the opera= tions >>>> performed by its clients on various RSs. >>>> >>>> To handle the complex case you envision, the full workflow of >>>> operations needs to be considered with a detailed focus on the time >>>> at which the user's *consent and choice* happens (*consent and choice* >>>> is the first privacy principle from ISO 29100). >>>> >>>> First of all, an access token could be targeted to a service rather >>>> than to a server. This would already solve many cases. >>>> >>>> When a RS needs to call another RS (which does not support the same >>>> service) then the client should be informed by the first RS. >>>> His "consent and choice" should then be obtained by the first RS and, >>>> when the user agrees, the client should then ask an access token >>>> to one of the ASs trusted by the second RS in order to perform the >>>> subsequent operation. >>>> >>>> Denis >>>> >>>> PS. In an email sent on June 23 you wrote: " I think an on-device AS >>>> is an important use case". I am sorry, but I don't understand. >>>> However, I do understand what "a server-based AS" is. >>>> >>>> >>>> Denis, thanks for the great comments. I think that your trust model is >>>> pretty different from what I=E2=80=99d laid out initially, and while i= t=E2=80=99s an >>>> interesting and important one, it is not what I meant by =E2=80=9Cmult= iple access >>>> tokens=E2=80=9D in my discussion below. I think that might be the caus= e of some >>>> disconnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of rea= ch for what the WG is >>>> after. >>>> >>>> When I refer to multiple access tokens, and what the charter calls out >>>> as multiple access tokens, is the ability for the client to get severa= l >>>> access tokens to get different resources from one request. I personall= y see >>>> this as an optimization of a specific set of use cases, some of which = I >>>> discussed in my original email. There are others, I=E2=80=99m sure, bu= t all the >>>> ones I=E2=80=99ve seen are around the client needing to get several di= fferent kinds >>>> of access through an AS. >>>> >>>> I think it=E2=80=99s going to be overwhelmingly common that a given RS= is going >>>> to trust exactly one AS that it knows about ahead of time. But for RS= =E2=80=99s >>>> that can trust multiple AS=E2=80=99s, then we should have a model that= can >>>> accommodate that as well. That=E2=80=99s why the charter calls out met= hods for the >>>> AS and RS to communicate what the token=E2=80=99s good for. I think th= e basis of >>>> those methods is going to start with a common token model, and likely >>>> incorporate into things like token formats and introspection-style tok= en >>>> APIs. >>>> >>>> =E2=80=94 Justin >>>> >>>> On Jun 22, 2020, at 3:55 AM, Denis wrote: >>>> >>>> Hello Justin, >>>> >>>> A few comments between the lines. >>>> >>>> One of the most important aspects to GNAP is going to be an ability to >>>> address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t d= o without significant >>>> gymnastics. So with that, I wanted to bring back a use case discussion= that >>>> originally came up while we were talking about the possibility of mult= iple >>>> access tokens, a few months back. I don=E2=80=99t know if this concept= has a >>>> regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected access= tokens=E2=80=9D until we >>>> come up with something better =E2=80=94 assuming we decide this is wor= thwhile. >>>> >>>> I don't understand what may mean "directed access tokens=E2=80=9D but = I >>>> understand what means "multiple access tokens". >>>> When speaking of "multiple access tokens", these access tokens may com= e >>>> from one or more ASs. >>>> >>>> In OAuth, the client=E2=80=99s supposed to always know where to send i= ts access >>>> token, and that knowledge is completely outside the protocol. This mak= es a >>>> lot of sense for many (if not most) deployments, as OAuth is really th= ere >>>> to enable the API access that the client already knows about. >>>> >>>> But we=E2=80=99re now in a world where a client could be talking to a = generic >>>> API that could be deployed at a number of different places, or a cloud >>>> deployment that the AS wants to be able to dispatch the client to. >>>> >>>> As soon the AS is placed (again) at the centre of the model, the AS >>>> will have the ability to act as "Big Brother". >>>> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP >>>> should take care of them. >>>> >>>> In order to do this, the AS needs to be able to communicate to the >>>> client not only the token information (and any related key and present= ation >>>> information), but also a set of *directions* about what that specific >>>> token is good for. This needs to be information outside the token itse= lf, >>>> since I believe we want to keep OAuth 2=E2=80=99s feature of having th= e token be >>>> opaque to the client. Note: while we could map all of these to differe= nt >>>> resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parla= nce) >>>> on the request side, this isn=E2=80=99t enough to tell the client what= to do with >>>> the token *if it doesn=E2=80=99t know already*. >>>> >>>> I know of two use cases already in the wild, where people are >>>> addressing things using a mix of existing standards and some proprieta= ry >>>> extensions to address things within their silos. I=E2=80=99ll try to s= ummarize >>>> here, but I know the folks I=E2=80=99ve been talking to about this are= also on the >>>> list so hopefully they can chime in with more detail or any correction= s for >>>> something I=E2=80=99ve missed. >>>> >>>> (1) The client knows what resource it=E2=80=99s calling, but it doesn= =E2=80=99t know >>>> where it=E2=80=99s hosted. Everything is in a single security domain c= ontrolled by >>>> the AS, >>>> >>>> Speaking of "multiple access tokens" is in contradiction with single >>>> security domain "controlled" by an AS. >>>> A user may need to demonstrate some of his identity attributes granted >>>> e.g. by his bank but may also >>>> need to demonstrate one or more diplomas granted by one or more >>>> universities. The bank cannot be >>>> the "primary issuer" of a university diploma. It should not be either = a >>>> "secondary issuer", because >>>> the bank does not "*need to know"* what are the diplomas of the user. >>>> >>>> but the AS needs to decide at runtime which specific instance of the >>>> API to direct the client to. Since things are closely tied together, t= he >>>> client just needs to effectively known an identifier for the RS, and t= his >>>> is currently implemented as a URI. Once the client has that identifier= , it >>>> knows how to dispatch that token to that instance of the RS. >>>> >>>> There is no good reason why the AS should be involved in that step. >>>> OAuth 2.0 is/was implicitly mandating a strong relationship between AS= s >>>> and RSs which makes it non scalable. >>>> GNAP should be based on a simple trust relationship : a given RS trust= s >>>> some ASs for access tokens that contains some types of attributes. >>>> An AS should not need to know in advance (or even at the time of an >>>> access token request) the RSs that are trusting it. >>>> >>>> A client could first talk to a "global service provider" which has the >>>> knowledge of the different RSs affiliated to it. >>>> >>>> (2) The client knows what kind of thing it=E2=80=99s looking for, but = doesn=E2=80=99t >>>> know who to ask it from. >>>> >>>> Once again, the client could first talk to a "global service provider" >>>> which has the knowledge of the different RSs affiliated to it. >>>> >>>> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS,= and the AS needs >>>> to dispatch to different resources depending on which user logged in (= and >>>> possibly what the user consented to). To make things more concrete, th= e >>>> client needs to get driver=E2=80=99s license information, but doesn=E2= =80=99t know ahead of >>>> time which of the many state/provincial bureaus to call to get that >>>> information because it doesn=E2=80=99t know yet who the user is. >>>> >>>> When a user has a driving license, he knows its issuer. The user can >>>> then provide some hint to the client. >>>> >>>> The AS will know who the user is once they log in and approve things, >>>> and so it can direct the client to call the correct RS. Since this is = a >>>> relatively simple API with a pre-negotiated cross-domain trust, the AS >>>> returns a URL that the client presents the token at. >>>> >>>> A single AS should not be aware of all the attributes a user has. >>>> >>>> >>>> As far as I know, in both of these cases, the token is only good for >>>> that API and not others =E2=80=94 but more on that later. >>>> >>>> A simple thing to do is just give back a URL with the access token, >>>> which tells the client where to go. >>>> >>>> { >>>> =E2=80=9Caccess_token=E2=80=9D: { >>>> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D, >>>> =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo" >>>> } >>>> } >>>> >>>> This is good for some kinds of APIs, but it=E2=80=99s limiting because= not all >>>> APIs dispatch based on the URL. An AS might want to divvy up access to= kens >>>> to an API that=E2=80=99s keyed on headers, or verbs, or any number of = things. And >>>> it doesn=E2=80=99t tell us immediately what to do about non-exact URL = matches. Can >>>> the client add query parameters and still use the token? What about pa= th >>>> segments? I like that this simple approach addresses some common >>>> deployments that we already see today (see above), it=E2=80=99s not un= iversal. Do >>>> we want or need a universal description language for directing where t= okens >>>> go? >>>> >>>> This also opens up a whole new set of security questions. If the AS ca= n >>>> now direct the client where to use the token, could a rogue AS convinc= e a >>>> legit client to use a stolen token at the wrong RS? And what if the cl= ient >>>> ignores the directions from the AS entirely? Could this open up new av= enues >>>> of attack? >>>> >>>> This is just the start, too. Things get even more complex if the clien= t >>>> can ask for multiple different kinds of resources at once. What if the= AS >>>> decides that the client needs a hyper-focused directed token for one p= art >>>> of the API, but can use a general token for other stuff? Can it signal= that >>>> to the client? And if it can, does that mean that all clients need to = be >>>> prepared for that kind of thing? >>>> >>>> I firmly believe that whatever we build in GNAP, we need to optimize >>>> for the overwhelmingly common use case of a client getting a single ac= cess >>>> token to call APIs that it already knows about. Anything we add on top= of >>>> that really can=E2=80=99t get in the way of this, because if it does, = there=E2=80=99s very >>>> small chance that people will try to use this for everyday things. Kee= p the >>>> simple things simple, and the complex things possible, after all. >>>> >>>> I=E2=80=99m really looking forward to hearing what the community think= s about >>>> these use cases, and hopefully the people I=E2=80=99ve chatted with of= fline about >>>> this can join the conversation and provide more light than I was able = to. >>>> >>>> The two use cases which are considered above are: >>>> >>>> (1) The client knows what resource it=E2=80=99s calling, but it doesn= =E2=80=99t know >>>> where it=E2=80=99s hosted. >>>> (2) The client knows what kind of thing it=E2=80=99s looking for, but = doesn=E2=80=99t >>>> know who to ask it from. >>>> >>>> That does not mean in any way that these two use cases should be solve= d >>>> by placing the AS at the centre of the solution. >>>> >>>> Denis >>>> >>>> >>>> =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 >>>> >>> >>> This communication, including any attachments, is confidential. If you = are not the intended recipient, you should not read it - please contact me = immediately, destroy it, and do not copy or use any part of this communicat= ion or disclose anything about it. Thank you. Please note that this communi= cation does not designate an information system for the purposes of the Ele= ctronic Transactions Act 2002. >>> >>> >>> -- >>> 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 >> > > --000000000000ad1e6705a8ff9062 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
no you should not assume that. But if your standard demand= s communications between the ro & rs for every release of data, then i = could not use the standard.
= Peace ..tom


On Fri, Jun 26, 2020 at 9:51 AM Deni= s <denis.ietf@free.fr> wrot= e:
=20 =20 =20
Tom,

Should I understand that you are willing to rubber-stamp an existing implementation ?

Since we are not yet a WG, it is not my understanding that it is what a WG should attempt to do.

Denis

=20
You cannot assume that the rs is in communication with the user/resource owner during the other interchanges. That would not be the case in my implementation.

thx ..Tom (mobile)

On Fri, Jun 26, 2020, 9:04 AM Denis <denis.ietf@free.fr> wrote:
Tom and Justin,

Why do want to make things complicated when they are quite simple ?

The statement saying "the as and rs most likely have = an ongoing=C2=A0security context on which to build subsequent interchanges"
would have severe limitations in terms of scalability and privacy.

The principle where a RS would only have relationships with one AS would make the model non scalable.
It would prevent to get attributes from two different ASs,=C2=A0 for example:=C2=A0
identity attributes from a bank and a master degree diploma from a university.

For privacy reasons, every AS should know as little as possible about the interactions between a client and multiple RSs.
It is even possible that this goes as little as knowing nothing at all.

The OAuth 2.0 assumption where the AS is in a position to know all the interactions of a given user has with all the RSs
that an AS server has a relationship with should not be re-iterated.

The relationships between RSs may change at any time and it woauld not be reasonable to inform the ASs in real time
about these interactions.

As already stated in an earlier email:
No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. (...)

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).
A RS whether the first one of a RS chain and a subsequent one, taking into consideration the kind of operation that will be requested by the client,
should be is able to inform the user about which kind of attributes are needed and from which AS(s) [note the plural], they may be obtained.

Denis


While there are multiple reasons for bound tokens, each with their own needs, I strongly encourage an effort to create a single broad spec that could address the common security issues. Tobias, this is the general idea you were pushing on application level networking. As a general rule, I believe=C2=A0that the current effort to base security on channel binding has already been extended beyond=C2=A0its capabilities. (That i= s the concept that the HTTPS key is used as the security for the messages.) So, can't we focus on the problem of identifying the participants to an extended set of interchanges. This would formalize the earlier statements that the as and rs most likely have an ongoing=C2=A0security context on which to build subsequent interchanges.
Peace ..tom


On Fri, Jun 26, 2020 at 6:23 AM Justin Richer <jricher@mit.edu> wrote:
On Jun 25, 2020, at 9:07 PM, Tobias Looker <tobias.looker@mattr.global> wrote:

I find this feature interesting and think it could be an important=C2=A0pattern going=C2=A0forward to enable an AS to be able t= o describe the utility of a token to the client, however as already pointed out in the thread I think there is some potential hidden complexity that would need to be ironed out such that it does not make the simple things complicated.

Justin, do you see this feature as something the client has to explicitly request, i.e "please give me access and instructions on how to use my access" or rather that the AS would just return this information in conjunction with the access token if it had it available?


This is something that I=E2=80=99d brought up as= a possibility on the previous thread =E2=80=94 someth= ing like a flag the client would set. This would be especially important if the AS wants to return multiple access tokens but the client requested 1, or the client requested N and the AS wants to return M in response. Basically any time there=E2= =80=99s a mismatch, that=E2=80=99s extra complexity on the client that I really don=E2=80=99t think we want to= be universal. A flag to turn that kind of direction and splitting on would be a potential start. But there are potential snags here too, and it comes down to how you manage the defaults...

> This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

Would a potential default be that if a client did for any reason not support processing the additional information returned with the access_token, just to ignore it? I think in the spirit of keeping the simple things simple, this potentially makes sense?

That=E2=80=99s the real trick, if you ask me. It= has to be :safe: for a client to ignore this information. Which means the AS can=E2=80=99t rely = on the client =E2=80=9Cdoing the right thing=E2=80=9D = with the information in the =E2=80=9Ctoken directions=E2=80= =9D portion of the response. Even setting aside the advanced and related =E2=80=9Csplit tokens=E2=80=9D idea abo= ve, we need to make sure that an AS/RS setup is built such that if the AS tells a client =E2=80=9Conly do X wi= th your token=E2=80=9D and the client does =E2=80=9CY= =E2=80=9D, then there are other protections and practices in place to prevent things from going haywire if the client does =E2=80=9CY=E2=80=9D either by accident or thro= ugh ignorance.=C2=A0

If OAuth 2 has taught us anything, it=E2=80=99s = that client applications are going to be the laziest participants in the security model. And that makes sense, really =E2=80=94 security isn=E2=80=99= t what the client apps are trying to do, they=E2=80=99re tryin= g to use the RS to do something. So we need to make sure that whatever system we design will fail on the safe side as much as possible, and keep things simple for the client.


> here are some worked out samples of this:
Peace ..tom

As one of the authors of those mentioned drafts, I am interested in discussing that, but perhaps on a seperate thread? As at least=C2=A0the bound assertion spec is=C2=A0primarily=C2=A0concerned with b= inding mechanisms for the artifacts produced from an authorization flow (specifically identity claims), whereas I think directed access tokens is just more generally talking about whether GNAP should support an AS conveying how to use an access_token it produces during a flow with a client.


I think that these are separate issues as well.

=C2=A0=E2=80=94 Justin

Thanks,
= 3D"Mattr =C2=A0
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
= 3D"Mattr = 3D"Mat= = 3D"Mattr = 3D"Mattr

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Wed, Jun 24, 2020 at 10:14 PM Denis <denis.ietf= @free.fr> wrote:
Justin, I fear we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I am gettin= g tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it=E2=80=99s going to be over= whelmingly common that a given RS is going to trust exactly one AS
that it knows about ahead of time"= ;. Such an architecture would have exactly the same limitations as OAuth 2.0. and would not be scalable.

Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions.
For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believ= e that we have an agreement at this time on what
these trust relationships are.

You are also using the following wording: "methods for the AS and RS = to communicate what the token=E2=80=99s good for".
With such a paradigm, it would be impossible to protect the user's privacy.

A key question is : Will GNAP take care of the user's privacy or will GNAP prevent to take care of the user's privacy ?

About "the ability for the client to get several access tokens to get different resources from one request"= ; is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform
on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).

First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases.

When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS.
His "consent and choice" sho= uld then be obtained by the first RS and, when the user agrees, the client should then ask an access token
to one of the ASs trusted by the second RS in order to perform the subsequent operation.=C2=A0

Denis

PS.=C2=A0 In an email sent on June 23 you wrote: " I think an on-device AS is an important use case".=C2=A0 I a= m sorry, but I don't understand.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Howe= ver, I do understand what "a server-based AS" is.


Denis, thanks for the great comments. I think that your trust model is pretty different from what I=E2=80=99d laid out initially,= and while it=E2=80=99s an interesting and important one, it is not what I meant by =E2=80=9Cmultiple access tokens=E2=80= =9D in my discussion below. I think that might be the cause of some disconnect here, but that doesn=E2=80=99t mean it=E2=80=99= s out of reach for what the WG is after.

When I refer to multiple access tokens, and what the charter calls out as multiple access tokens, is the ability for the client to get several access tokens to get different resources from one request. I personally see this as an optimization of a specific set of use cases, some of which I discussed in my original email. There are others, I=E2=80=99m sure, but all the o= nes I=E2=80=99ve seen are around the client needing to get several different kinds of access through an AS.=C2=A0

I think it=E2=80=99s going to be overwhelmingly common that a given RS is going to trust exactly one AS that it knows about ahead of time. But for RS=E2=80=99s that can t= rust multiple AS=E2=80=99s, then we should= have a model that can accommodate that as well. That=E2=80=99s why the chart= er calls out methods for the AS and RS to communicate what the token=E2= =80=99s good for. I think the basis of those methods is going to start with a common token model, and likely incorporate into things like token formats and introspection-style token APIs.=C2=A0=

=C2=A0=E2=80=94 Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.f= r> wrote:

Hello Justin,

A few comments between the lines.

One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can=E2=80=99t, or at least = can=E2=80=99t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don=E2=80=99t = know if this concept has a regular term, so I=E2=80=99m = going to call it =E2=80=9Cdirected access tokens=E2=80=9D until = we come up with something better =E2=80=94 assuming we decide this is worthwhile.=C2=A0

I don't understand what may mean "directed access tokens=E2=80=9D but I underst= and what means "multiple access tokens".=C2= =A0
When speaking of "multip= le access tokens", these access tokens may come from one or more ASs.

In OAuth, the client=E2=80=99s supposed t= o always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we=E2=80=99re now in= a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.=C2=A0

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of=C2=A0directions=C2=A0about what that specific token is good for. This needs to be information outside the token itself, since I=C2=A0believ= e we want to keep OAuth 2=E2=80=99s feature of havi= ng the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t en= ough to tell the client what to do with the token= =C2=A0if it doesn=E2=80=99t know already.=C2=A0

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I=E2=80=99ll t= ry to summarize here, but I know the folks I=E2=80=99ve= been talking to about this are also on the list so hopefully they can chime in with more detail or any corrections for something I=E2=80=99ve miss= ed.=C2=A0

(1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=80= =99t know where it=E2=80=99s hos= ted. Everything is in a single security domain controlled by the AS,= =C2=A0

Speaking of "multiple access tokens" is in contradiction with single security domain "controlled" by an = AS.=C2=A0
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also=C2=A0
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be=C2= =A0
the "primary issuer"= ; of a university diploma. It should not be either a "secondary issuer", because=C2=A0 the bank does not "ne= ed to know"=C2= =A0what are the diplomas of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved in that step.=C2=A0=
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it.= =C2=A0

(2) The client knows what kind of thing it=E2=80= =99s looking for, but doesn=E2= =80=99t know who to ask it from.=C2=A0

Once again, the client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it.=C2=A0

There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by t= he AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver=E2=80= =99s license information, but doesn=E2=80=99t know ahead = of time which of the many state/provincial bureaus to call to get that information because it doesn=E2=80=99t know yet wh= o the user is.=C2=A0=

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at.=C2=A0

=C2=A0A single AS should not be aware of all the attributes a user has.= =C2=A0


As far as I know, in both of these cases, the token is only good for that API and not others =E2=80=94 but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go.=C2=A0

{
=E2=80=9Caccess_token=E2=80=9D: {
=E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80= =9D,
=E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo&= quot;
}
}

This is good for some kinds of APIs, but it=E2=80= =99s limiting because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that=E2=80= =99s keyed on headers, or verbs, or any number of things. And it doesn=E2=80= =99t tell us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it=E2=80=99s n= ot universal. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can=E2=80=99= t get in the way of this, because if it does, there=E2=80=99s very small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I=E2=80=99m really looki= ng forward to hearing what the community thinks about these use cases, and hopefully the people I=E2=80=99ve chatted with offline about this can join the conversation and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what resource it=E2=80=99s calling, but it doesn=E2=80= =99t know where it=E2=80=99s hos= ted.
(2) The client knows what kind of thing it=E2=80= =99s looking for, but doesn=E2= =80=99t know who to ask it from.=C2=A0

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Denis


=C2=A0=E2=80=94 Justin


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


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

This commu=
nication, including any attachments, is confidential. If you are not the in=
tended recipient, you should not read it - please contact me immediately, d=
estroy it, and do not copy or use any part of this communication or disclos=
e anything about it. Thank you. Please note that this communication does no=
t designate an information system for the purposes of the Electronic Transa=
ctions Act 2002.

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


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


--000000000000ad1e6705a8ff9062-- From nobody Fri Jun 26 10:18:38 2020 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 611F53A0977 for ; Fri, 26 Jun 2020 10:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 FmmgMns8TN2L for ; Fri, 26 Jun 2020 10:18:31 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D35E3A0978 for ; Fri, 26 Jun 2020 10:18:30 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d18 with ME id vtJT220084FMSmm03tJTqa; Fri, 26 Jun 2020 19:18:28 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Fri, 26 Jun 2020 19:18:28 +0200 X-ME-IP: 86.238.65.197 To: Tom Jones Cc: Justin Richer , txauth@ietf.org, Tobias Looker References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr> <4fab6b2b-c860-350e-476b-60372dd946c3@free.fr> From: Denis Message-ID: <23c8d43b-9b79-f9b9-fdbf-aa2f096936a9@free.fr> Date: Fri, 26 Jun 2020 19:18:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------ACB074273DA7DD34ABC0AB7B" Content-Language: en-GB Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 26 Jun 2020 17:18:37 -0000 This is a multi-part message in MIME format. --------------ACB074273DA7DD34ABC0AB7B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Tom, In the model I have in mind, the ro may directly communicate with the rs (or open a session with the rs) to tell what the rules are, i.e. which attributes are needed for some kinds of operations and from which as(s) these attributes may be obtained. The ro is not involved in anyway at the time a client attempts to perform an operation. Denis > no you should not assume that. But if your standard demands > communications between the ro & rs for every release of data, then i > could not use the standard. > Peace ..tom > > > On Fri, Jun 26, 2020 at 9:51 AM Denis > wrote: > > Tom, > > Should I understand that you are willing to rubber-stamp an > existing implementation ? > > Since we are not yet a WG, it is not my understanding that it is > what a WG should attempt to do. > > Denis > >> You cannot assume that the rs is in communication with the >> user/resource owner during the other interchanges. That would not >> be the case in my implementation. >> >> thx ..Tom (mobile) >> >> On Fri, Jun 26, 2020, 9:04 AM Denis > > wrote: >> >> Tom and Justin, >> >> Why do want to make things complicated when they are quite >> simple ? >> >> The statement saying "the as and rs most likely have an >> ongoing security context on which to build subsequent >> interchanges" >> would have severe limitations in terms of scalability and >> privacy. >> >> The principle where a RS would only have relationships with >> one AS would make the model non scalable. >> It would prevent to get attributes from two different ASs,  >> for example: >> identity attributes from a bank and a master degree diploma >> from a university. >> >> For privacy reasons, every AS should know as little as >> possible about the interactions between a client and multiple >> RSs. >> It is even possible that this goes as little as knowing >> /nothing at all/. >> >> The OAuth 2.0 assumption where the AS is in a position to >> know all the interactions of a given user has with all the RSs >> that an AS server has a relationship with should not be >> re-iterated. >> >> The relationships between RSs may change at any time and it >> woauld not be reasonable to inform the ASs in real time >> about these interactions. >> >> As already stated in an earlier email: >> >> No one (including ASs) is able to predict in advance >> which access tokens will be needed, since they depend >> upon the kind of operation(s) >> the client will be willing to perform. (...) >> >> To handle the complex case you envision, the full >> workflow of operations needs to be considered with a >> detailed focus on the time >> at which the user's *consent and choice* happens >> (/consent and choice/ is the first privacy principle from >> ISO 29100). >> >> A RS whether the first one of a RS chain and a subsequent >> one, taking into consideration the kind of operation that >> will be requested by the client, >> should be is able to inform the user about which kind of >> attributes are needed and from which AS(s) [note the plural], >> they may be obtained. >> >> Denis >> >> >>> While there are multiple reasons for bound tokens, each with >>> their own needs, I strongly encourage an effort to create a >>> single broad spec that could address the common security >>> issues. Tobias, this is the general idea you were pushing on >>> application level networking. As a general rule, I >>> believe that the current effort to base security on channel >>> binding has already been extended beyond its capabilities. >>> (That is the concept that the HTTPS key is used as the >>> security for the messages.) So, can't we focus on the >>> problem of identifying the participants to an extended set >>> of interchanges. This would formalize the earlier statements >>> that the as and rs most likely have an ongoing security >>> context on which to build subsequent interchanges. >>> Peace ..tom >>> >>> >>> On Fri, Jun 26, 2020 at 6:23 AM Justin Richer >>> > wrote: >>> >>> On Jun 25, 2020, at 9:07 PM, Tobias Looker >>> >> > wrote: >>>> >>>> I find this feature interesting and think it could be >>>> an important pattern going forward to enable an AS to >>>> be able to describe the utility of a token to the >>>> client, however as already pointed out in the thread I >>>> think there is some potential hidden complexity that >>>> would need to be ironed out such that it does not make >>>> the simple things complicated. >>>> >>>> Justin, do you see this feature as something the client >>>> has to explicitly request, i.e "please give me access >>>> and instructions on how to use my access" or rather >>>> that the AS would just return this information in >>>> conjunction with the access token if it had it available? >>>> >>> >>> This is something that I’d brought up as a possibility >>> on the previous thread — something like a flag the >>> client would set. This would be especially important if >>> the AS wants to return multiple access tokens but the >>> client requested 1, or the client requested N and the AS >>> wants to return M in response. Basically any time >>> there’s a mismatch, that’s extra complexity on the >>> client that I really don’t think we want to be >>> universal. A flag to turn that kind of direction and >>> splitting on would be a potential start. But there are >>> potential snags here too, and it comes down to how you >>> manage the defaults... >>> >>>> > This is just the start, too. Things get even more >>>> complex if the client can ask for multiple different >>>> kinds of resources at once. What if the AS decides that >>>> the client needs a hyper-focused directed token for one >>>> part of the API, but can use a general token for other >>>> stuff? Can it signal that to the client? And if it can, >>>> does that mean that all clients need to be prepared for >>>> that kind of thing? >>>> >>>> Would a potential default be that if a client did for >>>> any reason not support processing the additional >>>> information returned with the access_token, just to >>>> ignore it? I think in the spirit of keeping the simple >>>> things simple, this potentially makes sense? >>> >>> That’s the real trick, if you ask me. It has to be >>> :safe: for a client to ignore this information. Which >>> means the AS can’t rely on the client “doing the right >>> thing” with the information in the “token directions” >>> portion of the response. Even setting aside the advanced >>> and related “split tokens” idea above, we need to make >>> sure that an AS/RS setup is built such that if the AS >>> tells a client “only do X with your token” and the >>> client does “Y”, then there are other protections and >>> practices in place to prevent things from going haywire >>> if the client does “Y” either by accident or through >>> ignorance. >>> >>> If OAuth 2 has taught us anything, it’s that client >>> applications are going to be the laziest participants in >>> the security model. And that makes sense, really — >>> security isn’t what the client apps are trying to do, >>> they’re trying to use the RS to do something. So we need >>> to make sure that whatever system we design will fail on >>> the safe side as much as possible, and keep things >>> simple for the client. >>> >>>> >>>> > here are some worked out samples of this: >>>> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token >>>> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ >>>> Peace ..tom >>>> >>>> As one of the authors of those mentioned drafts, I am >>>> interested in discussing that, but perhaps on a >>>> seperate thread? As at least the bound assertion spec >>>> is primarily concerned with binding mechanisms for the >>>> artifacts produced from an authorization flow >>>> (specifically identity claims), whereas I think >>>> directed access tokens is just more generally talking >>>> about whether GNAP should support an AS conveying how >>>> to use an access_token it produces during a flow with a >>>> client. >>>> >>> >>> I think that these are separate issues as well. >>> >>>  — Justin >>> >>>> Thanks, >>>> Mattr website >>>> *Tobias Looker* >>>> Mattr >>>> +64 (0) 27 378 0461 >>>> tobias.looker@mattr.global >>>> >>>> Mattr website Mattr on >>>> LinkedIn >>>> Mattr on Twitter >>>> Mattr on Github >>>> >>>> >>>> This communication, including any attachments, is >>>> confidential. If you are not the intended recipient, >>>> you should not read it - please contact me immediately, >>>> destroy it, and do not copy or use any part of this >>>> communication or disclose anything about it. Thank you. >>>> Please note that this communication does not designate >>>> an information system for the purposes of the >>>> Electronic Transactions Act 2002. >>>> >>>> >>>> On Wed, Jun 24, 2020 at 10:14 PM Denis >>>> > wrote: >>>> >>>> Justin, I fear we are still far away from an >>>> agreement about what this BoF should do. >>>> >>>> Tom Jones is saying " I am getting tired of the >>>> whack-a-mole approach ..." >>>> >>>> I don't agree with you when you write: "I think >>>> it’s going to be overwhelmingly common that a given >>>> RS is going to trust exactly one AS >>>> that it knows about ahead of time". Such an >>>> architecture would have exactly the same >>>> limitations as OAuth 2.0. and would not be scalable. >>>> >>>> Before we start, we should have a clear view of the >>>> whole picture rather than starting from one >>>> scenario and expanding it in many different directions. >>>> For building an architecture, a pre-requirement is >>>> to define ALL the trust relationships. I don't >>>> believe that we have an agreement at this time on what >>>> these trust relationships are. >>>> >>>> You are also using the following wording: "methods >>>> for the AS and RS to communicate what the token’s >>>> good for". >>>> With such a paradigm, it would be impossible to >>>> protect the user's privacy. >>>> >>>> A key question is : Will GNAP take care of the >>>> user's privacy or will GNAP *prevent *to take care >>>> of the user's privacy ? >>>> >>>> About "the ability for the client to get several >>>> access tokens to get different resources from one >>>> request" is indeed a complex case. >>>> >>>> No one (including ASs) is able to predict in >>>> advance which access tokens will be needed, since >>>> they depend upon the kind of operation(s) >>>> the client will be willing to perform. For privacy >>>> reasons, ASs should be kept ignorant of all the >>>> operations that a client is going to perform >>>> on one or more resource servers. I believe that >>>> every effort should be made to avoid the AS to be >>>> in a position to be able to trace the operations >>>> performed by its clients on various RSs. >>>> >>>> To handle the complex case you envision, the full >>>> workflow of operations needs to be considered with >>>> a detailed focus on the time >>>> at which the user's *consent and choice* happens >>>> (/consent and choice/ is the first privacy >>>> principle from ISO 29100). >>>> >>>> First of all, an access token could be targeted to >>>> a service rather than to a server. This would >>>> already solve many cases. >>>> >>>> When a RS needs to call another RS (which does not >>>> support the same service) then the client should be >>>> informed by the first RS. >>>> His "consent and choice" should then be obtained by >>>> the first RS and, when the user agrees, the client >>>> should then ask an access token >>>> to one of the ASs trusted by the second RS in order >>>> to perform the subsequent operation. >>>> >>>> Denis >>>> >>>> PS.  In an email sent on June 23 you wrote: " I >>>> think an on-device AS is an important use case".  I >>>> am sorry, but I don't understand. >>>>        However, I do understand what "a >>>> server-based AS" is. >>>> >>>> >>>>> Denis, thanks for the great comments. I think that >>>>> your trust model is pretty different from what I’d >>>>> laid out initially, and while it’s an interesting >>>>> and important one, it is not what I meant by >>>>> “multiple access tokens” in my discussion below. I >>>>> think that might be the cause of some disconnect >>>>> here, but that doesn’t mean it’s out of reach for >>>>> what the WG is after. >>>>> >>>>> When I refer to multiple access tokens, and what >>>>> the charter calls out as multiple access tokens, >>>>> is the ability for the client to get several >>>>> access tokens to get different resources from one >>>>> request. I personally see this as an optimization >>>>> of a specific set of use cases, some of which I >>>>> discussed in my original email. There are others, >>>>> I’m sure, but all the ones I’ve seen are around >>>>> the client needing to get several different kinds >>>>> of access through an AS. >>>>> >>>>> I think it’s going to be overwhelmingly common >>>>> that a given RS is going to trust exactly one AS >>>>> that it knows about ahead of time. But for RS’s >>>>> that can trust multiple AS’s, then we should have >>>>> a model that can accommodate that as well. That’s >>>>> why the charter calls out methods for the AS and >>>>> RS to communicate what the token’s good for. I >>>>> think the basis of those methods is going to start >>>>> with a common token model, and likely incorporate >>>>> into things like token formats and >>>>> introspection-style token APIs. >>>>> >>>>>  — Justin >>>>> >>>>>> On Jun 22, 2020, at 3:55 AM, Denis >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Hello Justin, >>>>>> >>>>>> A few comments between the lines. >>>>>> >>>>>>> One of the most important aspects to GNAP is >>>>>>> going to be an ability to address things that >>>>>>> OAuth 2 can’t, or at least can’t do without >>>>>>> significant gymnastics. So with that, I wanted >>>>>>> to bring back a use case discussion that >>>>>>> originally came up while we were talking about >>>>>>> the possibility of multiple access tokens, a few >>>>>>> months back. I don’t know if this concept has a >>>>>>> regular term, so I’m going to call it “directed >>>>>>> access tokens” until we come up with something >>>>>>> better — assuming we decide this is worthwhile. >>>>>> >>>>>> I don't understand what may mean "directed access >>>>>> tokens” but I understand what means "multiple >>>>>> access tokens". >>>>>> When speaking of "multiple access tokens", these >>>>>> access tokens may come from one or more ASs. >>>>>> >>>>>>> In OAuth, the client’s supposed to always know >>>>>>> where to send its access token, and that >>>>>>> knowledge is completely outside the protocol. >>>>>>> This makes a lot of sense for many (if not most) >>>>>>> deployments, as OAuth is really there to enable >>>>>>> the API access that the client already knows about. >>>>>>> >>>>>>> But we’re now in a world where a client could be >>>>>>> talking to a generic API that could be deployed >>>>>>> at a number of different places, or a cloud >>>>>>> deployment that the AS wants to be able to >>>>>>> dispatch the client to. >>>>>> >>>>>> As soon the AS is placed (again) at the centre of >>>>>> the model, the AS will have the ability to act as >>>>>> "Big Brother". >>>>>> OAuth 2.0 has not taken care of privacy issues. >>>>>> On the contrary, GNAP should take care of them. >>>>>> >>>>>>> In order to do this, the AS needs to be able to >>>>>>> communicate to the client not only the token >>>>>>> information (and any related key and >>>>>>> presentation information), but also a set >>>>>>> of/directions/ about what that specific token is >>>>>>> good for. This needs to be information outside >>>>>>> the token itself, since I believe we want to >>>>>>> keep OAuth 2’s feature of having the token be >>>>>>> opaque to the client. Note: while we could map >>>>>>> all of these to different resource requests (in >>>>>>> XYZ parlance) or scopes (in OAuth 2 legacy >>>>>>> parlance) on the request side, this isn’t enough >>>>>>> to tell the client what to do with the token/if >>>>>>> it doesn’t know already/. >>>>>>> >>>>>>> I know of two use cases already in the wild, >>>>>>> where people are addressing things using a mix >>>>>>> of existing standards and some proprietary >>>>>>> extensions to address things within their silos. >>>>>>> I’ll try to summarize here, but I know the folks >>>>>>> I’ve been talking to about this are also on the >>>>>>> list so hopefully they can chime in with more >>>>>>> detail or any corrections for something I’ve >>>>>>> missed. >>>>>>> >>>>>>> (1) The client knows what resource it’s calling, >>>>>>> but it doesn’t know where it’s hosted. >>>>>>> Everything is in a single security domain >>>>>>> controlled by the AS, >>>>>> >>>>>> Speaking of "multiple access tokens" is in >>>>>> contradiction with single security domain >>>>>> "controlled" by an AS. >>>>>> A user may need to demonstrate some of his >>>>>> identity attributes granted e.g. by his bank but >>>>>> may also >>>>>> need to demonstrate one or more diplomas granted >>>>>> by one or more universities. The bank cannot be >>>>>> the "primary issuer" of a university diploma. It >>>>>> should not be either a "secondary issuer", because >>>>>> the bank does not "/need to know"/what are the >>>>>> diplomas of the user. >>>>>> >>>>>>> but the AS needs to decide at runtime which >>>>>>> specific instance of the API to direct the >>>>>>> client to. Since things are closely tied >>>>>>> together, the client just needs to effectively >>>>>>> known an identifier for the RS, and this is >>>>>>> currently implemented as a URI. Once the client >>>>>>> has that identifier, it knows how to dispatch >>>>>>> that token to that instance of the RS. >>>>>> >>>>>> There is no good reason why the AS should be >>>>>> involved in that step. >>>>>> OAuth 2.0 is/was implicitly mandating a strong >>>>>> relationship between ASs and RSs which makes it >>>>>> non scalable. >>>>>> GNAP should be based on a simple trust >>>>>> relationship : a given RS trusts some ASs for >>>>>> access tokens that contains some types of attributes. >>>>>> An AS should not need to know in advance (or even >>>>>> at the time of an access token request) the RSs >>>>>> that are trusting it. >>>>>> >>>>>> A client could first talk to a "global service >>>>>> provider" which has the knowledge of the >>>>>> different RSs affiliated to it. >>>>>> >>>>>>> (2) The client knows what kind of thing it’s >>>>>>> looking for, but doesn’t know who to ask it from. >>>>>> >>>>>> Once again, the client could first talk to a >>>>>> "global service provider" which has the knowledge >>>>>> of the different RSs affiliated to it. >>>>>> >>>>>>> There’s a cross-domain trust that’s bridged by >>>>>>> the AS, and the AS needs to dispatch to >>>>>>> different resources depending on which user >>>>>>> logged in (and possibly what the user consented >>>>>>> to). To make things more concrete, the client >>>>>>> needs to get driver’s license information, but >>>>>>> doesn’t know ahead of time which of the many >>>>>>> state/provincial bureaus to call to get that >>>>>>> information because it doesn’t know yet who the >>>>>>> user is. >>>>>> >>>>>> When a user has a driving license, he knows its >>>>>> issuer. The user can then provide some hint to >>>>>> the client. >>>>>> >>>>>>> The AS will know who the user is once they log >>>>>>> in and approve things, and so it can direct the >>>>>>> client to call the correct RS. Since this is a >>>>>>> relatively simple API with a pre-negotiated >>>>>>> cross-domain trust, the AS returns a URL that >>>>>>> the client presents the token at. >>>>>> >>>>>>  A single AS should not be aware of all the >>>>>> attributes a user has. >>>>>> >>>>>>> >>>>>>> As far as I know, in both of these cases, the >>>>>>> token is only good for that API and not others — >>>>>>> but more on that later. >>>>>>> >>>>>>> A simple thing to do is just give back a URL >>>>>>> with the access token, which tells the client >>>>>>> where to go. >>>>>>> >>>>>>> { >>>>>>> “access_token”: { >>>>>>> “value”: “87yui843yfer”, >>>>>>> “resource_uri”: “https://example/foo" >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> This is good for some kinds of APIs, but it’s >>>>>>> limiting because not all APIs dispatch based on >>>>>>> the URL. An AS might want to divvy up access >>>>>>> tokens to an API that’s keyed on headers, or >>>>>>> verbs, or any number of things. And it doesn’t >>>>>>> tell us immediately what to do about non-exact >>>>>>> URL matches. Can the client add query parameters >>>>>>> and still use the token? What about path >>>>>>> segments? I like that this simple approach >>>>>>> addresses some common deployments that we >>>>>>> already see today (see above), it’s not >>>>>>> universal. Do we want or need a universal >>>>>>> description language for directing where tokens go? >>>>>>> >>>>>>> This also opens up a whole new set of security >>>>>>> questions. If the AS can now direct the client >>>>>>> where to use the token, could a rogue AS >>>>>>> convince a legit client to use a stolen token at >>>>>>> the wrong RS? And what if the client ignores the >>>>>>> directions from the AS entirely? Could this open >>>>>>> up new avenues of attack? >>>>>>> >>>>>>> This is just the start, too. Things get even >>>>>>> more complex if the client can ask for multiple >>>>>>> different kinds of resources at once. What if >>>>>>> the AS decides that the client needs a >>>>>>> hyper-focused directed token for one part of the >>>>>>> API, but can use a general token for other >>>>>>> stuff? Can it signal that to the client? And if >>>>>>> it can, does that mean that all clients need to >>>>>>> be prepared for that kind of thing? >>>>>>> >>>>>>> I firmly believe that whatever we build in GNAP, >>>>>>> we need to optimize for the overwhelmingly >>>>>>> common use case of a client getting a single >>>>>>> access token to call APIs that it already knows >>>>>>> about. Anything we add on top of that really >>>>>>> can’t get in the way of this, because if it >>>>>>> does, there’s very small chance that people will >>>>>>> try to use this for everyday things. Keep the >>>>>>> simple things simple, and the complex things >>>>>>> possible, after all. >>>>>>> >>>>>>> I’m really looking forward to hearing what the >>>>>>> community thinks about these use cases, and >>>>>>> hopefully the people I’ve chatted with offline >>>>>>> about this can join the conversation and provide >>>>>>> more light than I was able to. >>>>>> >>>>>> The two use cases which are considered above are: >>>>>> >>>>>> (1) The client knows what resource it’s >>>>>> calling, but it doesn’t know where it’s hosted. >>>>>> (2) The client knows what kind of thing it’s >>>>>> looking for, but doesn’t know who to ask it from. >>>>>> >>>>>> That does not mean in any way that these two use >>>>>> cases should be solved by placing the AS at the >>>>>> centre of the solution. >>>>>> >>>>>> Denis >>>>>> >>>>>>> >>>>>>>  — 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 >>>> >>>> >>>> This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002. >>> >>> -- >>> 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 >> > --------------ACB074273DA7DD34ABC0AB7B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Tom,

In the model I have in mind, the ro may directly communicate with the rs (or open a session with the rs) to tell what the rules are,
i.e. which attributes are needed for some kinds of operations and from which as(s) these attributes may be obtained.

The ro is not involved in anyway at the time a client attempts to perform an operation.

Denis

no you should not assume that. But if your standard demands communications between the ro & rs for every release of data, then i could not use the standard.
Peace ..tom


On Fri, Jun 26, 2020 at 9:51 AM Denis <denis.ietf@free.fr> wrote:
Tom,

Should I understand that you are willing to rubber-stamp an existing implementation ?

Since we are not yet a WG, it is not my understanding that it is what a WG should attempt to do.

Denis

You cannot assume that the rs is in communication with the user/resource owner during the other interchanges. That would not be the case in my implementation.

thx ..Tom (mobile)

On Fri, Jun 26, 2020, 9:04 AM Denis <denis.ietf@free.fr> wrote:
Tom and Justin,

Why do want to make things complicated when they are quite simple ?

The statement saying "the as and rs most likely have an ongoing security context on which to build subsequent interchanges"
would have severe limitations in terms of scalability and privacy.

The principle where a RS would only have relationships with one AS would make the model non scalable.
It would prevent to get attributes from two different ASs,  for example: 
identity attributes from a bank and a master degree diploma from a university.

For privacy reasons, every AS should know as little as possible about the interactions between a client and multiple RSs.
It is even possible that this goes as little as knowing nothing at all.

The OAuth 2.0 assumption where the AS is in a position to know all the interactions of a given user has with all the RSs
that an AS server has a relationship with should not be re-iterated.

The relationships between RSs may change at any time and it woauld not be reasonable to inform the ASs in real time
about these interactions.

As already stated in an earlier email:
No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. (...)

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).
A RS whether the first one of a RS chain and a subsequent one, taking into consideration the kind of operation that will be requested by the client,
should be is able to inform the user about which kind of attributes are needed and from which AS(s) [note the plural], they may be obtained.

Denis


While there are multiple reasons for bound tokens, each with their own needs, I strongly encourage an effort to create a single broad spec that could address the common security issues. Tobias, this is the general idea you were pushing on application level networking. As a general rule, I believe that the current effort to base security on channel binding has already been extended beyond its capabilities. (That is the concept that the HTTPS key is used as the security for the messages.) So, can't we focus on the problem of identifying the participants to an extended set of interchanges. This would formalize the earlier statements that the as and rs most likely have an ongoing security context on which to build subsequent interchanges.
Peace ..tom


On Fri, Jun 26, 2020 at 6:23 AM Justin Richer <jricher@mit.edu> wrote:
On Jun 25, 2020, at 9:07 PM, Tobias Looker <tobias.looker@mattr.global> wrote:

I find this feature interesting and think it could be an important pattern going forward to enable an AS to be able to describe the utility of a token to the client, however as already pointed out in the thread I think there is some potential hidden complexity that would need to be ironed out such that it does not make the simple things complicated.

Justin, do you see this feature as something the client has to explicitly request, i.e "please give me access and instructions on how to use my access" or rather that the AS would just return this information in conjunction with the access token if it had it available?


This is something that I’d brought up as a possibility on the previous thread — something like a flag the client would set. This would be especially important if the AS wants to return multiple access tokens but the client requested 1, or the client requested N and the AS wants to return M in response. Basically any time there’s a mismatch, that’s extra complexity on the client that I really don’t think we want to be universal. A flag to turn that kind of direction and splitting on would be a potential start. But there are potential snags here too, and it comes down to how you manage the defaults...

> This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

Would a potential default be that if a client did for any reason not support processing the additional information returned with the access_token, just to ignore it? I think in the spirit of keeping the simple things simple, this potentially makes sense?

That’s the real trick, if you ask me. It has to be :safe: for a client to ignore this information. Which means the AS can’t rely on the client “doing the right thing” with the information in the “token directions” portion of the response. Even setting aside the advanced and related “split tokens” idea above, we need to make sure that an AS/RS setup is built such that if the AS tells a client “only do X with your token” and the client does “Y”, then there are other protections and practices in place to prevent things from going haywire if the client does “Y” either by accident or through ignorance. 

If OAuth 2 has taught us anything, it’s that client applications are going to be the laziest participants in the security model. And that makes sense, really — security isn’t what the client apps are trying to do, they’re trying to use the RS to do something. So we need to make sure that whatever system we design will fail on the safe side as much as possible, and keep things simple for the client.


> here are some worked out samples of this:
Peace ..tom

As one of the authors of those mentioned drafts, I am interested in discussing that, but perhaps on a seperate thread? As at least the bound assertion spec is primarily concerned with binding mechanisms for the artifacts produced from an authorization flow (specifically identity claims), whereas I think directed access tokens is just more generally talking about whether GNAP should support an AS conveying how to use an access_token it produces during a flow with a client.


I think that these are separate issues as well.

 — Justin

Thanks,
Mattr website  
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
Mattr website Mattr on LinkedIn Mattr on Twitter Mattr on Github

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


On Wed, Jun 24, 2020 at 10:14 PM Denis <denis.ietf@free.fr> wrote:
Justin, I fear we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I am getting tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it’s going to be overwhelmingly common that a given RS is going to trust exactly one AS
that it knows about ahead of time". Such an architecture would have exactly the same limitations as OAuth 2.0. and would not be scalable.

Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions.
For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believe that we have an agreement at this time on what
these trust relationships are.

You are also using the following wording: "methods for the AS and RS to communicate what the token’s good for".
With such a paradigm, it would be impossible to protect the user's privacy.

A key question is : Will GNAP take care of the user's privacy or will GNAP prevent to take care of the user's privacy ?

About "the ability for the client to get several access tokens to get different resources from one request" is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform
on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).

First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases.

When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS.
His "consent and choice" should then be obtained by the first RS and, when the user agrees, the client should then ask an access token
to one of the ASs trusted by the second RS in order to perform the subsequent operation. 

Denis

PS.  In an email sent on June 23 you wrote: " I think an on-device AS is an important use case".  I am sorry, but I don't understand.
       However, I do understand what "a server-based AS" is.


Denis, thanks for the great comments. I think that your trust model is pretty different from what I’d laid out initially, and while it’s an interesting and important one, it is not what I meant by “multiple access tokens” in my discussion below. I think that might be the cause of some disconnect here, but that doesn’t mean it’s out of reach for what the WG is after.

When I refer to multiple access tokens, and what the charter calls out as multiple access tokens, is the ability for the client to get several access tokens to get different resources from one request. I personally see this as an optimization of a specific set of use cases, some of which I discussed in my original email. There are others, I’m sure, but all the ones I’ve seen are around the client needing to get several different kinds of access through an AS. 

I think it’s going to be overwhelmingly common that a given RS is going to trust exactly one AS that it knows about ahead of time. But for RS’s that can trust multiple AS’s, then we should have a model that can accommodate that as well. That’s why the charter calls out methods for the AS and RS to communicate what the token’s good for. I think the basis of those methods is going to start with a common token model, and likely incorporate into things like token formats and introspection-style token APIs. 

 — Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr> wrote:

Hello Justin,

A few comments between the lines.

One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can’t, or at least can’t do without significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don’t know if this concept has a regular term, so I’m going to call it “directed access tokens” until we come up with something better — assuming we decide this is worthwhile. 

I don't understand what may mean "directed access tokens” but I understand what means "multiple access tokens". 
When speaking of "multiple access tokens", these access tokens may come from one or more ASs.

In OAuth, the client’s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we’re now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to. 

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of directions about what that specific token is good for. This needs to be information outside the token itself, since I believe we want to keep OAuth 2’s feature of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn’t enough to tell the client what to do with the token if it doesn’t know already. 

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I’ll try to summarize here, but I know the folks I’ve been talking to about this are also on the list so hopefully they can chime in with more detail or any corrections for something I’ve missed. 

(1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted. Everything is in a single security domain controlled by the AS, 

Speaking of "multiple access tokens" is in contradiction with single security domain "controlled" by an AS. 
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also 
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be 
the "primary issuer" of a university diploma. It should not be either a "secondary issuer", because 
the bank does not "need to know" what are the diplomas of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

There is no good reason why the AS should be involved in that step. 
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it. 

(2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from. 

Once again, the client could first talk to a "global service provider" which has the knowledge of the different RSs affiliated to it. 

There’s a cross-domain trust that’s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver’s license information, but doesn’t know ahead of time which of the many state/provincial bureaus to call to get that information because it doesn’t know yet who the user is. 

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at. 

 A single AS should not be aware of all the attributes a user has. 


As far as I know, in both of these cases, the token is only good for that API and not others — but more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go. 

{
“access_token”: {
“value”: “87yui843yfer”,
“resource_uri”: “https://example/foo"
}
}

This is good for some kinds of APIs, but it’s limiting because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that’s keyed on headers, or verbs, or any number of things. And it doesn’t tell us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it’s not universal. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can’t get in the way of this, because if it does, there’s very small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I’m really looking forward to hearing what the community thinks about these use cases, and hopefully the people I’ve chatted with offline about this can join the conversation and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what resource it’s calling, but it doesn’t know where it’s hosted.
(2) The client knows what kind of thing it’s looking for, but doesn’t know who to ask it from. 

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Denis


 — 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

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

--
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



--------------ACB074273DA7DD34ABC0AB7B-- From nobody Fri Jun 26 10:22:10 2020 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 580BB3A09EA; Fri, 26 Jun 2020 10:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 H_7ZS8B8wUEA; Fri, 26 Jun 2020 10:22:05 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CD13A09B3; Fri, 26 Jun 2020 10:22:05 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id 9so11132597ljc.8; Fri, 26 Jun 2020 10:22:05 -0700 (PDT) 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=Abs5g8gR78BFz5HJQtQxLXVKQy2U3QlIAu1WemC+KAs=; b=hr7JJxcOpCoCY6VoItY0JMo/xdM1k0UnpSylE1qvp4BQuRK+U/te1ydRJQL7Zqr3vL V8TsfgLbsFKVL9Jo4lF11SLW9CF5VMnwigI/YEkfjBKf1VrGdS4brisd6TVWktO7M7mb vUIfluY70nA2scBGQ6dap7npEHF47fIcxHPOTqH+ZpLF1HCFlkmsdp9Rpux7wpHj9yOd 5J7eoBuwsue76C0VQjLMf4Fr/DC5DoV4NvaSTS6BHTUMdzqC1QqWqHAbk21/I2oWvXp8 2iDUCdATk+MlDzs+RPyF7JXTYEfnNBD+Gp9GtgzF29SrLFhxgpfx5Lp7+YviemIVniw2 WUBg== 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=Abs5g8gR78BFz5HJQtQxLXVKQy2U3QlIAu1WemC+KAs=; b=pvYTRYVnLB3Q3Jr3ZXfg2R0v6iqHbzRbIOSA+ra5C53opoe5hDcnmkSBYrscZumgz7 GMfCrmxZN90/Mw3rzpRQVT4QJmVFLOboppa0pkIcjmnuwDSJ8GKxYGJ3ytbpRYrtJ2h3 ZisfSDpYNU5GFc1lrMj44kKUPiNF5gUxxJbzV1XEq8+1sUW0SgiaGT44NKB183SsQhF/ YfODQMO5iv4JYPqzKvncPBWzJ7D8jfYo09HQf6xgeX4uZttgqK4FXKB6Dmy25I0OeFNp yzUIM/Bp9pe4if9wAIeRK7wxgxfMQ8EK0soqDRErIXJewr12xBlazxxzLs0eyS1aNt0q HQFQ== X-Gm-Message-State: AOAM532pDhMe0AuBodpaGFT0nhnbbZrlTdIhhRjclM8xx+Mf+lLW6FB6 mQBhpP6yKhpuHVEWSyWJiWsA+mXaYKHPbFxZ8k1HsuzpzwA= X-Google-Smtp-Source: ABdhPJxrMKXYn57sK7SFQ9FM7aZMP+gt6bJSoXLUbcQ1N8cqiiMmEk3d8VhGFrztzJLV+zkILm+2wB/Z0eHMWv65HXE= X-Received: by 2002:a05:651c:547:: with SMTP id q7mr1791605ljp.437.1593192123131; Fri, 26 Jun 2020 10:22:03 -0700 (PDT) MIME-Version: 1.0 References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> In-Reply-To: <159318778098.29096.6482921706088845432@ietfa.amsl.com> From: Dick Hardt Date: Fri, 26 Jun 2020 10:21:27 -0700 Message-ID: To: iesg@ietf.org Cc: txauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000008eed2405a8fff285" Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 26 Jun 2020 17:22:08 -0000 --0000000000008eed2405a8fff285 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am concerned with the following milestones: Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to WGLC Oct 2021 - Key presentation mechanism binding to the core protocol, detached HTTP signatures, to WGLC Oct 2021 - Key presentation mechanism binding to the core protocol, embedded HTTP signature, to WGLC I think it is overly prescriptive to specify which key presentation mechanisms will be created, and it implies that other key presentation mechanisms will not be worked on. While it is possible that channel binding mechanisms such as TLS, detached HTTP signatures, and embedded HTTP signatures will be appropriate key presentation mechanisms for GNAP, it is also quite possible that the WG will determine one or more are not appropriate, or the underlying mechanism may not gain acceptance, or channel binding is not always needed. For example, the effort to bind OAuth access tokens using RFC8471 was disbanded. Additionally, there are two primary communication channels in the protocol that have different security requirements. The client to authorization server, and the client to resource server. The term "core protocol" is vague and could be construed that the same mechanism MUST be used in both channels. I propose the following new wording: Oct 2021 - Key presentation mechanism binding for each communication channel to WGLC. ---------- Forwarded message --------- From: The IESG Date: Fri, Jun 26, 2020 at 9:10 AM Subject: WG Review: Grant Negotiation and Authorization Protocol (gnap) To: IETF-Announce Cc: A new IETF WG has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-07-06. Grant Negotiation and Authorization Protocol (gnap) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Yaron Sheffer Leif Johansson Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: txauth@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/txauth Archive: https://mailarchive.ietf.org/arch/browse/txauth/ Group page: https://datatracker.ietf.org/group/gnap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/ This group is chartered to develop a fine-grained delegation protocol for authorization and API access, as well as requesting and providing user identifiers and claims. This protocol will allow an authorizing party to delegate access to client software through an authorization server. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions. The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the interaction channels, such as the end user=E2=80=99s browser, from the delegation chann= el, which happens directly between the client and the authorization server (in contrast with OAuth 2.0, which is initiated by the client redirecting the user=E2=80= =99s browser). The protocol will include a means of specifying how the user can potentially be involved in an interactive fashion during the delegation process. The client and Authorization Server (AS) will use these interactio= n mechanisms to involve the user, as necessary, to make authorization decisions. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types o= f clients and interaction channels. The group will define interoperability for this protocol between different parties, including - client and authorization server; - client and resource server; and - authorization server and resource server. The group will seek to minimize assumptions about the form of client applications, allowing for: - Fine-grained specification of access - Approval of AS attestation to identifiers and other identity claims - Approval of access to multiple resources and APIs in a single interaction - Support for multiple access tokens in a single request and response - Support for directed, audience-restricted access tokens - Separation between the party authorizing access and the party operating the client requesting access 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 - Mechanisms for conveying user, software, organization, and other information used in authorization decisions - Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys - Optimized inclusion of additional information (including identifiers and identity assertions) through the delegation process Additionally, the group will provide mechanisms for management of the protocol lifecycle including: - Discovery of the authorization server - Revocation of active tokens - Mechanisms for the AS and RS to communicate the access granted by an access token Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible. This group is not chartered to develop extensions to OAuth 2.0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be directed to the OAuth Working Group, including functionality back-ported from the protocol developed here to OAuth 2.0. The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. This group is no= t chartered to develop new cryptographic methods. The group is chartered to develop mechanisms for conveying identity information within the protocol including existing identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertion= s (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas fo= r user information, profiles, or other identity attributes, unless a viable existing format is not available. The initial work will focus on using HTTPS for communication between the client and the authorization server, taking advantage of optimization features of HTTP/2 and HTTP/3 where possible, and will strive to enable simple mapping to other protocols such as COAP when doing so does not conflict with the primary focus. Milestones to include: - Core delegation protocol - Key presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded HTTP signatures - Conveyance mechanisms for identifiers and assertions - Guidelines for use of protocol extension points - (if needed) Guidelines on migration paths, implementation, and operations Where possible, the group will seek to make use of tools to guide and infor= m the standardization process including formal analysis, architecture documents, and use case documents. These artifacts will not be considered as working group milestones or deliverables. The working group will cooperate and coordinate with other IETF WGs such as OAUTH, and work with external organizations, such as the OpenID Foundation, as appropriate. Milestones: Jul 2021 - Core delegation protocol in WGLC Oct 2021 - Key presentation mechanism binding to the core protocol, TLS, to WGLC Oct 2021 - Key presentation mechanism binding to the core protocol, detached HTTP signatures, to WGLC Oct 2021 - Key presentation mechanism binding to the core protocol, embedded HTTP signature, to WGLC Dec 2021 - Guidelines for use of protocol extension points to WGLC Feb 2022 - Guidelines on migration paths, implementation, and operations to WGLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce =E1=90=A7 --0000000000008eed2405a8fff285 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


I am c= oncerned with the following milestones:


=
=C2=A0 Oct 2021 -=C2=A0Key=C2=A0presentation=C2=A0mechanism binding to the core p= rotocol, TLS, to
=C2=A0 WGLC

=C2=A0 Oct 2021 -=C2=A0Key=C2=A0presentation= =C2=A0mechanism binding to the core protocol,
=C2=A0 detached HTTP signa= tures, to WGLC

=C2=A0 Oct 2021 -=C2=A0Key=C2=A0presentation=C2=A0mechanism bind= ing to the core protocol,
=C2=A0 embedded HTTP signature, to WGLC

I think it is overly prescriptive to specify which k= ey presentation mechanisms will be created, and it implies that other key p= resentation mechanisms will not be worked on. While it is possible that cha= nnel binding mechanisms such as TLS, detached HTTP signatures, and embedded= HTTP signatures will be appropriate key presentation mechanisms for GNAP, = it is also quite possible that the WG will determine one or more are not ap= propriate, or the underlying mechanism may not gain acceptance, or channel = binding is not always needed. For example, the effort to bind OAuth access = tokens using RFC8471 was disbanded.

Additionally, = there are two primary communication channels in the protocol that have diff= erent security requirements. The client to authorization server, and the cl= ient to resource server. The term "core protocol" is vague and co= uld be construed that the same mechanism MUST be used in both channels.

I propose the following new wording:

Oct 2021 - Key presentation mechanism binding for each communicati= on channel to WGLC.


---------- Forwarded= message ---------
From: The IESG <iesg-secretary@ietf.org>
Date: Fri, Jun 26, = 2020 at 9:10 AM
Subject: WG Review: Grant Negotiation and Authorization = Protocol (gnap)
To: IETF-Announce <ietf-announce@ietf.org>
Cc: <txauth@ietf.org>
<= /div>

A new IETF WG has been proposed in the Security Area. The IESG= has not made
any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the<= br> IESG mailing list (iesg@= ietf.org) by 2020-07-06.

Grant Negotiation and Authorization Protocol (gnap)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
=C2=A0 Yaron Sheffer <yaronf.ietf@gmail.com>
=C2=A0 Leif Johansson <leifj@sunet.se>

Assigned Area Director:
=C2=A0 Roman Danyliw <= rdd@cert.org>

Security Area Directors:
=C2=A0 Benjamin Kaduk <kaduk@mit.edu>
=C2=A0 Roman Danyliw <= rdd@cert.org>

Mailing list:
=C2=A0 Address: txauth= @ietf.org
=C2=A0 To subscribe: https://www.ietf.org/mailman/listin= fo/txauth
=C2=A0 Archive: https://mailarchive.ietf.org/arch/br= owse/txauth/

Group page: https://datatracker.ietf.org/group/gnap/

Charter: https://datatracker.ietf.org/doc/charter= -ietf-gnap/

This group is chartered to develop a fine-grained delegation protocol for authorization and API access, as well as requesting and providing user
identifiers and claims. This protocol will allow an authorizing party to delegate access to client software through an authorization server. It will=
expand upon the uses cases currently supported by OAuth 2.0 and OpenID Conn= ect
(itself an extension of OAuth 2.0) to support authorizations scoped as
narrowly as a single transaction, provide a clear framework for interaction=
among all parties involved in the protocol flow, and remove unnecessary
dependence on a browser or user-agent for coordinating interactions.

The delegation process will be acted upon by multiple parties in the protoc= ol,
each performing a specific role. The protocol will decouple the interaction=
channels, such as the end user=E2=80=99s browser, from the delegation chann= el, which
happens directly between the client and the authorization server (in contra= st
with OAuth 2.0, which is initiated by the client redirecting the user=E2=80= =99s
browser). The protocol will include a means of specifying how the user can<= br> potentially be involved in an interactive fashion during the delegation
process. The client and Authorization Server (AS) will use these interactio= n
mechanisms to involve the user, as necessary, to make authorization decisio= ns.
This decoupling avoids many of the security concerns and technical challeng= es
of OAuth 2.0 and provides a non-invasive path for supporting future types o= f
clients and interaction channels.

The group will define interoperability for this protocol between different<= br> parties, including
=C2=A0- client and authorization server;
=C2=A0- client and resource server; and
=C2=A0- authorization server and resource server.

The group will seek to minimize assumptions about the form of client
applications, allowing for:
- Fine-grained specification of access
- Approval of AS attestation to identifiers and other identity claims
- Approval of access to multiple resources and APIs in a single interaction=
- Support for multiple access tokens in a single request and response
- Support for directed, audience-restricted access tokens
- Separation between the party authorizing access and the party operating t= he
client requesting access

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 possessi= on
- User interaction mechanisms including web and non-web methods
- Mechanisms for conveying user, software, organization, and other
information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and binding resource=
requests to tokens and associated cryptographic keys
- Optimized inclusion of additional information (including identifiers and<= br> identity assertions) through the delegation process

Additionally, the group will provide mechanisms for management of the proto= col
lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Mechanisms for the AS and RS to communicate the access granted by an acce= ss
token

Although the artifacts for this work are not intended or expected to be
backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attem= pt
to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol=
where possible.

This group is not chartered to develop extensions to OAuth 2.0, and as such=
will focus on new technological solutions not necessarily compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be directed=
to the OAuth Working Group, including functionality back-ported from the protocol developed here to OAuth 2.0.

The group is chartered to develop mechanisms for applying cryptographic
methods, such as JOSE and COSE, to the delegation process. This group is no= t
chartered to develop new cryptographic methods.

The group is chartered to develop mechanisms for conveying identity
information within the protocol including existing identifiers (such as ema= il
addresses, phone numbers, usernames, and subject identifiers) and assertion= s
(such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable
Credentials). The group is not chartered to develop new formats for
identifiers or assertions, nor is the group chartered to develop schemas fo= r
user information, profiles, or other identity attributes, unless a viable existing format is not available.

The initial work will focus on using HTTPS for communication between the client and the authorization server, taking advantage of optimization
features of HTTP/2 and HTTP/3 where possible, and will strive to enable
simple mapping to other protocols such as COAP when doing so does not
conflict with the primary focus.

Milestones to include:
- Core delegation protocol
- Key presentation mechanism bindings to the core protocol including TLS, detached HTTP signature, and embedded HTTP signatures
- Conveyance mechanisms for identifiers and assertions
- Guidelines for use of protocol extension points
- (if needed) Guidelines on migration paths, implementation, and operations=

Where possible, the group will seek to make use of tools to guide and infor= m
the standardization process including formal analysis, architecture documen= ts,
and use case documents. These artifacts will not be considered as working group milestones or deliverables.

The working group will cooperate and coordinate with other IETF WGs such as=
OAUTH, and work with external organizations, such as the OpenID Foundation,=
as appropriate.

Milestones:

=C2=A0 Jul 2021 - Core delegation protocol in WGLC

=C2=A0 Oct 2021 - Key presentation mechanism binding to the core protocol, = TLS, to
=C2=A0 WGLC

=C2=A0 Oct 2021 - Key presentation mechanism binding to the core protocol, =
=C2=A0 detached HTTP signatures, to WGLC

=C2=A0 Oct 2021 - Key presentation mechanism binding to the core protocol,<= br> =C2=A0 embedded HTTP signature, to WGLC

=C2=A0 Dec 2021 - Guidelines for use of protocol extension points to WGLC
=C2=A0 Feb 2022 - Guidelines on migration paths, implementation, and operat= ions to
=C2=A0 =C2=A0WGLC



_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
<= img alt=3D"" style=3D"width:0px;max-height:0px;overflow:hidden" src=3D"http= s://mailfoogae.appspot.com/t?sender=3DaZGljay5oYXJkdEBnbWFpbC5jb20%3D&t= ype=3Dzerocontent&guid=3D0e0bba5f-c013-4870-b966-0787b4f845a9">=E1=90=A7
--0000000000008eed2405a8fff285-- From nobody Fri Jun 26 10:36:58 2020 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 415493A0BE3 for ; Fri, 26 Jun 2020 10:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 t_KrfZu-7Tbo for ; Fri, 26 Jun 2020 10:36:43 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0: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 1B11D3A0BF0 for ; Fri, 26 Jun 2020 10:36:42 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id k4so8732428oik.2 for ; Fri, 26 Jun 2020 10:36:42 -0700 (PDT) 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=ugUV7CfnncO++eWq6t6n+uWKh/GamHhgdFenJv4ItH4=; b=FtW9fmx5/y09WH2OhF8StwUHXWQk/35piIBHSTvA6iNhy+MY88fVsLeF0QQ4dVEFYE /YgVhAyNpiUUDuSMiTbD4UhNy5sQFRNSc+LCtCN2p8GkiFpXMP4FnD3iJ92+gJVIlGhN jsowSlPlP9CpeREXio2pVy5slC+MvShFOz35O5jZ/zXT5C5SoIvUJRK5317xXdkAlYqW iJ7X946FnADFg3TcG0tFbImQgZQfIAKTH8Q86KN6QQCTjNUiNj5C2s27Ggc8BVZcD5zS mDDZmdlV/UaRzhHKZJQn5w6eSgI6VHjwO5rTuNWUz/KvjrR43Gd9ugZtwzhpQ8O8XqWd bD8A== 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=ugUV7CfnncO++eWq6t6n+uWKh/GamHhgdFenJv4ItH4=; b=ez076qaLL5weI6nfYPnc42oUijN/YbSWNVdtg8GvoRheWeJhN2/tX9k8jnV8FPcCwA LbGAslp9Y7Z0WCPKouFkOsLiyncbTvWjGZeov9Z0TwLB9+vbsLxPzaR8fqOf0Rc6qJNv BpswWBZvve4dll+5KQNvBfKcgWYZvBfpjmDg0zLIGdvBVOriCGsoEVSPmaeUSKIaoAzU peM49ZSsHUfas4dUguhjBhsKzAd6zT6WWlcdlnP9MrSC5+OZ835ItvRH8ufClNtL+3Ax Tkx7dSmQdwNQ3JChSaSEwZqnMMBArWLxUcs2c66Ch6MJSTl7V7kWV6G1aFRiM7kIb1aO mCTw== X-Gm-Message-State: AOAM53277BsZZOR/f16LUj/Z8lrgisNtlrg+aPA4wSoD76c+of8w9qiU 7xLV/w8fwBce7jAi0kUdSLAWdHHAnQJN8+Z7CsA= X-Google-Smtp-Source: ABdhPJzLTcMPt9xmPVEOMEzL+z6CcHcU8CCnTKm62zwimsPKCusOLj0kdNDT2LFM/Lb+Sp4VIK4SvJewJzMamNcNCn0= X-Received: by 2002:aca:280c:: with SMTP id 12mr3389012oix.131.1593193002017; Fri, 26 Jun 2020 10:36:42 -0700 (PDT) MIME-Version: 1.0 References: <4F145676-A126-4D35-8890-A0DDF891EA06@mit.edu> <32ae1a93-fc9d-cd15-798e-ec493482dd26@free.fr> <90F181EE-8E34-4486-BCFB-ADACE55A55CF@mit.edu> <6CCD515B-BE87-452B-9034-777D90E110DD@mit.edu> <3b49cf41-883c-66d9-ac92-b34301161eca@free.fr> <4fab6b2b-c860-350e-476b-60372dd946c3@free.fr> <23c8d43b-9b79-f9b9-fdbf-aa2f096936a9@free.fr> In-Reply-To: <23c8d43b-9b79-f9b9-fdbf-aa2f096936a9@free.fr> From: Tom Jones Date: Fri, 26 Jun 2020 10:36:29 -0700 Message-ID: To: Denis Cc: Justin Richer , txauth@ietf.org, Tobias Looker Content-Type: multipart/alternative; boundary="000000000000f1a6da05a90026e9" Archived-At: Subject: Re: [Txauth] Use Case: Directed Tokens 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, 26 Jun 2020 17:36:56 -0000 --000000000000f1a6da05a90026e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable that sounds useful. Do you think it should be in scope of this effort? Peace ..tom On Fri, Jun 26, 2020 at 10:18 AM Denis wrote: > Hi Tom, > > In the model I have in mind, the ro may directly communicate with the rs > (or open a session with the rs) to tell what the rules are, > i.e. which attributes are needed for some kinds of operations and from > which as(s) these attributes may be obtained. > > The ro is not involved in anyway at the time a client attempts to perform > an operation. > > Denis > > no you should not assume that. But if your standard demands communication= s > between the ro & rs for every release of data, then i could not use the > standard. > Peace ..tom > > > On Fri, Jun 26, 2020 at 9:51 AM Denis wrote: > >> Tom, >> >> Should I understand that you are willing to rubber-stamp an existing >> implementation ? >> >> Since we are not yet a WG, it is not my understanding that it is what a >> WG should attempt to do. >> >> Denis >> >> You cannot assume that the rs is in communication with the user/resource >> owner during the other interchanges. That would not be the case in my >> implementation. >> >> thx ..Tom (mobile) >> >> On Fri, Jun 26, 2020, 9:04 AM Denis wrote: >> >>> Tom and Justin, >>> >>> Why do want to make things complicated when they are quite simple ? >>> >>> The statement saying "the as and rs most likely have an ongoing securit= y >>> context on which to build subsequent interchanges" >>> would have severe limitations in terms of scalability and privacy. >>> >>> The principle where a RS would only have relationships with one AS woul= d >>> make the model non scalable. >>> It would prevent to get attributes from two different ASs, for >>> example: >>> identity attributes from a bank and a master degree diploma from a >>> university. >>> >>> For privacy reasons, every AS should know as little as possible about >>> the interactions between a client and multiple RSs. >>> It is even possible that this goes as little as knowing *nothing at all= * >>> . >>> >>> The OAuth 2.0 assumption where the AS is in a position to know all the >>> interactions of a given user has with all the RSs >>> that an AS server has a relationship with should not be re-iterated. >>> >>> The relationships between RSs may change at any time and it woauld not >>> be reasonable to inform the ASs in real time >>> about these interactions. >>> >>> As already stated in an earlier email: >>> >>> No one (including ASs) is able to predict in advance which access token= s >>> will be needed, since they depend upon the kind of operation(s) >>> the client will be willing to perform. (...) >>> >>> To handle the complex case you envision, the full workflow of operation= s >>> needs to be considered with a detailed focus on the time >>> at which the user's *consent and choice* happens (*consent and choice* >>> is the first privacy principle from ISO 29100). >>> >>> A RS whether the first one of a RS chain and a subsequent one, taking >>> into consideration the kind of operation that will be requested by the >>> client, >>> should be is able to inform the user about which kind of attributes are >>> needed and from which AS(s) [note the plural], they may be obtained. >>> >>> Denis >>> >>> >>> While there are multiple reasons for bound tokens, each with their own >>> needs, I strongly encourage an effort to create a single broad spec tha= t >>> could address the common security issues. Tobias, this is the general i= dea >>> you were pushing on application level networking. As a general rule, I >>> believe that the current effort to base security on channel binding has >>> already been extended beyond its capabilities. (That is the concept tha= t >>> the HTTPS key is used as the security for the messages.) So, can't we f= ocus >>> on the problem of identifying the participants to an extended set of >>> interchanges. This would formalize the earlier statements that the as a= nd >>> rs most likely have an ongoing security context on which to build >>> subsequent interchanges. >>> Peace ..tom >>> >>> >>> On Fri, Jun 26, 2020 at 6:23 AM Justin Richer wrote: >>> >>>> On Jun 25, 2020, at 9:07 PM, Tobias Looker >>>> wrote: >>>> >>>> >>>> I find this feature interesting and think it could be an >>>> important pattern going forward to enable an AS to be able to describe= the >>>> utility of a token to the client, however as already pointed out in th= e >>>> thread I think there is some potential hidden complexity that would ne= ed to >>>> be ironed out such that it does not make the simple things complicated= . >>>> >>>> Justin, do you see this feature as something the client has to >>>> explicitly request, i.e "please give me access and instructions on how= to >>>> use my access" or rather that the AS would just return this informatio= n in >>>> conjunction with the access token if it had it available? >>>> >>>> >>>> This is something that I=E2=80=99d brought up as a possibility on the = previous >>>> thread =E2=80=94 something like a flag the client would set. This woul= d be >>>> especially important if the AS wants to return multiple access tokens = but >>>> the client requested 1, or the client requested N and the AS wants to >>>> return M in response. Basically any time there=E2=80=99s a mismatch, t= hat=E2=80=99s extra >>>> complexity on the client that I really don=E2=80=99t think we want to = be universal. >>>> A flag to turn that kind of direction and splitting on would be a pote= ntial >>>> start. But there are potential snags here too, and it comes down to ho= w you >>>> manage the defaults... >>>> >>>> > This is just the start, too. Things get even more complex if the >>>> client can ask for multiple different kinds of resources at once. What= if >>>> the AS decides that the client needs a hyper-focused directed token fo= r one >>>> part of the API, but can use a general token for other stuff? Can it s= ignal >>>> that to the client? And if it can, does that mean that all clients nee= d to >>>> be prepared for that kind of thing? >>>> >>>> Would a potential default be that if a client did for any reason not >>>> support processing the additional information returned with the >>>> access_token, just to ignore it? I think in the spirit of keeping the >>>> simple things simple, this potentially makes sense? >>>> >>>> >>>> That=E2=80=99s the real trick, if you ask me. It has to be :safe: for = a client >>>> to ignore this information. Which means the AS can=E2=80=99t rely on t= he client >>>> =E2=80=9Cdoing the right thing=E2=80=9D with the information in the = =E2=80=9Ctoken directions=E2=80=9D >>>> portion of the response. Even setting aside the advanced and related = =E2=80=9Csplit >>>> tokens=E2=80=9D idea above, we need to make sure that an AS/RS setup i= s built such >>>> that if the AS tells a client =E2=80=9Conly do X with your token=E2=80= =9D and the client >>>> does =E2=80=9CY=E2=80=9D, then there are other protections and practic= es in place to >>>> prevent things from going haywire if the client does =E2=80=9CY=E2=80= =9D either by accident >>>> or through ignorance. >>>> >>>> If OAuth 2 has taught us anything, it=E2=80=99s that client applicatio= ns are >>>> going to be the laziest participants in the security model. And that m= akes >>>> sense, really =E2=80=94 security isn=E2=80=99t what the client apps ar= e trying to do, >>>> they=E2=80=99re trying to use the RS to do something. So we need to ma= ke sure that >>>> whatever system we design will fail on the safe side as much as possib= le, >>>> and keep things simple for the client. >>>> >>>> >>>> > here are some worked out samples of this: >>>> https://wiki.idesg.org/wiki/index.php/High_Assurance_AZ_Token >>>> https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ >>>> Peace ..tom >>>> >>>> As one of the authors of those mentioned drafts, I am interested in >>>> discussing that, but perhaps on a seperate thread? As at least the bou= nd >>>> assertion spec is primarily concerned with binding mechanisms for the >>>> artifacts produced from an authorization flow (specifically identity >>>> claims), whereas I think directed access tokens is just more generally >>>> talking about whether GNAP should support an AS conveying how to use a= n >>>> access_token it produces during a flow with a client. >>>> >>>> >>>> I think that these are separate issues as well. >>>> >>>> =E2=80=94 Justin >>>> >>>> Thanks, >>>> [image: Mattr website] >>>> *Tobias Looker* >>>> Mattr >>>> +64 (0) 27 378 0461 >>>> tobias.looker@mattr.global >>>> [image: Mattr website] [image: Mattr on >>>> LinkedIn] [image: Mattr >>>> on Twitter] [image: Mattr on Github] >>>> >>>> This communication, including any attachments, is confidential. If you >>>> are not the intended recipient, you should not read it - please contac= t me >>>> immediately, destroy it, and do not copy or use any part of this >>>> communication or disclose anything about it. Thank you. Please note th= at >>>> this communication does not designate an information system for the >>>> purposes of the Electronic Transactions Act 2002. >>>> >>>> >>>> On Wed, Jun 24, 2020 at 10:14 PM Denis wrote: >>>> >>>>> Justin, I fear we are still far away from an agreement about what thi= s >>>>> BoF should do. >>>>> >>>>> Tom Jones is saying " I am getting tired of the whack-a-mole approach >>>>> ..." >>>>> >>>>> I don't agree with you when you write: "I think it=E2=80=99s going to= be >>>>> overwhelmingly common that a given RS is going to trust exactly one A= S >>>>> that it knows about ahead of time". Such an architecture would have >>>>> exactly the same limitations as OAuth 2.0. and would not be scalable. >>>>> >>>>> Before we start, we should have a clear view of the whole picture >>>>> rather than starting from one scenario and expanding it in many diffe= rent >>>>> directions. >>>>> For building an architecture, a pre-requirement is to define ALL the >>>>> trust relationships. I don't believe that we have an agreement at thi= s time >>>>> on what >>>>> these trust relationships are. >>>>> >>>>> You are also using the following wording: "methods for the AS and RS >>>>> to communicate what the token=E2=80=99s good for". >>>>> With such a paradigm, it would be impossible to protect the user's >>>>> privacy. >>>>> >>>>> A key question is : Will GNAP take care of the user's privacy or will >>>>> GNAP *prevent *to take care of the user's privacy ? >>>>> >>>>> About "the ability for the client to get several access tokens to get >>>>> different resources from one request" is indeed a complex case. >>>>> >>>>> No one (including ASs) is able to predict in advance which access >>>>> tokens will be needed, since they depend upon the kind of operation(s= ) >>>>> the client will be willing to perform. For privacy reasons, ASs shoul= d >>>>> be kept ignorant of all the operations that a client is going to perf= orm >>>>> on one or more resource servers. I believe that every effort should b= e >>>>> made to avoid the AS to be in a position to be able to trace the oper= ations >>>>> performed by its clients on various RSs. >>>>> >>>>> To handle the complex case you envision, the full workflow of >>>>> operations needs to be considered with a detailed focus on the time >>>>> at which the user's *consent and choice* happens (*consent and choice= * >>>>> is the first privacy principle from ISO 29100). >>>>> >>>>> First of all, an access token could be targeted to a service rather >>>>> than to a server. This would already solve many cases. >>>>> >>>>> When a RS needs to call another RS (which does not support the same >>>>> service) then the client should be informed by the first RS. >>>>> His "consent and choice" should then be obtained by the first RS and, >>>>> when the user agrees, the client should then ask an access token >>>>> to one of the ASs trusted by the second RS in order to perform the >>>>> subsequent operation. >>>>> >>>>> Denis >>>>> >>>>> PS. In an email sent on June 23 you wrote: " I think an on-device AS >>>>> is an important use case". I am sorry, but I don't understand. >>>>> However, I do understand what "a server-based AS" is. >>>>> >>>>> >>>>> Denis, thanks for the great comments. I think that your trust model i= s >>>>> pretty different from what I=E2=80=99d laid out initially, and while = it=E2=80=99s an >>>>> interesting and important one, it is not what I meant by =E2=80=9Cmul= tiple access >>>>> tokens=E2=80=9D in my discussion below. I think that might be the cau= se of some >>>>> disconnect here, but that doesn=E2=80=99t mean it=E2=80=99s out of re= ach for what the WG is >>>>> after. >>>>> >>>>> When I refer to multiple access tokens, and what the charter calls ou= t >>>>> as multiple access tokens, is the ability for the client to get sever= al >>>>> access tokens to get different resources from one request. I personal= ly see >>>>> this as an optimization of a specific set of use cases, some of which= I >>>>> discussed in my original email. There are others, I=E2=80=99m sure, b= ut all the >>>>> ones I=E2=80=99ve seen are around the client needing to get several d= ifferent kinds >>>>> of access through an AS. >>>>> >>>>> I think it=E2=80=99s going to be overwhelmingly common that a given R= S is >>>>> going to trust exactly one AS that it knows about ahead of time. But = for >>>>> RS=E2=80=99s that can trust multiple AS=E2=80=99s, then we should hav= e a model that can >>>>> accommodate that as well. That=E2=80=99s why the charter calls out me= thods for the >>>>> AS and RS to communicate what the token=E2=80=99s good for. I think t= he basis of >>>>> those methods is going to start with a common token model, and likely >>>>> incorporate into things like token formats and introspection-style to= ken >>>>> APIs. >>>>> >>>>> =E2=80=94 Justin >>>>> >>>>> On Jun 22, 2020, at 3:55 AM, Denis wrote: >>>>> >>>>> Hello Justin, >>>>> >>>>> A few comments between the lines. >>>>> >>>>> One of the most important aspects to GNAP is going to be an ability t= o >>>>> address things that OAuth 2 can=E2=80=99t, or at least can=E2=80=99t = do without significant >>>>> gymnastics. So with that, I wanted to bring back a use case discussio= n that >>>>> originally came up while we were talking about the possibility of mul= tiple >>>>> access tokens, a few months back. I don=E2=80=99t know if this concep= t has a >>>>> regular term, so I=E2=80=99m going to call it =E2=80=9Cdirected acces= s tokens=E2=80=9D until we >>>>> come up with something better =E2=80=94 assuming we decide this is wo= rthwhile. >>>>> >>>>> >>>>> I don't understand what may mean "directed access tokens=E2=80=9D but= I >>>>> understand what means "multiple access tokens". >>>>> When speaking of "multiple access tokens", these access tokens may >>>>> come from one or more ASs. >>>>> >>>>> In OAuth, the client=E2=80=99s supposed to always know where to send = its >>>>> access token, and that knowledge is completely outside the protocol. = This >>>>> makes a lot of sense for many (if not most) deployments, as OAuth is = really >>>>> there to enable the API access that the client already knows about. >>>>> >>>>> But we=E2=80=99re now in a world where a client could be talking to a= generic >>>>> API that could be deployed at a number of different places, or a clou= d >>>>> deployment that the AS wants to be able to dispatch the client to. >>>>> >>>>> As soon the AS is placed (again) at the centre of the model, the AS >>>>> will have the ability to act as "Big Brother". >>>>> OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP >>>>> should take care of them. >>>>> >>>>> In order to do this, the AS needs to be able to communicate to the >>>>> client not only the token information (and any related key and presen= tation >>>>> information), but also a set of *directions* about what that specific >>>>> token is good for. This needs to be information outside the token its= elf, >>>>> since I believe we want to keep OAuth 2=E2=80=99s feature of having t= he token be >>>>> opaque to the client. Note: while we could map all of these to differ= ent >>>>> resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parl= ance) >>>>> on the request side, this isn=E2=80=99t enough to tell the client wha= t to do with >>>>> the token *if it doesn=E2=80=99t know already*. >>>>> >>>>> I know of two use cases already in the wild, where people are >>>>> addressing things using a mix of existing standards and some propriet= ary >>>>> extensions to address things within their silos. I=E2=80=99ll try to = summarize >>>>> here, but I know the folks I=E2=80=99ve been talking to about this ar= e also on the >>>>> list so hopefully they can chime in with more detail or any correctio= ns for >>>>> something I=E2=80=99ve missed. >>>>> >>>>> (1) The client knows what resource it=E2=80=99s calling, but it doesn= =E2=80=99t know >>>>> where it=E2=80=99s hosted. Everything is in a single security domain = controlled by >>>>> the AS, >>>>> >>>>> Speaking of "multiple access tokens" is in contradiction with single >>>>> security domain "controlled" by an AS. >>>>> A user may need to demonstrate some of his identity attributes grante= d >>>>> e.g. by his bank but may also >>>>> need to demonstrate one or more diplomas granted by one or more >>>>> universities. The bank cannot be >>>>> the "primary issuer" of a university diploma. It should not be either >>>>> a "secondary issuer", because >>>>> the bank does not "*need to know"* what are the diplomas of the user. >>>>> >>>>> but the AS needs to decide at runtime which specific instance of the >>>>> API to direct the client to. Since things are closely tied together, = the >>>>> client just needs to effectively known an identifier for the RS, and = this >>>>> is currently implemented as a URI. Once the client has that identifie= r, it >>>>> knows how to dispatch that token to that instance of the RS. >>>>> >>>>> There is no good reason why the AS should be involved in that step. >>>>> OAuth 2.0 is/was implicitly mandating a strong relationship between >>>>> ASs and RSs which makes it non scalable. >>>>> GNAP should be based on a simple trust relationship : a given RS >>>>> trusts some ASs for access tokens that contains some types of attribu= tes. >>>>> An AS should not need to know in advance (or even at the time of an >>>>> access token request) the RSs that are trusting it. >>>>> >>>>> A client could first talk to a "global service provider" which has th= e >>>>> knowledge of the different RSs affiliated to it. >>>>> >>>>> (2) The client knows what kind of thing it=E2=80=99s looking for, but= doesn=E2=80=99t >>>>> know who to ask it from. >>>>> >>>>> Once again, the client could first talk to a "global service provider= " >>>>> which has the knowledge of the different RSs affiliated to it. >>>>> >>>>> There=E2=80=99s a cross-domain trust that=E2=80=99s bridged by the AS= , and the AS >>>>> needs to dispatch to different resources depending on which user logg= ed in >>>>> (and possibly what the user consented to). To make things more concre= te, >>>>> the client needs to get driver=E2=80=99s license information, but doe= sn=E2=80=99t know >>>>> ahead of time which of the many state/provincial bureaus to call to g= et >>>>> that information because it doesn=E2=80=99t know yet who the user is. >>>>> >>>>> When a user has a driving license, he knows its issuer. The user can >>>>> then provide some hint to the client. >>>>> >>>>> The AS will know who the user is once they log in and approve things, >>>>> and so it can direct the client to call the correct RS. Since this is= a >>>>> relatively simple API with a pre-negotiated cross-domain trust, the A= S >>>>> returns a URL that the client presents the token at. >>>>> >>>>> A single AS should not be aware of all the attributes a user has. >>>>> >>>>> >>>>> As far as I know, in both of these cases, the token is only good for >>>>> that API and not others =E2=80=94 but more on that later. >>>>> >>>>> A simple thing to do is just give back a URL with the access token, >>>>> which tells the client where to go. >>>>> >>>>> { >>>>> =E2=80=9Caccess_token=E2=80=9D: { >>>>> =E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yfer=E2=80=9D, >>>>> =E2=80=9Cresource_uri=E2=80=9D: =E2=80=9Chttps://example/foo" >>>>> } >>>>> } >>>>> >>>>> This is good for some kinds of APIs, but it=E2=80=99s limiting becaus= e not all >>>>> APIs dispatch based on the URL. An AS might want to divvy up access t= okens >>>>> to an API that=E2=80=99s keyed on headers, or verbs, or any number of= things. And >>>>> it doesn=E2=80=99t tell us immediately what to do about non-exact URL= matches. Can >>>>> the client add query parameters and still use the token? What about p= ath >>>>> segments? I like that this simple approach addresses some common >>>>> deployments that we already see today (see above), it=E2=80=99s not u= niversal. Do >>>>> we want or need a universal description language for directing where = tokens >>>>> go? >>>>> >>>>> This also opens up a whole new set of security questions. If the AS >>>>> can now direct the client where to use the token, could a rogue AS co= nvince >>>>> a legit client to use a stolen token at the wrong RS? And what if the >>>>> client ignores the directions from the AS entirely? Could this open u= p new >>>>> avenues of attack? >>>>> >>>>> This is just the start, too. Things get even more complex if the >>>>> client can ask for multiple different kinds of resources at once. Wha= t if >>>>> the AS decides that the client needs a hyper-focused directed token f= or one >>>>> part of the API, but can use a general token for other stuff? Can it = signal >>>>> that to the client? And if it can, does that mean that all clients ne= ed to >>>>> be prepared for that kind of thing? >>>>> >>>>> I firmly believe that whatever we build in GNAP, we need to optimize >>>>> for the overwhelmingly common use case of a client getting a single a= ccess >>>>> token to call APIs that it already knows about. Anything we add on to= p of >>>>> that really can=E2=80=99t get in the way of this, because if it does,= there=E2=80=99s very >>>>> small chance that people will try to use this for everyday things. Ke= ep the >>>>> simple things simple, and the complex things possible, after all. >>>>> >>>>> I=E2=80=99m really looking forward to hearing what the community thin= ks about >>>>> these use cases, and hopefully the people I=E2=80=99ve chatted with o= ffline about >>>>> this can join the conversation and provide more light than I was able= to. >>>>> >>>>> The two use cases which are considered above are: >>>>> >>>>> (1) The client knows what resource it=E2=80=99s calling, but it doesn= =E2=80=99t know >>>>> where it=E2=80=99s hosted. >>>>> (2) The client knows what kind of thing it=E2=80=99s looking for, but= doesn=E2=80=99t >>>>> know who to ask it from. >>>>> >>>>> That does not mean in any way that these two use cases should be >>>>> solved by placing the AS at the centre of the solution. >>>>> >>>>> Denis >>>>> >>>>> >>>>> =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 >>>>> >>>> >>>> This communication, including any attachments, is confidential. If you= are not the intended recipient, you should not read it - please contact me= immediately, destroy it, and do not copy or use any part of this communica= tion or disclose anything about it. Thank you. Please note that this commun= ication does not designate an information system for the purposes of the El= ectronic Transactions Act 2002. >>>> >>>> >>>> -- >>>> 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 >>> >> >> > --000000000000f1a6da05a90026e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
that sounds useful. Do you think it should be in scope of = this effort?
Peace ..tom


On Fri, Jun 26, 2020 at 10:18 AM Denis <denis.ietf@free.fr> 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"> =20 =20 =20
Hi Tom,

In the model I have in mind, the ro may directly communicate with the rs (or open a session with the rs) to tell what the rules are,
i.e. which attributes are needed for some kinds of operations and from which as(s) these attributes may be obtained.

The ro is not involved in anyway at the time a client attempts to perform an operation.

Denis

=20
no you should not assume that. But if your standard demands communications between the ro & rs for every release of data, then i could not use the standard.
Peace ..tom


On Fri, Jun 26, 2020 at 9:51 AM Denis <denis.ietf@free.fr> wrote:
Tom,

Should I understand that you are willing to rubber-stamp an existing implementation ?

Since we are not yet a WG, it is not my understanding that it is what a WG should attempt to do.

Denis

You cannot assume that the rs is in communication with the user/resource owner during the other interchanges. That would not be the case in my implementation.

thx ..Tom (mobile)

On Fri, Jun 26, 2020, 9:04 AM Denis <denis.ietf@free.fr> wrote:
Tom and Justin,

Why do want to make things complicated when they are quite simple ?

The statement saying "the as and rs most like= ly have an ongoing=C2=A0security context on which to bui= ld subsequent interchanges"
would have severe limitations in terms of scalability and privacy.

The principle where a RS would only have relationships with one AS would make the model non scalable.
It would prevent to get attributes from two different ASs,=C2=A0 for example:=C2=A0
identity attributes from a bank and a master degree diploma from a university.

For privacy reasons, every AS should know as little as possible about the interactions between a client and multiple RSs.
It is even possible that this goes as little as knowing nothing at all.

The OAuth 2.0 assumption where the AS is in a position to know all the interactions of a given user has with all the RSs
that an AS server has a relationship with should not be re-iterated.

The relationships between RSs may change at any time and it woauld not be reasonable to inform the ASs in real time
about these interactions.

As already stated in an earlier email:
No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. (...)

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consent and choice happens (consent and choice is the first privacy principle from ISO 29100).
A RS whether the first one of a RS chain and a subsequent one, taking into consideration the kind of operation that will be requested by the client, should be is able to inform the user about which kind of attributes are needed and from which AS(s) [note the plural], they may be obtained.

Denis


While there are multiple reasons for bound tokens, each with their own needs, I strongly encourage an effort to create a single broad spec that could address the common security issues. Tobias, this is the general idea you were pushing on application level networking. As a general rule, I believe=C2=A0that the current effort to base security on channel binding has already been extended beyond=C2=A0its capabilities. (That is the concept that the HTTPS key is used as the security for the messages.) So, can't we focus on the problem of identifying the participants to an extended set of interchanges. This would formalize the earlier statements that the as and rs most likely have an ongoing=C2=A0security context on whi= ch to build subsequent interchanges.
Peace ..tom


On Fri, Jun 26, 2020 at 6:23 AM Justin Richer <jricher@mit.ed= u> wrote:
On Jun 25, 2020, at 9:07 PM, Tobias Looker <tobias.looker@mattr.global> wrote:

I find this feature interesting and think it could be an important=C2=A0pattern going=C2=A0forwa= rd to enable an AS to be able to describe the utility of a token to the client, however as already pointed out in the thread I think there is some potential hidden complexity that would need to be ironed out such that it does not make the simple things complicated.

Justin, do you see this feature as something the client has to explicitly request, i.e "please give me access and instructions on how to use my access" or rather that the AS would just return this information in conjunction with the access token if it had it available?


This is something that I=E2=80=99d broug= ht up as a possibility on the previous thread =E2=80=94 something like a flag the client = would set. This would be especially important if the AS wants to return multiple access tokens but the client requested 1, or the client requested N and the AS wants to return M in response. Basically any time there=E2=80=99s a mismatch, that= =E2=80=99s extra complexity on the client that I really don=E2=80=99t think we want to be universal. A flag to turn that kind of direction and splitting on would be a potential start. But there are potential snags here too, and it comes down to how you manage the defaults...

> This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

Would a potential default be that if a client did for any reason not support processing the additional information returned with the access_token, just to ignore it? I think in the spirit of keeping the simple things simple, this potentially makes sense?

That=E2=80=99s the real trick, if you as= k me. It has to be :safe: for a client to ignore this information. Which means the AS can=E2=80=99t rely on the client =E2=80= =9Cdoing the right thing=E2=80=9D with the information i= n the =E2=80=9Ctoken directions=E2=80=9D portion = of the response. Even setting aside the advanced and related =E2=80=9Csplit tokens= =E2=80=9D idea above, we need to make sure that an AS/RS setup is built such that if the AS tells a client =E2=80=9Conly do X with your token=E2=80=9D and the client does =E2=80= =9CY=E2=80=9D, then there are other protections and practices in place to prevent things from going haywire if the client does =E2=80=9CY=E2=80=9D either by accident or t= hrough ignorance.=C2=A0

If OAuth 2 has taught us anything, it=E2=80=99s that client applications are g= oing to be the laziest participants in the security model. And that makes sense, really =E2=80=94 security isn=E2=80=99t wha= t the client apps are trying to do, they=E2=80=99re tryi= ng to use the RS to do something. So we need to make sure that whatever system we design will fail on the safe side as much as possible, and keep things simple for the client.


> here are some worked out samples of this:
https://mattrglobal.github.io/oidc-client-bound-assertions-spec/
Peace ..tom

As one of the authors of those mentioned drafts, I am interested in discussing that, but perhaps on a seperate thread? As at least=C2=A0the bound assertion spec is=C2=A0primarily=C2=A0con= cerned with binding mechanisms for the artifacts produced from an authorization flow (specifically identity claims), whereas I think directed access tokens is just more generally talking about whether GNAP should support an AS conveying how to use an access_token it produces during a flow with a client.


I think that these are separate issues as well.

=C2=A0=E2=80=94 Justin

Thanks,
3D"Mattr =C2=A0
Tobias Looker
Mattr
+64 (0) 27 378 0461
tobias.looker@mattr.global
= 3D"Mattr = 3D"Mat= = 3D"Mattr = 3D"Mattr

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.


O= n Wed, Jun 24, 2020 at 10:14 PM Denis <denis.ietf@free.fr> wrote:
Justin, I fear we are still far away from an agreement about what this BoF should do.

Tom Jones is saying " I a= m getting tired of the whack-a-mole approach ..."

I don't agree with you when you write: "I think it=E2=80=99s g= oing to be overwhelmingly common that a given RS is going to trust exactly one AS
that it knows about ahead of time". Such an architectu= re would have exactly the same limitations as OAuth 2.0. and would not be scalable.

Before we start, we should have a clear view of the whole picture rather than starting from one scenario and expanding it in many different directions.
For building an architecture, a pre-requirement is to define ALL the trust relationships. I don't believe that we hav= e an agreement at this time on what
these trust relationships are.

You are also using the following wording: "methods for the AS and RS to communicate what the token=E2=80= =99s good for".
With such a paradigm, it would be impossible to protect the user's privacy.

A key question is : Will GNAP take care of the user's privacy or will GNAP prevent to take care of the user'= s privacy ?

About "the ability for th= e client to get several access tokens to get different resources from one request" = is indeed a complex case.

No one (including ASs) is able to predict in advance which access tokens will be needed, since they depend upon the kind of operation(s)
the client will be willing to perform. For privacy reasons, ASs should be kept ignorant of all the operations that a client is going to perform
on one or more resource servers. I believe that every effort should be made to avoid the AS to be in a position to be able to trace the operations
performed by its clients on various RSs.

To handle the complex case you envision, the full workflow of operations needs to be considered with a detailed focus on the time
at which the user's consen= t and choice happens (cons= ent and choice is the first privacy principle from ISO 29100).

First of all, an access token could be targeted to a service rather than to a server. This would already solve many cases.

When a RS needs to call another RS (which does not support the same service) then the client should be informed by the first RS.
His "consent and choice&q= uot; should then be obtained by the first RS and, when the user agrees, the client should then ask an access token
to one of the ASs trusted by the second RS in order to perform the subsequent operation.=C2=A0

Denis

PS.=C2=A0 In an email sent on June 23 you wrote: " I think an on-device AS is an important use case".=C2=A0 I= am sorry, but I don't understand= .
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 However, I do understand what "a server-based AS" is.


Denis, thanks for the great comments. I think that your trust model is pretty different from what I=E2=80=99d laid out initially, a= nd while it=E2=80=99s an interesting= and important one, it is not what I meant by =E2=80=9Cmultiple acce= ss tokens=E2=80=9D in my discussion below. I think that might be the cause of some disconnect here, but that doesn=E2=80=99t me= an it=E2=80=99s out of reach for wha= t the WG is after.

When I refer to multiple access tokens, and what the charter calls out as multiple access tokens, is the ability for the client to get several access tokens to get different resources from one request. I personally see this as an optimization of a specific set of use cases, some of which I discussed in my original email. There are others, I=E2=80=99m sure, but a= ll the ones I=E2=80=99ve seen are around the client needing to get several different kinds of access through an AS.=C2=A0<= br>

I think it=E2=80=99s going= to be overwhelmingly common that a given RS is going to trust exactly one AS that it knows about ahead of time. But for RS=E2=80=99s= that can trust multiple AS=E2=80= =99s, then we should have a model that can accommodate that as well. That=E2=80=99s = why the charter calls out methods for the AS and RS to communicate what the token=E2=80=99s good for. I t= hink the basis of those methods is going to start with a common token model, and likely incorporate into things like token formats and introspection-style token APIs.=C2=A0

=C2=A0=E2=80=94 Justin

On Jun 22, 2020, at 3:55 AM, Denis <denis.ietf@free.fr<= /a>> wrote:

He= llo Justin,
A few comments between the lines.
One of the most important aspects to GNAP is going to be an ability to address things that OAuth 2 can=E2=80=99t, or at = least can=E2=80=99t do with= out significant gymnastics. So with that, I wanted to bring back a use case discussion that originally came up while we were talking about the possibility of multiple access tokens, a few months back. I don=E2=80=99t know if= this concept has a regular term, so I=E2=80=99m going to = call it =E2=80=9Cdirected access tokens=E2=80= =9D until we come up with something better =E2=80=94 assu= ming we decide this is worthwhile.=C2= =A0

I don't understand what may mean "directed access tokens=E2=80=9D but I understand what means "multiple access tokens".<= span>=C2=A0
When speaking of "multiple access tokens", these access tokens may come from one or more ASs.

In OAuth, the client=E2=80=99s supposed to always know where to send its access token, and that knowledge is completely outside the protocol. This makes a lot of sense for many (if not most) deployments, as OAuth is really there to enable the API access that the client already knows about.

But we=E2=80=99r= e now in a world where a client could be talking to a generic API that could be deployed at a number of different places, or a cloud deployment that the AS wants to be able to dispatch the client to.=C2= =A0

As soon the AS is placed (again) at the centre of the model, the AS will have the ability to act as "Big Brother".
OAuth 2.0 has not taken care of privacy issues. On the contrary, GNAP should take care of them.

In order to do this, the AS needs to be able to communicate to the client not only the token information (and any related key and presentation information), but also a set of=C2=A0directions=C2=A0about what that specific token is good for. This needs to be information outside the token itself, since I=C2=A0believ= e we want to keep OAuth 2=E2=80=99s feature of having the token be opaque to the client. Note: while we could map all of these to different resource requests (in XYZ parlance) or scopes (in OAuth 2 legacy parlance) on the request side, this isn=E2=80=99t enough to tell the client what to do with the token=C2=A0if it doesn=E2=80=99= t know already.= =C2=A0

I know of two use cases already in the wild, where people are addressing things using a mix of existing standards and some proprietary extensions to address things within their silos. I=E2=80=99ll= try to summarize here, but I know the folks I=E2=80= =99ve been talking to about this are also on the list so hopefully they can chime in with more detail or any corrections for something I=E2=80= =99ve missed.=C2=A0

(1) The client knows what resource it=E2=80=99s callin= g, but it doesn=E2=80= =99t know where it=E2=80= =99s hosted. Everything is in a single security domain controlled by the AS,=C2=A0=

Spea= king of "multiple access tokens" i= s in contradiction with single security domain "controlled"= ; by an AS.=C2=A0
A user may need to demonstrate some of his identity attributes granted e.g. by his bank but may also=C2= =A0
need to demonstrate one or more diplomas granted by one or more universities. The bank cannot be=C2=A0
the "primary issuer" of a university diploma. It should not be either a "secondary issuer", because= =C2=A0
the bank does not "need to know= "=C2=A0what are the diplomas of the user.

but the AS needs to decide at runtime which specific instance of the API to direct the client to. Since things are closely tied together, the client just needs to effectively known an identifier for the RS, and this is currently implemented as a URI. Once the client has that identifier, it knows how to dispatch that token to that instance of the RS.

Ther= e is no good reason why the AS should be involved in that step.=C2= =A0
OAuth 2.0 is/was implicitly mandating a strong relationship between ASs and RSs which makes it non scalable.
GNAP should be based on a simple trust relationship : a given RS trusts some ASs for access tokens that contains some types of attributes.
An AS should not need to know in advance (or even at the time of an access token request) the RSs that are trusting it.

A client could first talk to a "globa= l service provider"= ; which has the knowledge of the different RSs affiliated to it.=C2=A0

(2) The client knows what kind of thing it=E2=80=99s looking for, but doesn=E2=80=99t kno= w who to ask it from.=C2=A0

Once again, the client could first talk to a "global service provider"= ; which has the knowledge of the different RSs affiliated to it.=C2=A0

There=E2=80=99s = a cross-domain trust that=E2=80=99= s bridged by the AS, and the AS needs to dispatch to different resources depending on which user logged in (and possibly what the user consented to). To make things more concrete, the client needs to get driver=E2=80= =99s license information, but doesn=E2=80=99t kno= w ahead of time which of the many state/provincial bureaus to call to get that information because it doesn=E2=80=99t kno= w yet who the user is.=C2=A0

When a user has a driving license, he knows its issuer. The user can then provide some hint to the client.

The AS will know who the user is once they log in and approve things, and so it can direct the client to call the correct RS. Since this is a relatively simple API with a pre-negotiated cross-domain trust, the AS returns a URL that the client presents the token at.=C2= =A0

=C2= =A0A single AS should not be aware of all the attributes a user has.=C2= =A0


As far as I know, in both of these cases, the token is only good for that API and not others =E2=80=94 bu= t more on that later.

A simple thing to do is just give back a URL with the access token, which tells the client where to go.=C2=A0

{
=E2=80=9Caccess_token=E2=80=9D: {
=E2=80=9Cvalue=E2=80=9D: =E2=80=9C87yui843yf= er=E2=80=9D,
}
}

This is good for some kinds of APIs, but it=E2=80=99s limiti= ng because not all APIs dispatch based on the URL. An AS might want to divvy up access tokens to an API that=E2=80= =99s keyed on headers, or verbs, or any number of things. And it doesn=E2=80=99t tel= l us immediately what to do about non-exact URL matches. Can the client add query parameters and still use the token? What about path segments? I like that this simple approach addresses some common deployments that we already see today (see above), it=E2=80=99= s not universal. Do we want or need a universal description language for directing where tokens go?

This also opens up a whole new set of security questions. If the AS can now direct the client where to use the token, could a rogue AS convince a legit client to use a stolen token at the wrong RS? And what if the client ignores the directions from the AS entirely? Could this open up new avenues of attack?

This is just the start, too. Things get even more complex if the client can ask for multiple different kinds of resources at once. What if the AS decides that the client needs a hyper-focused directed token for one part of the API, but can use a general token for other stuff? Can it signal that to the client? And if it can, does that mean that all clients need to be prepared for that kind of thing?

I firmly believe that whatever we build in GNAP, we need to optimize for the overwhelmingly common use case of a client getting a single access token to call APIs that it already knows about. Anything we add on top of that really can=E2=80=99t get i= n the way of this, because if it does, there=E2=80= =99s very small chance that people will try to use this for everyday things. Keep the simple things simple, and the complex things possible, after all.

I=E2=80=99m real= ly looking forward to hearing what the community thinks about these use cases, and hopefully the people I=E2=80= =99ve chatted with offline about this can join the conversation and provide more light than I was able to.

The two use cases which are considered above are:

(1) The client knows what resource it=E2=80= =99s calling, but it doesn=E2=80=99t kno= w where it=E2=80=99s hosted.
(2) The client knows what kind of thing it=E2=80= =99s looking for, but doesn=E2=80=99t kno= w who to ask it from.=C2=A0

That does not mean in any way that these two use cases should be solved by placing the AS at the centre of the solution.

Deni= s


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


--=C2=A0
Txauth mailing list Txauth@ietf.org
https://w= ww.ietf.org/mailman/listinfo/txauth


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

Th=
is communication, including any attachments, is confidential. If you are no=
t the intended recipient, you should not read it - please contact me immedi=
ately, destroy it, and do not copy or use any part of this communication or=
 disclose anything about it. Thank you. Please note that this communication=
 does not designate an information system for the purposes of the Electroni=
c Transactions Act 2002.

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


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



--000000000000f1a6da05a90026e9-- From nobody Fri Jun 26 10:40:38 2020 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 3DC3D3A0BA8; Fri, 26 Jun 2020 10:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 g82L9JwRjq_P; Fri, 26 Jun 2020 10:40:35 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416543A0A40; Fri, 26 Jun 2020 10:40:35 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id b25so7593102ljp.6; Fri, 26 Jun 2020 10:40:35 -0700 (PDT) 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=p9lmV2Tucg5GAGVmtgA/+7UiROpSNXK+2qmmYwD2CuI=; b=nW7tmXSSBeMzpy4klXT+0i+kGk9a4UNlKmve8tlOESeTbT6Qu2I+e3WSpf8WjUBuz1 GrAmHGz4j3wFEmbqS73O9BPjOh9hyKoP1hh10durNwrAFnnsKRQrcvnbLWoExr5e22kz PqA8qxoa6Ukr3R/oCOnqIuNAYBp62AM0imZseZyxMfbkyXRe1fDOJ0eXrh4oMdmGbiJB lEI4jbsqMwuJd2ZQtXg2ZjZlXwj/PWR+TTfTPMF2VLI1TfZJeuMyzP9+P9iNQ8R4GjEg 5zKFI5cQxrYXf1rHeKBkdHRGF+P9awjLGgFlA4t/r3r6c5wLyI7Fca3dmxbRTn2TfW4c vZUA== 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=p9lmV2Tucg5GAGVmtgA/+7UiROpSNXK+2qmmYwD2CuI=; b=oCgAtYYbX2WgspORWW7q5QVUGNzL4JI2MaXjbPDhDBh46nIpeLA/n8YAAXhQY4MCsW zYB4ePaVxuLgluk4Haw5qZ5vpgkbBnj2G2XauCfQ8ym0hlMPwn2BUB538bvMR8svsX0A UT81Xg/de/+getAfmFQwWlA5VNmJb2dK2VJEXaRcJekTQd3KUn9PR2+5zntln6EVdg6Y F3xlDE3fT1pjugVE/SPoOHlxopXt5Nns9V6brtYoMQsMNEHHkhBIMW5lsNqdhYXk0aOc HXl5QkRGP+YY+U9ARaAjnxY8sNStjEBTZLf8XY6Kt39sn4foIuMi4XvqjdLoe5Vetpwk ldJQ== X-Gm-Message-State: AOAM533jH1ms5xfkfU8m/Yv1IAAudyzZ+r/x+Hvj6uBzBK9a0xf0X1nI 6a7ll43pHGcN3Z1KkETP72BGEYoWPls34iYa96A= X-Google-Smtp-Source: ABdhPJwz7witqgDdpe8h3I0L9hCbuOkA6sOk7sPxeSglbjV4jQ1U3Q/HLdsF4cJs5V93JrnUIiB95SDlVZ7kFAqcQP0= X-Received: by 2002:a2e:7f10:: with SMTP id a16mr2071743ljd.69.1593193233286; Fri, 26 Jun 2020 10:40:33 -0700 (PDT) MIME-Version: 1.0 References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> In-Reply-To: From: Dick Hardt Date: Fri, 26 Jun 2020 10:39:57 -0700 Message-ID: To: Denis Cc: iesg@ietf.org, txauth@ietf.org Content-Type: multipart/alternative; boundary="000000000000ba898805a90034d8" Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 26 Jun 2020 17:40:37 -0000 --000000000000ba898805a90034d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Denis, thanks for sharing your thoughts, some clarifications on your statements inserted: On Fri, Jun 26, 2020 at 9:42 AM Denis wrote: > *New proposed charter* > > > > Resource servers inform their clients about which access token formats ar= e > acceptable and depending upon the king of operation > that is requested, which kind of attributes are needed and from which ASs > that my be obtained. > > While at times this may be appropriate, at other times disclosing the attributes the RS requires is not needed by the client. For example, an enterprise client accessing a resource does not need to know which groups a user belongs to, but the RS may require that to determine if the user running the client has access. > > A major difference with OAuth 2.0 is that there is no bilateral trust > relationship between an authorization server and a resource server: > for a given category of attributes, a resource server may trust one or > more authorization servers. Another major difference with OAuth 2.0. > is that the content of an attributes token is meant to be accessible to > the client. > > This is not how OAuth 2.0 works. See slides 7 and 8 from my original IETF presentation on what became OAuth 2.0 https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation The AS may not even know who the RS (or PR in the slides) is. > > I got rid of the word "delegation": the client does not delegate anything > to an authorization server. If it would, this would mean that the > authorization server > would be able to act as the client and could know everything that the > client will do, which comes into contradiction with the user's privacy. > The above is not true. The Resource Owner is delegating access control to the AS in authorization use cases. The client is may be delegating user authentication to the AS in identity claim use cases. The AS can act as the client in many OAuth deployments, as the access token is a bearer token. That does not mean the AS knows what the client is doing. /Dick =E1=90=A7 --000000000000ba898805a90034d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Denis, thanks for sharing your thoughts, = some clarifications on your statements inserted:

On Fri, Jun 26, 2020 at 9:4= 2 AM Denis <denis.ietf@free.fr= > wrote:
<snip>

New proposed charte= r

<snip&= gt;=C2=A0
=
=
Resource servers inform their clients about which access token formats are acceptable and depending upon the king of operation
that is requested, which kind of attributes are needed and from which ASs that my be obtained.
While at times th= is may be appropriate, at other times disclosing the attributes the RS requ= ires is not needed by the client. For example, an enterprise client accessi= ng a resource does not need to know which groups a user belongs to, but the= RS may require that to determine if the user running the client has access= .

A major difference with OAuth 2.0 is that there is no bilateral trust relationship between an authorization server and a resource server:
for a given category of attributes, a resource server may trust one or more authorization servers. Another major difference with OAuth 2.0.
is that the content of an attributes token is meant to be accessible to the client.
This is not how OAuth 2.0 works. See slides 7 and 8 from= my original IETF presentation on what became OAuth 2.0


The AS may not even know who the RS (o= r PR in the slides) is.

<snip>=C2=A0


I got rid of the word "delegation": the client does n= ot delegate anything to an authorization server. If it would, this would mean that the authorization server
would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy.


The=C2=A0above is not true.
=C2=A0
The Resource Owner is delegating access control to the AS in authori= zation use cases.

The client is may be delegating = user authentication to the AS in identity claim use cases.

The AS can act as the client in many OAuth deployments, as the acc= ess token is a bearer token. That does not mean the AS knows what the clien= t is doing.=C2=A0

/Dick
=C2=A0
3D==E1=90=A7
--000000000000ba898805a90034d8-- From nobody Fri Jun 26 14:03:06 2020 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 69B243A0C79; Fri, 26 Jun 2020 14:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 pJbYB96_K-KA; Fri, 26 Jun 2020 14:02:59 -0700 (PDT) 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 C4FD03A0C77; Fri, 26 Jun 2020 14:02:58 -0700 (PDT) Received: from [192.168.1.14] (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 05QL2ufd030553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Jun 2020 17:02:56 -0400 From: Justin Richer Message-Id: <830A4653-5912-46DE-8173-BA149899FDD3@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_66E0A1F7-F8B7-4C74-A5C0-2D150F06FB82" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 26 Jun 2020 17:02:56 -0400 In-Reply-To: Cc: txauth@ietf.org, Dick Hardt To: The IESG References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 26 Jun 2020 21:03:02 -0000 --Apple-Mail=_66E0A1F7-F8B7-4C74-A5C0-2D150F06FB82 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with this proposed change in wording for the milestones. We = don=E2=80=99t want to artificially limit the key binding presentation = mechanisms. While I think the three listed are likely to be among the = first ones we see (based on prior art and current community interest), I = don=E2=80=99t think we can predict entirely what will be developed by = the group and when.=20 =E2=80=94 Justin > On Jun 26, 2020, at 1:21 PM, Dick Hardt wrote: >=20 >=20 >=20 > I am concerned with the following milestones: >=20 >=20 > Oct 2021 - Key presentation mechanism binding to the core protocol, = TLS, to > WGLC >=20 > Oct 2021 - Key presentation mechanism binding to the core protocol, > detached HTTP signatures, to WGLC >=20 > Oct 2021 - Key presentation mechanism binding to the core protocol, > embedded HTTP signature, to WGLC >=20 > I think it is overly prescriptive to specify which key presentation = mechanisms will be created, and it implies that other key presentation = mechanisms will not be worked on. While it is possible that channel = binding mechanisms such as TLS, detached HTTP signatures, and embedded = HTTP signatures will be appropriate key presentation mechanisms for = GNAP, it is also quite possible that the WG will determine one or more = are not appropriate, or the underlying mechanism may not gain = acceptance, or channel binding is not always needed. For example, the = effort to bind OAuth access tokens using RFC8471 was disbanded. >=20 > Additionally, there are two primary communication channels in the = protocol that have different security requirements. The client to = authorization server, and the client to resource server. The term "core = protocol" is vague and could be construed that the same mechanism MUST = be used in both channels. >=20 > I propose the following new wording: >=20 > Oct 2021 - Key presentation mechanism binding for each communication = channel to WGLC. >=20 >=20 > ---------- Forwarded message --------- > From: The IESG > > Date: Fri, Jun 26, 2020 at 9:10 AM > Subject: WG Review: Grant Negotiation and Authorization Protocol = (gnap) > To: IETF-Announce > > Cc: > >=20 >=20 > A new IETF WG has been proposed in the Security Area. The IESG has not = made > any determination yet. The following draft charter was submitted, and = is > provided for informational purposes only. Please send your comments to = the > IESG mailing list (iesg@ietf.org ) by = 2020-07-06. >=20 > Grant Negotiation and Authorization Protocol (gnap) > = ----------------------------------------------------------------------- > Current status: Proposed WG >=20 > Chairs: > Yaron Sheffer > > Leif Johansson > >=20 > Assigned Area Director: > Roman Danyliw > >=20 > Security Area Directors: > Benjamin Kaduk > > Roman Danyliw > >=20 > Mailing list: > Address: txauth@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/txauth = > Archive: https://mailarchive.ietf.org/arch/browse/txauth/ = >=20 > Group page: https://datatracker.ietf.org/group/gnap/ = >=20 > Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/ = >=20 > This group is chartered to develop a fine-grained delegation protocol = for > authorization and API access, as well as requesting and providing user > identifiers and claims. This protocol will allow an authorizing party = to > delegate access to client software through an authorization server. It = will > expand upon the uses cases currently supported by OAuth 2.0 and OpenID = Connect > (itself an extension of OAuth 2.0) to support authorizations scoped as > narrowly as a single transaction, provide a clear framework for = interaction > among all parties involved in the protocol flow, and remove = unnecessary > dependence on a browser or user-agent for coordinating interactions. >=20 > The delegation process will be acted upon by multiple parties in the = protocol, > each performing a specific role. The protocol will decouple the = interaction > channels, such as the end user=E2=80=99s browser, from the delegation = channel, which > happens directly between the client and the authorization server (in = contrast > with OAuth 2.0, which is initiated by the client redirecting the = user=E2=80=99s > browser). The protocol will include a means of specifying how the user = can > potentially be involved in an interactive fashion during the = delegation > process. The client and Authorization Server (AS) will use these = interaction > mechanisms to involve the user, as necessary, to make authorization = decisions. > This decoupling avoids many of the security concerns and technical = challenges > of OAuth 2.0 and provides a non-invasive path for supporting future = types of > clients and interaction channels. >=20 > The group will define interoperability for this protocol between = different > parties, including > - client and authorization server; > - client and resource server; and > - authorization server and resource server. >=20 > The group will seek to minimize assumptions about the form of client > applications, allowing for: > - Fine-grained specification of access > - Approval of AS attestation to identifiers and other identity claims > - Approval of access to multiple resources and APIs in a single = interaction > - Support for multiple access tokens in a single request and response > - Support for directed, audience-restricted access tokens > - Separation between the party authorizing access and the party = operating the > client requesting access >=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 > - User interaction mechanisms including web and non-web methods > - Mechanisms for conveying user, software, organization, and other > information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding = resource > requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information (including identifiers = and > identity assertions) through the delegation process >=20 > Additionally, the group will provide mechanisms for management of the = protocol > lifecycle including: >=20 > - Discovery of the authorization server > - Revocation of active tokens > - Mechanisms for the AS and RS to communicate the access granted by an = access > token >=20 > Although the artifacts for this work are not intended or expected to = be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will = attempt > to simplify migrating from OAuth 2.0 and OpenID Connect to the new = protocol > where possible. >=20 > This group is not chartered to develop extensions to OAuth 2.0, and as = such > will focus on new technological solutions not necessarily compatible = with > OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be = directed > to the OAuth Working Group, including functionality back-ported from = the > protocol developed here to OAuth 2.0. >=20 > The group is chartered to develop mechanisms for applying = cryptographic > methods, such as JOSE and COSE, to the delegation process. This group = is not > chartered to develop new cryptographic methods. >=20 > The group is chartered to develop mechanisms for conveying identity > information within the protocol including existing identifiers (such = as email > addresses, phone numbers, usernames, and subject identifiers) and = assertions > (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable > Credentials). The group is not chartered to develop new formats for > identifiers or assertions, nor is the group chartered to develop = schemas for > user information, profiles, or other identity attributes, unless a = viable > existing format is not available. >=20 > The initial work will focus on using HTTPS for communication between = the > client and the authorization server, taking advantage of optimization > features of HTTP/2 and HTTP/3 where possible, and will strive to = enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. >=20 > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol including = TLS, > detached HTTP signature, and embedded HTTP signatures > - Conveyance mechanisms for identifiers and assertions > - Guidelines for use of protocol extension points > - (if needed) Guidelines on migration paths, implementation, and = operations >=20 > Where possible, the group will seek to make use of tools to guide and = inform > the standardization process including formal analysis, architecture = documents, > and use case documents. These artifacts will not be considered as = working > group milestones or deliverables. >=20 > The working group will cooperate and coordinate with other IETF WGs = such as > OAUTH, and work with external organizations, such as the OpenID = Foundation, > as appropriate. >=20 > Milestones: >=20 > Jul 2021 - Core delegation protocol in WGLC >=20 > Oct 2021 - Key presentation mechanism binding to the core protocol, = TLS, to > WGLC >=20 > Oct 2021 - Key presentation mechanism binding to the core protocol,=20= > detached HTTP signatures, to WGLC >=20 > Oct 2021 - Key presentation mechanism binding to the core protocol, > embedded HTTP signature, to WGLC >=20 > Dec 2021 - Guidelines for use of protocol extension points to WGLC >=20 > Feb 2022 - Guidelines on migration paths, implementation, and = operations to > WGLC >=20 >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce = > =E1=90=A7 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth = --Apple-Mail=_66E0A1F7-F8B7-4C74-A5C0-2D150F06FB82 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree with this proposed change in wording for the milestones. We = don=E2=80=99t want to artificially limit the key binding presentation = mechanisms. While I think the three listed are likely to be among the = first ones we see (based on prior art and current community interest), I = don=E2=80=99t think we can predict entirely what will be developed by = the group and when. 

 =E2=80=94 Justin

On Jun = 26, 2020, at 1:21 PM, Dick Hardt <dick.hardt@gmail.com> wrote:



I= am concerned with the following milestones:


  Oct 2021 - Key presentation mechanism binding to the = core protocol, TLS, to
  WGLC

  Oct 2021 - Key presentation mechanism binding to the = core protocol,
  detached HTTP signatures, to WGLC

  Oct 2021 - Key presentation mechanism binding to the = core protocol,
  embedded HTTP signature, to WGLC

I = think it is overly prescriptive to specify which key presentation = mechanisms will be created, and it implies that other key presentation = mechanisms will not be worked on. While it is possible that channel = binding mechanisms such as TLS, detached HTTP signatures, and embedded = HTTP signatures will be appropriate key presentation mechanisms for = GNAP, it is also quite possible that the WG will determine one or more = are not appropriate, or the underlying mechanism may not gain = acceptance, or channel binding is not always needed. For example, the = effort to bind OAuth access tokens using RFC8471 was = disbanded.

Additionally, there are two primary communication channels in = the protocol that have different security requirements. The client to = authorization server, and the client to resource server. The term "core = protocol" is vague and could be construed that the same mechanism MUST = be used in both channels.

I propose the following new wording:

Oct 2021 - Key presentation mechanism = binding for each communication channel to WGLC.


---------- = Forwarded message ---------
From: The IESG <iesg-secretary@ietf.org>
Date: Fri, Jun 26, 2020 at 9:10 AM
Subject: WG = Review: Grant Negotiation and Authorization Protocol (gnap)
To: IETF-Announce <ietf-announce@ietf.org>
Cc: <txauth@ietf.org>


A new IETF WG has been proposed in the Security Area. The = IESG has not made
any determination yet. The following = draft charter was submitted, and is
provided for = informational purposes only. Please send your comments to the
IESG mailing list (iesg@ietf.org) by 2020-07-06.

Grant Negotiation and Authorization Protocol = (gnap)
---------------------------------------------------------------= --------
Current status: Proposed WG

Chairs:
  Yaron Sheffer <yaronf.ietf@gmail.com>
  Leif = Johansson <leifj@sunet.se>

Assigned = Area Director:
  Roman Danyliw <rdd@cert.org>

Security = Area Directors:
  Benjamin Kaduk <kaduk@mit.edu>
  Roman Danyliw = <rdd@cert.org>

Mailing = list:
  Address: txauth@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/txauth
  Archive: https://mailarchive.ietf.org/arch/browse/txauth/

Group page: https://datatracker.ietf.org/group/gnap/

Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/

This group is chartered to develop a = fine-grained delegation protocol for
authorization and API = access, as well as requesting and providing user
identifiers= and claims. This protocol will allow an authorizing party to
delegate access to client software through an authorization = server. It will
expand upon the uses cases currently = supported by OAuth 2.0 and OpenID Connect
(itself an = extension of OAuth 2.0) to support authorizations scoped as
narrowly as a single transaction, provide a clear framework = for interaction
among all parties involved in the protocol = flow, and remove unnecessary
dependence on a browser or = user-agent for coordinating interactions.

The= delegation process will be acted upon by multiple parties in the = protocol,
each performing a specific role. The protocol = will decouple the interaction
channels, such as the end = user=E2=80=99s browser, from the delegation channel, which
happens directly between the client and the authorization = server (in contrast
with OAuth 2.0, which is initiated by = the client redirecting the user=E2=80=99s
browser). The = protocol will include a means of specifying how the user can
potentially be involved in an interactive fashion during the = delegation
process. The client and Authorization Server = (AS) will use these interaction
mechanisms to involve the = user, as necessary, to make authorization decisions.
This = decoupling avoids many of the security concerns and technical = challenges
of OAuth 2.0 and provides a non-invasive path = for supporting future types of
clients and interaction = channels.

The group will define = interoperability for this protocol between different
parties, including
 - client and = authorization server;
 - client and resource server; = and
 - authorization server and resource server.

The group will seek to minimize assumptions = about the form of client
applications, allowing for:
- Fine-grained specification of access
- = Approval of AS attestation to identifiers and other identity claims
- Approval of access to multiple resources and APIs in a = single interaction
- Support for multiple access tokens in = a single request and response
- Support for directed, = audience-restricted access tokens
- Separation between the = party authorizing access and the party operating the
client = requesting access

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
- Mechanisms for conveying user, software, organization, and = other
information used in authorization decisions
- Mechanisms for presenting tokens to resource servers and = binding resource
requests to tokens and associated = cryptographic keys
- Optimized inclusion of additional = information (including identifiers and
identity = assertions) through the delegation process

Additionally, the group will provide mechanisms for = management of the protocol
lifecycle including:

- Discovery of the authorization server
- Revocation of active tokens
- Mechanisms for = the AS and RS to communicate the access granted by an access
token

Although the artifacts for = this work are not intended or expected to be
backwards-compatible with OAuth 2.0 or OpenID Connect, the = group will attempt
to simplify migrating from OAuth 2.0 = and OpenID Connect to the new protocol
where possible.

This group is not chartered to develop = extensions to OAuth 2.0, and as such
will focus on new = technological solutions not necessarily compatible with
OAuth 2.0. Functionality that builds directly on OAuth 2.0 = will be directed
to the OAuth Working Group, including = functionality back-ported from the
protocol developed here = to OAuth 2.0.

The group is chartered to = develop mechanisms for applying cryptographic
methods, = such as JOSE and COSE, to the delegation process. This group is not
chartered to develop new cryptographic methods.

The group is chartered to develop mechanisms = for conveying identity
information within the protocol = including existing identifiers (such as email
addresses, = phone numbers, usernames, and subject identifiers) and assertions
(such as OpenID Connect ID Tokens, SAML Assertions, and = Verifiable
Credentials). The group is not chartered to = develop new formats for
identifiers or assertions, nor is = the group chartered to develop schemas for
user = information, profiles, or other identity attributes, unless a viable
existing format is not available.

The initial work will focus on using HTTPS for communication = between the
client and the authorization server, taking = advantage of optimization
features of HTTP/2 and HTTP/3 = where possible, and will strive to enable
simple mapping = to other protocols such as COAP when doing so does not
conflict with the primary focus.

Milestones to include:
- Core delegation = protocol
- Key presentation mechanism bindings to the core = protocol including TLS,
detached HTTP signature, and = embedded HTTP signatures
- Conveyance mechanisms for = identifiers and assertions
- Guidelines for use of = protocol extension points
- (if needed) Guidelines on = migration paths, implementation, and operations

Where possible, the group will seek to make use of tools to = guide and inform
the standardization process including = formal analysis, architecture documents,
and use case = documents. These artifacts will not be considered as working
group milestones or deliverables.

The working group will cooperate and coordinate with other = IETF WGs such as
OAUTH, and work with external = organizations, such as the OpenID Foundation,
as = appropriate.

Milestones:

  Jul 2021 - Core delegation protocol in WGLC

  Oct 2021 - Key presentation mechanism = binding to the core protocol, TLS, to
  WGLC

  Oct 2021 - Key presentation mechanism = binding to the core protocol, 
  = detached HTTP signatures, to WGLC

  = Oct 2021 - Key presentation mechanism binding to the core protocol,
  embedded HTTP signature, to WGLC

  Dec 2021 - Guidelines for use of protocol extension = points to WGLC

  Feb 2022 - Guidelines = on migration paths, implementation, and operations to
 =  WGLC



_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
3D""=E1=90=A7
-- Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_66E0A1F7-F8B7-4C74-A5C0-2D150F06FB82-- From nobody Fri Jun 26 15:10:02 2020 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 1619C3A0CE5; Fri, 26 Jun 2020 15:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 TT933suRZsb3; Fri, 26 Jun 2020 15:09:54 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 436AD3A0CE0; Fri, 26 Jun 2020 15:09:47 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id q21so2483916otc.7; Fri, 26 Jun 2020 15:09:47 -0700 (PDT) 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=gXarehUMIi/W4CfH4Yu4hMrDdsxcxvEtbHZ6yp4vgMI=; b=XTLc9zQ6RY9yuELbn2hWYJOHXH2myLp3ceRcFazxAm+R0k7xPiaClEw+6hIbGB0EEE XLHGreCfYLfo9MJlwxtg6tVPsxaWoOW7f2FzV9vsisA5uoJsYT2Z2DlY0Ay9+xNmRNzA e3pSZEvC3UYBZfKwAKVkdCO6g+MCt5IO8DEdmnR2LRbCh5+vkthsRi1oaDXcdpJ+iaVY rwRBCg3uVCjcWwQdM8RF3/1Mwmp2ANgNeD3ewGnLJFES76kxRljOG6oTY03/n+39B5RC UA6MBddavXL8vOi3fSdrqJCDNUltmcO1xmqyL8mlYRecSTpG2C3gxXWy6u5vWdVI56Nh kkKw== 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=gXarehUMIi/W4CfH4Yu4hMrDdsxcxvEtbHZ6yp4vgMI=; b=DDtDW8NMVzsC+O5HLxyVpLdIVOkhp0d7813Kzm8fGxpxN8+2ifRdcA5jB4QSvZd9/S uCq+7qJuYv3LI7+oRXkNEJD0ULBTH29lvfgdYN4SYwbxfIw63IymX1K/A1NU0SEbsn9o GwjFGlzvz6WfXnXEH2k62dc6gHwdLs2xIahCBrM2Oi6Vu68ybZlHHMp86r6RxnYp2601 p7Cwqu1CvMudiDxCDYKpEhQKhOdxpb8d/QLgrgiNozVoJK423jc2yDK/PRXq8IMoU8mK loGBrdkC+jp2jZ8zG0Du81c+/fhlT8sgSh/p+yIzlg5lIUg57pJk5mFKG7wExIrF6Dq6 epjw== X-Gm-Message-State: AOAM533dE5Woj1uTK7f0YV4q9HOf8VQqaAHp1ue2Yg1OJULSLFxyji4d lUMOr0r+LJIygk1CvNPRjO36GHbrIpWgkQjsd8o= X-Google-Smtp-Source: ABdhPJzD6m3qR2jAg4MLESa5LjvXGI61vBZ4JxEfhMa4EVXJZJslipM9AYvkOQbnB63dI48ZNR7kjCKngYJvCfv59ds= X-Received: by 2002:a05:6830:837:: with SMTP id t23mr4065501ots.87.1593209386356; Fri, 26 Jun 2020 15:09:46 -0700 (PDT) MIME-Version: 1.0 References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <830A4653-5912-46DE-8173-BA149899FDD3@mit.edu> In-Reply-To: <830A4653-5912-46DE-8173-BA149899FDD3@mit.edu> From: Tom Jones Date: Fri, 26 Jun 2020 15:09:34 -0700 Message-ID: To: Justin Richer Cc: The IESG , txauth@ietf.org, Dick Hardt Content-Type: multipart/alternative; boundary="00000000000086d8b505a903f719" Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 26 Jun 2020 22:09:57 -0000 --00000000000086d8b505a903f719 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Right - I have already proposed binding to application level keys in other venues and strongly oppose continued use of channel binding. Peace ..tom On Fri, Jun 26, 2020 at 2:03 PM Justin Richer wrote: > I agree with this proposed change in wording for the milestones. We don= =E2=80=99t > want to artificially limit the key binding presentation mechanisms. While= I > think the three listed are likely to be among the first ones we see (base= d > on prior art and current community interest), I don=E2=80=99t think we ca= n predict > entirely what will be developed by the group and when. > > =E2=80=94 Justin > > On Jun 26, 2020, at 1:21 PM, Dick Hardt wrote: > > > > I am concerned with the following milestones: > > > Oct 2021 - Key presentation mechanism binding to the core protocol, > TLS, to > WGLC > > Oct 2021 - Key presentation mechanism binding to the core protocol, > detached HTTP signatures, to WGLC > > Oct 2021 - Key presentation mechanism binding to the core protocol, > embedded HTTP signature, to WGLC > > I think it is overly prescriptive to specify which key presentation > mechanisms will be created, and it implies that other key presentation > mechanisms will not be worked on. While it is possible that channel bindi= ng > mechanisms such as TLS, detached HTTP signatures, and embedded HTTP > signatures will be appropriate key presentation mechanisms for GNAP, it i= s > also quite possible that the WG will determine one or more are not > appropriate, or the underlying mechanism may not gain acceptance, or > channel binding is not always needed. For example, the effort to bind OAu= th > access tokens using RFC8471 was disbanded. > > Additionally, there are two primary communication channels in the protoco= l > that have different security requirements. The client to authorization > server, and the client to resource server. The term "core protocol" is > vague and could be construed that the same mechanism MUST be used in both > channels. > > I propose the following new wording: > > Oct 2021 - Key presentation mechanism binding for each communication > channel to WGLC. > > > ---------- Forwarded message --------- > From: The IESG > Date: Fri, Jun 26, 2020 at 9:10 AM > Subject: WG Review: Grant Negotiation and Authorization Protocol (gnap) > To: IETF-Announce > Cc: > > > A new IETF WG has been proposed in the Security Area. The IESG has not ma= de > any determination yet. The following draft charter was submitted, and is > provided for informational purposes only. Please send your comments to th= e > IESG mailing list (iesg@ietf.org) by 2020-07-06. > > Grant Negotiation and Authorization Protocol (gnap) > ----------------------------------------------------------------------- > Current status: Proposed WG > > Chairs: > Yaron Sheffer > Leif Johansson > > Assigned Area Director: > Roman Danyliw > > Security Area Directors: > Benjamin Kaduk > Roman Danyliw > > Mailing list: > Address: txauth@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/txauth > Archive: https://mailarchive.ietf.org/arch/browse/txauth/ > > Group page: https://datatracker.ietf.org/group/gnap/ > > Charter: https://datatracker.ietf.org/doc/charter-ietf-gnap/ > > This group is chartered to develop a fine-grained delegation protocol for > authorization and API access, as well as requesting and providing user > identifiers and claims. This protocol will allow an authorizing party to > delegate access to client software through an authorization server. It wi= ll > expand upon the uses cases currently supported by OAuth 2.0 and OpenID > Connect > (itself an extension of OAuth 2.0) to support authorizations scoped as > narrowly as a single transaction, provide a clear framework for interacti= on > among all parties involved in the protocol flow, and remove unnecessary > dependence on a browser or user-agent for coordinating interactions. > > The delegation process will be acted upon by multiple parties in the > protocol, > each performing a specific role. The protocol will decouple the interacti= on > channels, such as the end user=E2=80=99s browser, from the delegation cha= nnel, > which > happens directly between the client and the authorization server (in > contrast > with OAuth 2.0, which is initiated by the client redirecting the user=E2= =80=99s > browser). The protocol will include a means of specifying how the user ca= n > potentially be involved in an interactive fashion during the delegation > process. The client and Authorization Server (AS) will use these > interaction > mechanisms to involve the user, as necessary, to make authorization > decisions. > This decoupling avoids many of the security concerns and technical > challenges > of OAuth 2.0 and provides a non-invasive path for supporting future types > of > clients and interaction channels. > > The group will define interoperability for this protocol between differen= t > parties, including > - client and authorization server; > - client and resource server; and > - authorization server and resource server. > > The group will seek to minimize assumptions about the form of client > applications, allowing for: > - Fine-grained specification of access > - Approval of AS attestation to identifiers and other identity claims > - Approval of access to multiple resources and APIs in a single interacti= on > - Support for multiple access tokens in a single request and response > - Support for directed, audience-restricted access tokens > - Separation between the party authorizing access and the party operating > the > client requesting access > > 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 > - Mechanisms for conveying user, software, organization, and other > information used in authorization decisions > - Mechanisms for presenting tokens to resource servers and binding resour= ce > requests to tokens and associated cryptographic keys > - Optimized inclusion of additional information (including identifiers an= d > identity assertions) through the delegation process > > Additionally, the group will provide mechanisms for management of the > protocol > lifecycle including: > > - Discovery of the authorization server > - Revocation of active tokens > - Mechanisms for the AS and RS to communicate the access granted by an > access > token > > Although the artifacts for this work are not intended or expected to be > backwards-compatible with OAuth 2.0 or OpenID Connect, the group will > attempt > to simplify migrating from OAuth 2.0 and OpenID Connect to the new protoc= ol > where possible. > > This group is not chartered to develop extensions to OAuth 2.0, and as su= ch > will focus on new technological solutions not necessarily compatible with > OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be direct= ed > to the OAuth Working Group, including functionality back-ported from the > protocol developed here to OAuth 2.0. > > The group is chartered to develop mechanisms for applying cryptographic > methods, such as JOSE and COSE, to the delegation process. This group is > not > chartered to develop new cryptographic methods. > > The group is chartered to develop mechanisms for conveying identity > information within the protocol including existing identifiers (such as > email > addresses, phone numbers, usernames, and subject identifiers) and > assertions > (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable > Credentials). The group is not chartered to develop new formats for > identifiers or assertions, nor is the group chartered to develop schemas > for > user information, profiles, or other identity attributes, unless a viable > existing format is not available. > > The initial work will focus on using HTTPS for communication between the > client and the authorization server, taking advantage of optimization > features of HTTP/2 and HTTP/3 where possible, and will strive to enable > simple mapping to other protocols such as COAP when doing so does not > conflict with the primary focus. > > Milestones to include: > - Core delegation protocol > - Key presentation mechanism bindings to the core protocol including TLS, > detached HTTP signature, and embedded HTTP signatures > - Conveyance mechanisms for identifiers and assertions > - Guidelines for use of protocol extension points > - (if needed) Guidelines on migration paths, implementation, and operatio= ns > > Where possible, the group will seek to make use of tools to guide and > inform > the standardization process including formal analysis, architecture > documents, > and use case documents. These artifacts will not be considered as working > group milestones or deliverables. > > The working group will cooperate and coordinate with other IETF WGs such = as > OAUTH, and work with external organizations, such as the OpenID Foundatio= n, > as appropriate. > > Milestones: > > Jul 2021 - Core delegation protocol in WGLC > > Oct 2021 - Key presentation mechanism binding to the core protocol, TLS= , > to > WGLC > > Oct 2021 - Key presentation mechanism binding to the core protocol, > detached HTTP signatures, to WGLC > > Oct 2021 - Key presentation mechanism binding to the core protocol, > embedded HTTP signature, to WGLC > > Dec 2021 - Guidelines for use of protocol extension points to WGLC > > Feb 2022 - Guidelines on migration paths, implementation, and operation= s > to > WGLC > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > =E1=90=A7 > -- > 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 > --00000000000086d8b505a903f719 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right - I have already proposed binding to application lev= el keys in other venues and strongly oppose continued use of channel bindin= g.
Peace ..tom


On Fri, Jun 26, 2020 at 2:03 PM Justin Richer <jricher@mit.edu> wrote:
I agree with this proposed change in wording for the milestones. = We don=E2=80=99t want to artificially limit the key binding presentation me= chanisms. While I think the three listed are likely to be among the first o= nes we see (based on prior art and current community interest), I don=E2=80= =99t think we can predict entirely what will be developed by the group and = when.=C2=A0

=C2=A0=E2=80=94 Justin

On Jun 26, 2020, at 1:21 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:



I am concerned with the following milestones:


=C2=A0 Oct 2021 -=C2=A0Key= =C2=A0presentation=C2=A0mechanism binding to the core protocol= , TLS, to
=C2=A0 WGLC

=C2=A0 Oct 2021 -=C2=A0Key=C2= =A0presentation=C2=A0mechanism binding to the core protocol,=C2=A0 detached HTTP signatures, to WGLC

=C2=A0 Oct 2021 -=C2=A0Key=C2=A0presentation=C2=A0mechanism binding to the= core protocol,
=C2=A0 embedded HTTP signature, to WGLC
I think it is overly prescriptive to specify which key present= ation mechanisms will be created, and it implies that other key presentatio= n mechanisms will not be worked on. While it is possible that channel bindi= ng mechanisms such as TLS, detached HTTP signatures, and embedded HTTP sign= atures will be appropriate key presentation mechanisms for GNAP, it is also= quite possible that the WG will determine one or more are not appropriate,= or the underlying mechanism may not gain acceptance, or channel binding is= not always needed. For example, the effort to bind OAuth access tokens usi= ng RFC8471 was disbanded.

Additionally, there are = two primary communication channels in the protocol that have different secu= rity requirements. The client to authorization server, and the client to re= source server. The term "core protocol" is vague and could be con= strued that the same mechanism MUST be used in both channels.
I propose the following new wording:

O= ct 2021 - Key presentation mechanism binding for each communication channel= to WGLC.


---------- Forwarded message -= --------
Fr= om:=C2=A0The I= ESG=C2=A0<iesg-secretary@ietf.org>
Date: Fri, Jun 26, 2020 at 9:10 AM
Subject: WG Review: Grant Nego= tiation and Authorization Protocol (gnap)
To: IETF-Announce <ietf-announce@ietf.org= >
Cc: <tx= auth@ietf.org>


A new IETF WG has been proposed in t= he Security Area. The IESG has not made
any determination yet. The follo= wing draft charter was submitted, and is
provided for informational purp= oses only. Please send your comments to the
IESG mailing list (iesg@ietf.org) by 2020-07-0= 6.

Grant Negotiation and Authorization Protocol (gnap)
----------= -------------------------------------------------------------
Current st= atus: Proposed WG

Chairs:
=C2=A0 Yaron Sheffer <yaronf.ietf@gmail.com><= br>=C2=A0 Leif Johansson <leifj@sunet.se>

Assigned Area Director:
=C2=A0 Roman= Danyliw <rdd@cert.org= >

Security Area Directors:
=C2=A0 Benjamin Kaduk <kaduk@mit.edu>
=C2= =A0 Roman Danyliw <rdd= @cert.org>

Mailing list:
=C2=A0 Address:=C2=A0txauth@ietf.org=C2=A0 To subscribe:=C2=A0https://www.iet= f.org/mailman/listinfo/txauth
=C2=A0 Archive:=C2=A0https://mailarchive.ietf.org/arch/browse/txauth/
=
Group page:=C2=A0https://datatracker.ietf.o= rg/group/gnap/

Charter:=C2=A0https://datatracker.ietf.org/doc/charter-ietf-gnap/

This gro= up is chartered to develop a fine-grained delegation protocol for
author= ization and API access, as well as requesting and providing user
identif= iers and claims. This protocol will allow an authorizing party to
delega= te access to client software through an authorization server. It will
ex= pand upon the uses cases currently supported by OAuth 2.0 and OpenID Connec= t
(itself an extension of OAuth 2.0) to support authorizations scoped as=
narrowly as a single transaction, provide a clear framework for interac= tion
among all parties involved in the protocol flow, and remove unneces= sary
dependence on a browser or user-agent for coordinating interactions= .

The delegation process will be acted upon by multiple parties in t= he protocol,
each performing a specific role. The protocol will decouple= the interaction
channels, such as the end user=E2=80=99s browser, from = the delegation channel, which
happens directly between the client and th= e authorization server (in contrast
with OAuth 2.0, which is initiated b= y the client redirecting the user=E2=80=99s
browser). The protocol will = include a means of specifying how the user can
potentially be involved i= n an interactive fashion during the delegation
process. The client and A= uthorization Server (AS) will use these interaction
mechanisms to involv= e the user, as necessary, to make authorization decisions.
This decoupli= ng avoids many of the security concerns and technical challenges
of OAut= h 2.0 and provides a non-invasive path for supporting future types of
cl= ients and interaction channels.

The group will define interoperabili= ty for this protocol between different
parties, including
=C2=A0- cli= ent and authorization server;
=C2=A0- client and resource server; and=C2=A0- authorization server and resource server.

The group will se= ek to minimize assumptions about the form of client
applications, allowi= ng for:
- Fine-grained specification of access
- Approval of AS attes= tation to identifiers and other identity claims
- Approval of access to = multiple resources and APIs in a single interaction
- Support for multip= le access tokens in a single request and response
- Support for directed= , audience-restricted access tokens
- Separation between the party autho= rizing access and the party operating the
client requesting access
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 interaction mechanisms = including web and non-web methods
- Mechanisms for conveying user, softw= are, organization, and other
information used in authorization decisions=
- Mechanisms for presenting tokens to resource servers and binding reso= urce
requests to tokens and associated cryptographic keys
- Optimized= inclusion of additional information (including identifiers and
identity= assertions) through the delegation process

Additionally, the group = will provide mechanisms for management of the protocol
lifecycle includi= ng:

- Discovery of the authorization server
- Revocation of activ= e tokens
- Mechanisms for the AS and RS to communicate the access grante= d by an access
token

Although the artifacts for this work are not= intended or expected to be
backwards-compatible with OAuth 2.0 or OpenI= D Connect, the group will attempt
to simplify migrating from OAuth 2.0 a= nd OpenID Connect to the new protocol
where possible.

This group = is not chartered to develop extensions to OAuth 2.0, and as such
will fo= cus on new technological solutions not necessarily compatible with
OAuth= 2.0. Functionality that builds directly on OAuth 2.0 will be directed
t= o the OAuth Working Group, including functionality back-ported from the
= protocol developed here to OAuth 2.0.

The group is chartered to deve= lop mechanisms for applying cryptographic
methods, such as JOSE and COSE= , to the delegation process. This group is not
chartered to develop new = cryptographic methods.

The group is chartered to develop mechanisms = for conveying identity
information within the protocol including existin= g identifiers (such as email
addresses, phone numbers, usernames, and su= bject identifiers) and assertions
(such as OpenID Connect ID Tokens, SAM= L Assertions, and Verifiable
Credentials). The group is not chartered to= develop new formats for
identifiers or assertions, nor is the group cha= rtered to develop schemas for
user information, profiles, or other ident= ity attributes, unless a viable
existing format is not available.
The initial work will focus on using HTTPS for communication between theclient and the authorization server, taking advantage of optimization
= features of HTTP/2 and HTTP/3 where possible, and will strive to enable
= simple mapping to other protocols such as COAP when doing so does not
co= nflict with the primary focus.

Milestones to include:
- Core dele= gation protocol
- Key presentation mechanism bindings to the core protoc= ol including TLS,
detached HTTP signature, and embedded HTTP signatures<= br>- Conveyance mechanisms for identifiers and assertions
- Guidelines f= or use of protocol extension points
- (if needed) Guidelines on migratio= n paths, implementation, and operations

Where possible, the group wi= ll seek to make use of tools to guide and inform
the standardization pro= cess including formal analysis, architecture documents,
and use case doc= uments. These artifacts will not be considered as working
group mileston= es or deliverables.

The working group will cooperate and coordinate = with other IETF WGs such as
OAUTH, and work with external organizations,= such as the OpenID Foundation,
as appropriate.

Milestones:
=C2=A0 Jul 2021 - Core delegation protocol in WGLC

=C2=A0 Oct 2021= - Key presentation mechanism binding to the core protocol, TLS, to
=C2= =A0 WGLC

=C2=A0 Oct 2021 - Key presentation mechanism binding to the= core protocol,=C2=A0
=C2=A0 detached HTTP signatures, to W= GLC

=C2=A0 Oct 2021 - Key presentation mechanism binding to the core= protocol,
=C2=A0 embedded HTTP signature, to WGLC

=C2=A0 Dec 202= 1 - Guidelines for use of protocol extension points to WGLC

=C2=A0 F= eb 2022 - Guidelines on migration paths, implementation, and operations to<= br>=C2=A0 =C2=A0WGLC



_______________________________________= ________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
=E1=90=A7
--=C2=A0
<= span style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-v= ariant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:star= t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;t= ext-decoration:none;float:none;display:inline">Txauth mailing listTxauth@ie= tf.org
https://www.ietf.org/mailman/listinfo/txauth

--
Txauth mailing list
Txauth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000086d8b505a903f719-- From nobody Sat Jun 27 12:56:47 2020 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 2AD543A003E for ; Sat, 27 Jun 2020 12:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 f8qhvjRnwbvY for ; Sat, 27 Jun 2020 12:56:44 -0700 (PDT) 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 BF30D3A0033 for ; Sat, 27 Jun 2020 12:56:43 -0700 (PDT) Received: from [192.168.1.14] (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 05RJucf3025862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Jun 2020 15:56:40 -0400 From: Justin Richer Message-Id: <353AF4E4-4939-4994-960E-54B0AADC6253@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_12FE2FC2-9454-4648-9FF7-0CEB52FECEDB" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 27 Jun 2020 15:56:38 -0400 In-Reply-To: Cc: Denis , Dick Hardt To: txauth@ietf.org References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 27 Jun 2020 19:56:46 -0000 --Apple-Mail=_12FE2FC2-9454-4648-9FF7-0CEB52FECEDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Removing the IESG as this is really a more internal-to-the-group = discussion, as it comes down to the scope of use cases that we want to = address here in GNAP. While it is definitely important to understand how and why OAuth 2 does = things, we do need to keep use cases like Denis=E2=80=99s in mind. = It=E2=80=99s not unheard of today for a single OAuth 2 RS to accept = tokens from multiple AS=E2=80=99s. In fact, we=E2=80=99ve even got cases = with things like the Solid project where the RS will take a token from = :any: AS so long as it can verify that it=E2=80=99s approved by the = resource owner. While the Solid platform has its own special layering in = place to allow this, our model should not assume a closely-tied = connection between an RS and any single AS. The question of :how: we = solve that is, of course, up to the WG to figure out over time. Taking that even further, I think the idea of an AS that=E2=80=99s = personal to the user, to promote privacy and control, is a very good = one. In fact, this is one of the main selling points of UMA2 and its = federated authorization mechanisms. With GNAP, we might be able to = deliver on this promise even more than UMA has been able to, and it=E2=80=99= s my hope that we can have a cohesive protocol that allows both = user-to-self and user-to-another delegation sharing without needing to = use different mechanisms.=20 Additionally, the RS-first method is also something from the UMA2 work = that we should be working on, as it touches on AS discovery, AS/RS = communication, and a few other aspects of the protocol design. It=E2=80=99= s not a trivial problem by any stretch, and there are huge privacy and = security implications, but there=E2=80=99s both need for it and some = good prior art to pull from. In fact, XYZ=E2=80=99s whole notion of a = =E2=80=9Ctransaction handle=E2=80=9D is an adaptation of UMA2=E2=80=99s = =E2=80=9Cpermission ticket=E2=80=9D. In UMA, this ticket is first issued = to the RS by the AS, and the RS then hands it to the client, which = starts the negotiation for access. I envision something very similar = happening here with GNAP, where a client can get something to bootstrap = the process at the AS. The important thing, to me, is that we don=E2=80=99= t have to jump through a bunch of weird hoops such that the AS-first and = RS-first cases look completely different, as they do in UMA2 and OAuth 2 = respectively today. We=E2=80=99ve got the chance to have a clean and = cohesive protocol here, let=E2=80=99s not miss that opportunity. So in sum, the trust model of OAuth 2 is not sufficient to cover = everything, and the model that Denis is proposing is something we should = at least look at as a use case. Where Denis and I seem to disagree is = whether this trust model should be the :only: one that we address with = the protocol. I strongly believe, as I believe much of this group does, = that we can=E2=80=99t discount or ignore (or make things overly = difficult for) the tightly bound AS/RS combos, or any type of static = setup where the RS offloads its trust fully to the AS. But it=E2=80=99s = my belief that we should be able to do so without needlessly throwing = out all of the OAuth 2 use cases. We shouldn=E2=80=99t let =E2=80=9COAuth 2 doesn=E2=80=99t do it that = way=E2=80=9D be the limiting factor here. We need to understand the what = and wherefore of things that OAuth 2 is bad at, otherwise we=E2=80=99re = just going to re-invent OAuth 2 and inherit its problems. =E2=80=94 Justin > On Jun 26, 2020, at 1:39 PM, Dick Hardt wrote: >=20 > Denis, thanks for sharing your thoughts, some clarifications on your = statements inserted: >=20 > On Fri, Jun 26, 2020 at 9:42 AM Denis > wrote: > > New proposed charter >=20 > =20 >=20 > Resource servers inform their clients about which access token formats = are acceptable and depending upon the king of operation > that is requested, which kind of attributes are needed and from which = ASs that my be obtained. >=20 > While at times this may be appropriate, at other times disclosing the = attributes the RS requires is not needed by the client. For example, an = enterprise client accessing a resource does not need to know which = groups a user belongs to, but the RS may require that to determine if = the user running the client has access.. >=20 > A major difference with OAuth 2.0 is that there is no bilateral trust = relationship between an authorization server and a resource server:=20 > for a given category of attributes, a resource server may trust one or = more authorization servers. Another major difference with OAuth 2.0. > is that the content of an attributes token is meant to be accessible = to the client. > This is not how OAuth 2.0 works. See slides 7 and 8 from my original = IETF presentation on what became OAuth 2.0 >=20 > https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation = >=20 > The AS may not even know who the RS (or PR in the slides) is. >=20 > =20 >=20 > I got rid of the word "delegation": the client does not delegate = anything to an authorization server. If it would, this would mean that = the authorization server=20 > would be able to act as the client and could know everything that the = client will do, which comes into contradiction with the user's privacy. >=20 >=20 > The above is not true. > =20 > The Resource Owner is delegating access control to the AS in = authorization use cases. >=20 > The client is may be delegating user authentication to the AS in = identity claim use cases. >=20 > The AS can act as the client in many OAuth deployments, as the access = token is a bearer token. That does not mean the AS knows what the client = is doing.=20 >=20 > /Dick > =20 > =E1=90=A7 > --=20 > Txauth mailing list > Txauth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth --Apple-Mail=_12FE2FC2-9454-4648-9FF7-0CEB52FECEDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Removing the IESG as this is really a more = internal-to-the-group discussion, as it comes down to the scope of use = cases that we want to address here in GNAP.

While it is definitely important to = understand how and why OAuth 2 does things, we do need to keep use cases = like Denis=E2=80=99s in mind. It=E2=80=99s not unheard of today for a = single OAuth 2 RS to accept tokens from multiple AS=E2=80=99s. In fact, = we=E2=80=99ve even got cases with things like the Solid project where = the RS will take a token from :any: AS so long as it can verify that = it=E2=80=99s approved by the resource owner. While the Solid platform = has its own special layering in place to allow this, our model should = not assume a closely-tied connection between an RS and any single AS. = The question of :how: we solve that is, of course, up to the WG to = figure out over time.

Taking that even further, I think the idea of an AS that=E2=80=99= s personal to the user, to promote privacy and control, is a very good = one. In fact, this is one of the main selling points of UMA2 and its = federated authorization mechanisms. With GNAP, we might be able to = deliver on this promise even more than UMA has been able to, and it=E2=80=99= s my hope that we can have a cohesive protocol that allows both = user-to-self and user-to-another delegation sharing without needing to = use different mechanisms. 

Additionally, the RS-first method is = also something from the UMA2 work that we should be working on, as it = touches on AS discovery, AS/RS communication, and a few other aspects of = the protocol design. It=E2=80=99s not a trivial problem by any stretch, = and there are huge privacy and security implications, but there=E2=80=99s = both need for it and some good prior art to pull from. In fact, XYZ=E2=80=99= s whole notion of a =E2=80=9Ctransaction handle=E2=80=9D is an = adaptation of UMA2=E2=80=99s =E2=80=9Cpermission ticket=E2=80=9D. In = UMA, this ticket is first issued to the RS by the AS, and the RS then = hands it to the client, which starts the negotiation for access. I = envision something very similar happening here with GNAP, where a client = can get something to bootstrap the process at the AS. The important = thing, to me, is that we don=E2=80=99t have to jump through a bunch of = weird hoops such that the AS-first and RS-first cases look completely = different, as they do in UMA2 and OAuth 2 respectively today. We=E2=80=99v= e got the chance to have a clean and cohesive protocol here, let=E2=80=99s= not miss that opportunity.

So in sum, the trust model of OAuth 2 is not sufficient to = cover everything, and the model that Denis is proposing is something we = should at least look at as a use case. Where Denis and I seem to = disagree is whether this trust model should be the :only: one that we = address with the protocol. I strongly believe, as I believe much of this = group does, that we can=E2=80=99t discount or ignore (or make things = overly difficult for) the tightly bound AS/RS combos, or any type of = static setup where the RS offloads its trust fully to the AS. But it=E2=80= =99s my belief that we should be able to do so without needlessly = throwing out all of the OAuth 2 use cases.

We shouldn=E2=80=99t let =E2=80=9COAuth = 2 doesn=E2=80=99t do it that way=E2=80=9D be the limiting factor here. = We need to understand the what and wherefore of things that OAuth 2 is = bad at, otherwise we=E2=80=99re just going to re-invent OAuth 2 and = inherit its problems.

 =E2=80=94 Justin

On Jun = 26, 2020, at 1:39 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Denis, = thanks for sharing your thoughts, some clarifications on your statements = inserted:

On Fri, Jun 26, 2020 at 9:42 AM Denis <denis.ietf@free.fr> = wrote:
<snip>

New proposed = charter

<snip> 

Resource servers inform their clients about which access token formats are acceptable and depending upon the king of operation
that is requested, which kind of attributes are needed and from which ASs that my be = obtained.

While at times this may be appropriate, at other times = disclosing the attributes the RS requires is not needed by the client. = For example, an enterprise client accessing a resource does not need to = know which groups a user belongs to, but the RS may require that to = determine if the user running the client has access..

A major difference with OAuth 2.0 is that there is no bilateral trust relationship between an authorization server and a resource server:
for a given category of attributes, a resource server may trust one or more authorization servers. Another major difference with OAuth 2.0.
is that the content of an attributes token is meant to be accessible to the = client.
This is not how OAuth 2.0 works. See slides 7 and 8 from my = original IETF presentation on what became OAuth 2.0

https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presen= tation

The = AS may not even know who the RS (or PR in the slides) is.

<snip> 


I got rid of the word "delegation": the client does not delegate anything to an authorization server. If it would, this would mean that the authorization server
would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy.


The above is not true.
 
The Resource Owner is delegating = access control to the AS in authorization use cases.

The client is may be = delegating user authentication to the AS in identity claim use = cases.

The AS = can act as the client in many OAuth deployments, as the access token is = a bearer token. That does not mean the AS knows what the client is = doing. 

/Dick
 
3D""=E1=90=A7
--
Txauth mailing list
Txauth@ietf.org
https://www.ietf.org/mailman/listinfo/txauth

= --Apple-Mail=_12FE2FC2-9454-4648-9FF7-0CEB52FECEDB-- From nobody Sat Jun 27 13:14:58 2020 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 7938D3A00C1 for ; Sat, 27 Jun 2020 13:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 hDTXNBzuAn0q for ; Sat, 27 Jun 2020 13:14:54 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 00BF33A003B for ; Sat, 27 Jun 2020 13:14:53 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id h22so6634757lji.9 for ; Sat, 27 Jun 2020 13:14:53 -0700 (PDT) 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=I9xb9pG9ShZ1I2i0l/rt0ZyP/NCbuPL3ZNFnXr64RtA=; b=gDczc/64u/ZxcW7ZnB6xgG8KOQ30xE5A/45FJFUyEXM1Bcklk+VghcF+4Vf5XSQTJI rxX0bS8sCZ7Aljb89RoELt7ve8+yPZr0BlJF90MuH0i3UIn78lnOLamdlALPSdDwND5G afZeS9KhX5LxN4kk46uTsNvrGQ4qVMTcGdCR4C1FKaXDeirjIXLpdv3fYSdmQS0FfqLK EalbgmXtOa8l4qwCwHq/BkOZcQdsAAf8nF1+VjFIRzOc9iOLc/6DO8Oa1FxL4mjv8cfA x98IaEmBM9X+QQXFD/S5HT9Cpa0XHXDEIO1B7oNN44bizvftFCZ7ZS81odvzfuiYJN0w vkkQ== 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=I9xb9pG9ShZ1I2i0l/rt0ZyP/NCbuPL3ZNFnXr64RtA=; b=WGyrjKJHr58bDQBLYYE3LrpZ15dtg2/gde5aYtxK2t6wUTcmDv4Fw+ktxw1DOyjR9t uiI5NGeu3xIz2MbdhwjaUkN5TuaIgp5U1R8oilKYaHdvZQp1ZtlwrM/ZT6LyHXV0OIRb 0MZx4EKQS0RAwQByuorrpRukuoNS0lLnxJ5Nt3LfVBLl2mGoy7EBrRgRYIKSFqMQCnUU 0vGX4zOkIc6tZe7zV6AwioW1g3IfZB8h6oyYsgYPyT83LQVK3xj09C3uWc3jPwVYVimZ eljnvrRD1Zrcz6t0CeAJEZd18H304cGn+bES8PDwA0BsoEvkNgqjKhqIZN55xBe2XZoT Oesg== X-Gm-Message-State: AOAM5301F8garji0TXhWqKaVLxatnb3xX5MGsYSCQQBSCvMjt1LUmwkA awN36d1o+dNLHzB0SW9FeXZ9Cp2kx7b6XR+hrc4= X-Google-Smtp-Source: ABdhPJz+dv631uayJ/x2ASVTf+hgg+TIjb+Dastr1k41Vb3X+OkHe2faMm617QcYPdwfkXUlviGugGsmpkMwMQc57Ts= X-Received: by 2002:a2e:750c:: with SMTP id q12mr4594844ljc.142.1593288891943; Sat, 27 Jun 2020 13:14:51 -0700 (PDT) MIME-Version: 1.0 References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <353AF4E4-4939-4994-960E-54B0AADC6253@mit.edu> In-Reply-To: <353AF4E4-4939-4994-960E-54B0AADC6253@mit.edu> From: Dick Hardt Date: Sat, 27 Jun 2020 13:14:15 -0700 Message-ID: To: Justin Richer Cc: txauth@ietf.org, Denis Content-Type: multipart/alternative; boundary="0000000000006dcf0605a9167a80" Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 27 Jun 2020 20:14:57 -0000 --0000000000006dcf0605a9167a80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 to 'We shouldn=E2=80=99t let =E2=80=9COAuth 2 doesn=E2=80=99t do it that= way=E2=80=9D be the limiting factor here.' Conversely, I worry about scope creep if we are forced to complicate the protocol to cover use cases that are only theoretical. (I'm not implying that any of the use cases discussed in this thread are in that category). /Dick On Sat, Jun 27, 2020 at 12:56 PM Justin Richer wrote: > Removing the IESG as this is really a more internal-to-the-group > discussion, as it comes down to the scope of use cases that we want to > address here in GNAP. > > While it is definitely important to understand how and why OAuth 2 does > things, we do need to keep use cases like Denis=E2=80=99s in mind. It=E2= =80=99s not unheard > of today for a single OAuth 2 RS to accept tokens from multiple AS=E2=80= =99s. In > fact, we=E2=80=99ve even got cases with things like the Solid project whe= re the RS > will take a token from :any: AS so long as it can verify that it=E2=80=99= s approved > by the resource owner. While the Solid platform has its own special > layering in place to allow this, our model should not assume a closely-ti= ed > connection between an RS and any single AS. The question of :how: we solv= e > that is, of course, up to the WG to figure out over time. > > Taking that even further, I think the idea of an AS that=E2=80=99s person= al to the > user, to promote privacy and control, is a very good one. In fact, this i= s > one of the main selling points of UMA2 and its federated authorization > mechanisms. With GNAP, we might be able to deliver on this promise even > more than UMA has been able to, and it=E2=80=99s my hope that we can have= a > cohesive protocol that allows both user-to-self and user-to-another > delegation sharing without needing to use different mechanisms. > > Additionally, the RS-first method is also something from the UMA2 work > that we should be working on, as it touches on AS discovery, AS/RS > communication, and a few other aspects of the protocol design. It=E2=80= =99s not a > trivial problem by any stretch, and there are huge privacy and security > implications, but there=E2=80=99s both need for it and some good prior ar= t to pull > from. In fact, XYZ=E2=80=99s whole notion of a =E2=80=9Ctransaction handl= e=E2=80=9D is an > adaptation of UMA2=E2=80=99s =E2=80=9Cpermission ticket=E2=80=9D. In UMA,= this ticket is first > issued to the RS by the AS, and the RS then hands it to the client, which > starts the negotiation for access. I envision something very similar > happening here with GNAP, where a client can get something to bootstrap t= he > process at the AS. The important thing, to me, is that we don=E2=80=99t h= ave to > jump through a bunch of weird hoops such that the AS-first and RS-first > cases look completely different, as they do in UMA2 and OAuth 2 > respectively today. We=E2=80=99ve got the chance to have a clean and cohe= sive > protocol here, let=E2=80=99s not miss that opportunity. > > So in sum, the trust model of OAuth 2 is not sufficient to cover > everything, and the model that Denis is proposing is something we should = at > least look at as a use case. Where Denis and I seem to disagree is whethe= r > this trust model should be the :only: one that we address with the > protocol. I strongly believe, as I believe much of this group does, that = we > can=E2=80=99t discount or ignore (or make things overly difficult for) th= e tightly > bound AS/RS combos, or any type of static setup where the RS offloads its > trust fully to the AS. But it=E2=80=99s my belief that we should be able = to do so > without needlessly throwing out all of the OAuth 2 use cases. > > We shouldn=E2=80=99t let =E2=80=9COAuth 2 doesn=E2=80=99t do it that way= =E2=80=9D be the limiting factor > here. We need to understand the what and wherefore of things that OAuth 2 > is bad at, otherwise we=E2=80=99re just going to re-invent OAuth 2 and in= herit its > problems. > > =E2=80=94 Justin > > On Jun 26, 2020, at 1:39 PM, Dick Hardt wrote: > > Denis, thanks for sharing your thoughts, some clarifications on your > statements inserted: > > On Fri, Jun 26, 2020 at 9:42 AM Denis wrote: > > >> *New proposed charter* >> >> > >> >> Resource servers inform their clients about which access token formats >> are acceptable and depending upon the king of operation >> that is requested, which kind of attributes are needed and from which AS= s >> that my be obtained. >> >> While at times this may be appropriate, at other times disclosing the > attributes the RS requires is not needed by the client. For example, an > enterprise client accessing a resource does not need to know which groups= a > user belongs to, but the RS may require that to determine if the user > running the client has access.. > >> >> A major difference with OAuth 2.0 is that there is no bilateral trust >> relationship between an authorization server and a resource server: >> for a given category of attributes, a resource server may trust one or >> more authorization servers. Another major difference with OAuth 2.0. >> is that the content of an attributes token is meant to be accessible to >> the client. >> >> This is not how OAuth 2.0 works. See slides 7 and 8 from my original IET= F > presentation on what became OAuth 2.0 > > https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation > > The AS may not even know who the RS (or PR in the slides) is. > > > >> >> I got rid of the word "delegation": the client does not delegate anythin= g >> to an authorization server. If it would, this would mean that the >> authorization server >> would be able to act as the client and could know everything that the >> client will do, which comes into contradiction with the user's privacy. >> > > The above is not true. > > The Resource Owner is delegating access control to the AS in authorizatio= n > use cases. > > The client is may be delegating user authentication to the AS in identity > claim use cases. > > The AS can act as the client in many OAuth deployments, as the access > token is a bearer token. That does not mean the AS knows what the client = is > doing. > > /Dick > > =E1=90=A7 > -- > 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 > --0000000000006dcf0605a9167a80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to 'We shouldn=E2=80=99t let = =E2=80=9COAuth 2 doesn=E2=80=99t do it that way=E2=80=9D be the limiting fa= ctor here.'

Conversely, I worry about scop= e creep if we are forced to complicate the protocol to cover use cases that= are only theoretical. (I'm not implying that any of the use cases disc= ussed in this thread are in that category).

/Dick<= /div>
O= n Sat, Jun 27, 2020 at 12:56 PM Justin Richer <jricher@mit.edu> wrote:
Removing= the IESG as this is really a more internal-to-the-group discussion, as it = comes down to the scope of use cases that we want to address here in GNAP.<= div>
While it is definitely important to understand how and w= hy OAuth 2 does things, we do need to keep use cases like Denis=E2=80=99s i= n mind. It=E2=80=99s not unheard of today for a single OAuth 2 RS to accept= tokens from multiple AS=E2=80=99s. In fact, we=E2=80=99ve even got cases w= ith things like the Solid project where the RS will take a token from :any:= AS so long as it can verify that it=E2=80=99s approved by the resource own= er. While the Solid platform has its own special layering in place to allow= this, our model should not assume a closely-tied connection between an RS = and any single AS. The question of :how: we solve that is, of course, up to= the WG to figure out over time.

Taking that even = further, I think the idea of an AS that=E2=80=99s personal to the user, to = promote privacy and control, is a very good one. In fact, this is one of th= e main selling points of UMA2 and its federated authorization mechanisms. W= ith GNAP, we might be able to deliver on this promise even more than UMA ha= s been able to, and it=E2=80=99s my hope that we can have a cohesive protoc= ol that allows both user-to-self and user-to-another delegation sharing wit= hout needing to use different mechanisms.=C2=A0

Ad= ditionally, the RS-first method is also something from the UMA2 work that w= e should be working on, as it touches on AS discovery, AS/RS communication,= and a few other aspects of the protocol design. It=E2=80=99s not a trivial= problem by any stretch, and there are huge privacy and security implicatio= ns, but there=E2=80=99s both need for it and some good prior art to pull fr= om. In fact, XYZ=E2=80=99s whole notion of a =E2=80=9Ctransaction handle=E2= =80=9D is an adaptation of UMA2=E2=80=99s =E2=80=9Cpermission ticket=E2=80= =9D. In UMA, this ticket is first issued to the RS by the AS, and the RS th= en hands it to the client, which starts the negotiation for access. I envis= ion something very similar happening here with GNAP, where a client can get= something to bootstrap the process at the AS. The important thing, to me, = is that we don=E2=80=99t have to jump through a bunch of weird hoops such t= hat the AS-first and RS-first cases look completely different, as they do i= n UMA2 and OAuth 2 respectively today. We=E2=80=99ve got the chance to have= a clean and cohesive protocol here, let=E2=80=99s not miss that opportunit= y.

So in sum, the trust model of OAuth 2 is not su= fficient to cover everything, and the model that Denis is proposing is some= thing we should at least look at as a use case. Where Denis and I seem to d= isagree is whether this trust model should be the :only: one that we addres= s with the protocol. I strongly believe, as I believe much of this group do= es, that we can=E2=80=99t discount or ignore (or make things overly difficu= lt for) the tightly bound AS/RS combos, or any type of static setup where t= he RS offloads its trust fully to the AS. But it=E2=80=99s my belief that w= e should be able to do so without needlessly throwing out all of the OAuth = 2 use cases.

We shouldn=E2=80=99t let =E2=80=9COAu= th 2 doesn=E2=80=99t do it that way=E2=80=9D be the limiting factor here. W= e need to understand the what and wherefore of things that OAuth 2 is bad a= t, otherwise we=E2=80=99re just going to re-invent OAuth 2 and inherit its = problems.

=C2=A0=E2=80=94 Justin
On Jun 26, 2020, at 1:39 PM, Dick Hardt &l= t;dick.hardt@gmai= l.com> wrote:

Denis,= thanks for sharing your thoughts, some clarifications on your statements i= nserted:

On Fri, Jun 26, 2020 at 9:42 AM Denis <denis.ietf@free.fr> wrote:
<snip>

New propo= sed charter

<snip>=C2=A0
=

Resource servers inform their clients about which access token formats are acceptable and depending upon the king of operation
that is requested, which kind of attributes are needed and from which ASs that my be obtained.
While at times th= is may be appropriate, at other times disclosing the attributes the RS requ= ires is not needed by the client. For example, an enterprise client accessi= ng a resource does not need to know which groups a user belongs to, but the= RS may require that to determine if the user running the client has access= ..

A major difference with OAuth 2.0 is that there is no bilateral trust relationship between an authorization server and a resource server:
for a given category of attributes, a resource server may trust one or more authorization servers. Another major difference with OAuth 2.0.
is that the content of an attributes token is meant to be accessible to the client.
This is not how OAuth 2.0 works. See slides 7 and 8 from= my original IETF presentation on what became OAuth 2.0


The AS may not even = know who the RS (or PR in the slides) is.

<snip= >=C2=A0


I got rid of the word "delegation": the client does n= ot delegate anything to an authorization server. If it would, this would mean that the authorization server
would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy.


The=C2=A0above is not true.
=C2=A0
The Resource Owner is delegating access control to the AS in authori= zation use cases.

The client is may be delegating = user authentication to the AS in identity claim use cases.

The AS can act as the client in many OAuth deployments, as the acc= ess token is a bearer token. That does not mean the AS knows what the clien= t is doing.=C2=A0

/Dick
=C2=A0
3D==E1=90=A7
--
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
--0000000000006dcf0605a9167a80-- From nobody Sat Jun 27 13:45:19 2020 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 2AAD83A0795 for ; Sat, 27 Jun 2020 13:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 ndc3ini-ZqHX for ; Sat, 27 Jun 2020 13:45:15 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 A902C3A0778 for ; Sat, 27 Jun 2020 13:45:15 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id 18so11899574otv.6 for ; Sat, 27 Jun 2020 13:45:15 -0700 (PDT) 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=UcJQvoMr9muj3LyO9viNQSUrEs0M58hclN/TLYj1ZwI=; b=VXQQCePReMgR+vGoeK6skE/1+I7kdyDsrYU53DFaYwq4WdQFYQizIGUmMzh2UPEVDu sIele0uaLBnqWzZbddtCddR9hUruWt/w9Ef+CUoXwOA7F5MoONYSc1D+f4VJ93Ci58QU 5Eg1U8UJuj96JF13EO4ArwmLLWrAT0vjMH4Q7c+Ei2xye0jsongcb4w016sT5rFTPi6c 0NY9qoH+aqKwEiDocCG0e4+PkyOFccwE4/xFar35ZnXctITDt6naMeAmFKgFvtua3zUc gHM44jHN2NnzRcv4l3VoRwsrWtgYtoxTggzzXM6aIBQWQesvEw5crjc6K1rktrq+JwMe F/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=UcJQvoMr9muj3LyO9viNQSUrEs0M58hclN/TLYj1ZwI=; b=DaH4rnV4VAllKsykXSQXE3TbqjK0N5g7JJaVJMYswR2TtLSAVkQCaocnJoYgRK4PMv QmP9YRIZj1ghxZhMpnWZOT3BajlGARQu6p5RCiMYU117NWymANr9+3dk+bEAWjmYx+By NoeKsE6uoyMcXwGAuRwTGim0961GL8QPD9pu5uEAzE1ZSxtA7kB+fneFQEQ/PEixEsQg wqC09knioiJZDSU1QiMHpacwhkslxNJzVdJuBtVPzBH5Aokrl/3BKkfZpwpFoTlb1Qc6 M6NuZSoDaM1pCGgjLJKWptKtWMalhZW2YJzgWXHtDvy7XE1xMjG4zsJtbb19srS2kvxE 7btQ== X-Gm-Message-State: AOAM531RlL95Xma8N1dlByYYEyYCTt1Obv8aSstOczvPYRID+KAXXPLk 5uEH2J0CZ4aYKiLEV26JA+OiPFmvsKeZLnRIwH4= X-Google-Smtp-Source: ABdhPJxtKVGVUL7YIOuSwOpOmFGoMF0m3kq4uWM9Z0pV/pu/p6LPlo+x4SKkvp2pZjwLGZYfTlw9PwQrTWJ7DO39W7I= X-Received: by 2002:a05:6830:4cd:: with SMTP id s13mr1922690otd.358.1593290714936; Sat, 27 Jun 2020 13:45:14 -0700 (PDT) MIME-Version: 1.0 References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <353AF4E4-4939-4994-960E-54B0AADC6253@mit.edu> In-Reply-To: From: Tom Jones Date: Sat, 27 Jun 2020 13:45:03 -0700 Message-ID: To: Dick Hardt Cc: Justin Richer , Denis , txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000016790a05a916e76b" Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 27 Jun 2020 20:45:18 -0000 --00000000000016790a05a916e76b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 - Right on Justin. Peace ..tom On Sat, Jun 27, 2020 at 1:15 PM Dick Hardt wrote: > +1 to 'We shouldn=E2=80=99t let =E2=80=9COAuth 2 doesn=E2=80=99t do it th= at way=E2=80=9D be the limiting > factor here.' > > Conversely, I worry about scope creep if we are forced to complicate the > protocol to cover use cases that are only theoretical. (I'm not implying > that any of the use cases discussed in this thread are in that category). > > /Dick > > On Sat, Jun 27, 2020 at 12:56 PM Justin Richer wrote: > >> Removing the IESG as this is really a more internal-to-the-group >> discussion, as it comes down to the scope of use cases that we want to >> address here in GNAP. >> >> While it is definitely important to understand how and why OAuth 2 does >> things, we do need to keep use cases like Denis=E2=80=99s in mind. It=E2= =80=99s not unheard >> of today for a single OAuth 2 RS to accept tokens from multiple AS=E2=80= =99s. In >> fact, we=E2=80=99ve even got cases with things like the Solid project wh= ere the RS >> will take a token from :any: AS so long as it can verify that it=E2=80= =99s approved >> by the resource owner. While the Solid platform has its own special >> layering in place to allow this, our model should not assume a closely-t= ied >> connection between an RS and any single AS. The question of :how: we sol= ve >> that is, of course, up to the WG to figure out over time. >> >> Taking that even further, I think the idea of an AS that=E2=80=99s perso= nal to >> the user, to promote privacy and control, is a very good one. In fact, t= his >> is one of the main selling points of UMA2 and its federated authorizatio= n >> mechanisms. With GNAP, we might be able to deliver on this promise even >> more than UMA has been able to, and it=E2=80=99s my hope that we can hav= e a >> cohesive protocol that allows both user-to-self and user-to-another >> delegation sharing without needing to use different mechanisms. >> >> Additionally, the RS-first method is also something from the UMA2 work >> that we should be working on, as it touches on AS discovery, AS/RS >> communication, and a few other aspects of the protocol design. It=E2=80= =99s not a >> trivial problem by any stretch, and there are huge privacy and security >> implications, but there=E2=80=99s both need for it and some good prior a= rt to pull >> from. In fact, XYZ=E2=80=99s whole notion of a =E2=80=9Ctransaction hand= le=E2=80=9D is an >> adaptation of UMA2=E2=80=99s =E2=80=9Cpermission ticket=E2=80=9D. In UMA= , this ticket is first >> issued to the RS by the AS, and the RS then hands it to the client, whic= h >> starts the negotiation for access. I envision something very similar >> happening here with GNAP, where a client can get something to bootstrap = the >> process at the AS. The important thing, to me, is that we don=E2=80=99t = have to >> jump through a bunch of weird hoops such that the AS-first and RS-first >> cases look completely different, as they do in UMA2 and OAuth 2 >> respectively today. We=E2=80=99ve got the chance to have a clean and coh= esive >> protocol here, let=E2=80=99s not miss that opportunity. >> >> So in sum, the trust model of OAuth 2 is not sufficient to cover >> everything, and the model that Denis is proposing is something we should= at >> least look at as a use case. Where Denis and I seem to disagree is wheth= er >> this trust model should be the :only: one that we address with the >> protocol. I strongly believe, as I believe much of this group does, that= we >> can=E2=80=99t discount or ignore (or make things overly difficult for) t= he tightly >> bound AS/RS combos, or any type of static setup where the RS offloads it= s >> trust fully to the AS. But it=E2=80=99s my belief that we should be able= to do so >> without needlessly throwing out all of the OAuth 2 use cases. >> >> We shouldn=E2=80=99t let =E2=80=9COAuth 2 doesn=E2=80=99t do it that way= =E2=80=9D be the limiting factor >> here. We need to understand the what and wherefore of things that OAuth = 2 >> is bad at, otherwise we=E2=80=99re just going to re-invent OAuth 2 and i= nherit its >> problems. >> >> =E2=80=94 Justin >> >> On Jun 26, 2020, at 1:39 PM, Dick Hardt wrote: >> >> Denis, thanks for sharing your thoughts, some clarifications on your >> statements inserted: >> >> On Fri, Jun 26, 2020 at 9:42 AM Denis wrote: >> >> >>> *New proposed charter* >>> >>> >> >>> >>> Resource servers inform their clients about which access token formats >>> are acceptable and depending upon the king of operation >>> that is requested, which kind of attributes are needed and from which >>> ASs that my be obtained. >>> >>> While at times this may be appropriate, at other times disclosing the >> attributes the RS requires is not needed by the client. For example, an >> enterprise client accessing a resource does not need to know which group= s a >> user belongs to, but the RS may require that to determine if the user >> running the client has access... >> >>> >>> A major difference with OAuth 2.0 is that there is no bilateral trust >>> relationship between an authorization server and a resource server: >>> for a given category of attributes, a resource server may trust one or >>> more authorization servers. Another major difference with OAuth 2.0. >>> is that the content of an attributes token is meant to be accessible to >>> the client. >>> >>> This is not how OAuth 2.0 works. See slides 7 and 8 from my original >> IETF presentation on what became OAuth 2.0 >> >> https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation >> >> The AS may not even know who the RS (or PR in the slides) is. >> >> >> >>> >>> I got rid of the word "delegation": the client does not delegate >>> anything to an authorization server. If it would, this would mean that = the >>> authorization server >>> would be able to act as the client and could know everything that the >>> client will do, which comes into contradiction with the user's privacy. >>> >> >> The above is not true. >> >> The Resource Owner is delegating access control to the AS in >> authorization use cases. >> >> The client is may be delegating user authentication to the AS in identit= y >> claim use cases. >> >> The AS can act as the client in many OAuth deployments, as the access >> token is a bearer token. That does not mean the AS knows what the client= is >> doing. >> >> /Dick >> >> =E1=90=A7 >> -- >> 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 > --00000000000016790a05a916e76b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 - Right on Justin.
Peace ..tom


On Sat, Jun 27, 2020 at 1= :15 PM Dick Hardt <dick.hardt@gm= ail.com> wrote:
+1 to 'We shouldn=E2=80= =99t let =E2=80=9COAuth 2 doesn=E2=80=99t do it that way=E2=80=9D be the li= miting factor here.'

Conversely, I worry a= bout scope creep if we are forced to complicate the protocol to cover use c= ases that are only theoretical. (I'm not implying that any of the use c= ases discussed in this thread are in that category).

/Dick

On Sat, Jun 27, 2020 at 12:56 PM Justin Richer <jricher@mit.edu> wrote:
Removing the IESG = as this is really a more internal-to-the-group discussion, as it comes down= to the scope of use cases that we want to address here in GNAP.

While it is definitely important to understand how and why OAuth 2= does things, we do need to keep use cases like Denis=E2=80=99s in mind. It= =E2=80=99s not unheard of today for a single OAuth 2 RS to accept tokens fr= om multiple AS=E2=80=99s. In fact, we=E2=80=99ve even got cases with things= like the Solid project where the RS will take a token from :any: AS so lon= g as it can verify that it=E2=80=99s approved by the resource owner. While = the Solid platform has its own special layering in place to allow this, our= model should not assume a closely-tied connection between an RS and any si= ngle AS. The question of :how: we solve that is, of course, up to the WG to= figure out over time.

Taking that even further, I= think the idea of an AS that=E2=80=99s personal to the user, to promote pr= ivacy and control, is a very good one. In fact, this is one of the main sel= ling points of UMA2 and its federated authorization mechanisms. With GNAP, = we might be able to deliver on this promise even more than UMA has been abl= e to, and it=E2=80=99s my hope that we can have a cohesive protocol that al= lows both user-to-self and user-to-another delegation sharing without needi= ng to use different mechanisms.=C2=A0

Additionally= , the RS-first method is also something from the UMA2 work that we should b= e working on, as it touches on AS discovery, AS/RS communication, and a few= other aspects of the protocol design. It=E2=80=99s not a trivial problem b= y any stretch, and there are huge privacy and security implications, but th= ere=E2=80=99s both need for it and some good prior art to pull from. In fac= t, XYZ=E2=80=99s whole notion of a =E2=80=9Ctransaction handle=E2=80=9D is = an adaptation of UMA2=E2=80=99s =E2=80=9Cpermission ticket=E2=80=9D. In UMA= , this ticket is first issued to the RS by the AS, and the RS then hands it= to the client, which starts the negotiation for access. I envision somethi= ng very similar happening here with GNAP, where a client can get something = to bootstrap the process at the AS. The important thing, to me, is that we = don=E2=80=99t have to jump through a bunch of weird hoops such that the AS-= first and RS-first cases look completely different, as they do in UMA2 and = OAuth 2 respectively today. We=E2=80=99ve got the chance to have a clean an= d cohesive protocol here, let=E2=80=99s not miss that opportunity.

So in sum, the trust model of OAuth 2 is not sufficient to= cover everything, and the model that Denis is proposing is something we sh= ould at least look at as a use case. Where Denis and I seem to disagree is = whether this trust model should be the :only: one that we address with the = protocol. I strongly believe, as I believe much of this group does, that we= can=E2=80=99t discount or ignore (or make things overly difficult for) the= tightly bound AS/RS combos, or any type of static setup where the RS offlo= ads its trust fully to the AS. But it=E2=80=99s my belief that we should be= able to do so without needlessly throwing out all of the OAuth 2 use cases= .

We shouldn=E2=80=99t let =E2=80=9COAuth 2 doesn= =E2=80=99t do it that way=E2=80=9D be the limiting factor here. We need to = understand the what and wherefore of things that OAuth 2 is bad at, otherwi= se we=E2=80=99re just going to re-invent OAuth 2 and inherit its problems.<= /div>

=C2=A0=E2=80=94 Justin

On Jun 26, 2020, at 1:39 PM, Dick Hardt <dick.hardt@gmail.com= > wrote:

Denis, thanks f= or sharing your thoughts, some clarifications on your statements inserted:<= /div>
O= n Fri, Jun 26, 2020 at 9:42 AM Denis <denis.ietf@free.fr> wrote:
<snip>

New propo= sed charter

<snip>=C2=A0
=

Resource servers inform their clients about which access token formats are acceptable and depending upon the king of operation
that is requested, which kind of attributes are needed and from which ASs that my be obtained.
While at times th= is may be appropriate, at other times disclosing the attributes the RS requ= ires is not needed by the client. For example, an enterprise client accessi= ng a resource does not need to know which groups a user belongs to, but the= RS may require that to determine if the user running the client has access= ...

A major difference with OAuth 2.0 is that there is no bilateral trust relationship between an authorization server and a resource server:
for a given category of attributes, a resource server may trust one or more authorization servers. Another major difference with OAuth 2.0.
is that the content of an attributes token is meant to be accessible to the client.
This is not how OAuth 2.0 works. See slides 7 and 8 from= my original IETF presentation on what became OAuth 2.0


The AS may not even = know who the RS (or PR in the slides) is.

<snip= >=C2=A0


I got rid of the word "delegation": the client does n= ot delegate anything to an authorization server. If it would, this would mean that the authorization server
would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy.


The=C2=A0above is not true.
=C2=A0
The Resource Owner is delegating access control to the AS in authori= zation use cases.

The client is may be delegating = user authentication to the AS in identity claim use cases.

The AS can act as the client in many OAuth deployments, as the acc= ess token is a bearer token. That does not mean the AS knows what the clien= t is doing.=C2=A0

/Dick
=C2=A0
3D==E1=90=A7
--
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
--00000000000016790a05a916e76b-- From nobody Sun Jun 28 10:50:30 2020 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 68CBE3A0E2A for ; Sun, 28 Jun 2020 10:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 XPRuuXFlTKHP for ; Sun, 28 Jun 2020 10:50:27 -0700 (PDT) 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 ABD863A0D67 for ; Sun, 28 Jun 2020 10:50:26 -0700 (PDT) Received: from [192.168.1.14] (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 05SHoL9F014808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Jun 2020 13:50:22 -0400 From: Justin Richer Message-Id: <6A9D6B5D-EA90-4DB4-84A5-8C5AE9AF051B@mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_BAC06676-44A7-44A7-A779-DA9805C83ACD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 28 Jun 2020 13:50:21 -0400 In-Reply-To: Cc: Dick Hardt , Denis , txauth@ietf.org To: Tom Jones References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <353AF4E4-4939-4994-960E-54B0AADC6253@mit.edu> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 28 Jun 2020 17:50:29 -0000 --Apple-Mail=_BAC06676-44A7-44A7-A779-DA9805C83ACD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m also worried about feature creep, but it=E2=80=99s something = that the group can guard against in very practical ways. It=E2=80=99s = dangerous to dismiss someone else=E2=80=99s work as =E2=80=9Conly = theoretical=E2=80=9D, especially because GNAP is going to draw from a = different sent of circumstances that are going to be outside the = experience of the core OAuth community, and that=E2=80=99s a really good = thing.=20 But I believe that we can apply a set of sensible criteria to things: - Is there an implementation (even a proof of concept)? Running code = makes bad assumptions come out in sharp relief, and we need to test = these assumptions constantly. But also keep in mind that running code = can be changed. - Is there an existing, perhaps more convoluted, solution out there? = Pulling disparate systems under a common structure should be a way of = working here. But this only works if it can come =E2=80=9Cin common=E2=80=9D= and we aren=E2=80=99t stretching the abstractions so much that = they=E2=80=99re meaningless. - Does it fit in the GNAP model along with other work? This might mean = we have to adjust the model, but such adjustments shouldn=E2=80=99t be = at the expense of all other use cases. Sometimes, things don=E2=80=99t = fit, and that=E2=80=99s ok. Cohesiveness of the GNAP solution will come from applying good = engineering and questioning assumptions about our existing and proposed = solutions. It=E2=80=99s important that we know the :why: of things and = not just the :what:. The last thing I think we want is a protocol that = is actually a bunch of completely different protocols with switched = behavior. This is one of the biggest complaints that I see about OAuth = 2=E2=80=99s =E2=80=9Cframework=E2=80=9D approach and I think we have an = opportunity to do much better here if we get the model right. That=E2=80=99= s going to take time and effort, but I believe it=E2=80=99s possible, = and I look forward to building that with everyone here. Right now, our best focus is going to be use cases =E2=80=94 what do = people want to :do: with GNAP =E2=80=94 and what those use cases say = about our model and assumptions going in to the solution space. There = are a number of valuable points in both Tom and Denis=E2=80=99s = discussion below. Some of it fits, some of it doesn=E2=80=99t. Some of = it might be better for an extension. Some of it might be counter to what = we=E2=80=99re after.=20 Discussing all of that is why we=E2=80=99re all in a standards working = group and not just building a commercial product. =E2=80=94 Justin > On Jun 27, 2020, at 4:45 PM, Tom Jones = wrote: >=20 > +1 - Right on Justin. > Peace ..tom >=20 >=20 > On Sat, Jun 27, 2020 at 1:15 PM Dick Hardt > wrote: > +1 to 'We shouldn=E2=80=99t let =E2=80=9COAuth 2 doesn=E2=80=99t do it = that way=E2=80=9D be the limiting factor here.' >=20 > Conversely, I worry about scope creep if we are forced to complicate = the protocol to cover use cases that are only theoretical. (I'm not = implying that any of the use cases discussed in this thread are in that = category). >=20 > /Dick >=20 > On Sat, Jun 27, 2020 at 12:56 PM Justin Richer > wrote: > Removing the IESG as this is really a more internal-to-the-group = discussion, as it comes down to the scope of use cases that we want to = address here in GNAP. >=20 > While it is definitely important to understand how and why OAuth 2 = does things, we do need to keep use cases like Denis=E2=80=99s in mind. = It=E2=80=99s not unheard of today for a single OAuth 2 RS to accept = tokens from multiple AS=E2=80=99s. In fact, we=E2=80=99ve even got cases = with things like the Solid project where the RS will take a token from = :any: AS so long as it can verify that it=E2=80=99s approved by the = resource owner. While the Solid platform has its own special layering in = place to allow this, our model should not assume a closely-tied = connection between an RS and any single AS. The question of :how: we = solve that is, of course, up to the WG to figure out over time. >=20 > Taking that even further, I think the idea of an AS that=E2=80=99s = personal to the user, to promote privacy and control, is a very good = one. In fact, this is one of the main selling points of UMA2 and its = federated authorization mechanisms. With GNAP, we might be able to = deliver on this promise even more than UMA has been able to, and it=E2=80=99= s my hope that we can have a cohesive protocol that allows both = user-to-self and user-to-another delegation sharing without needing to = use different mechanisms.=20 >=20 > Additionally, the RS-first method is also something from the UMA2 work = that we should be working on, as it touches on AS discovery, AS/RS = communication, and a few other aspects of the protocol design. It=E2=80=99= s not a trivial problem by any stretch, and there are huge privacy and = security implications, but there=E2=80=99s both need for it and some = good prior art to pull from. In fact, XYZ=E2=80=99s whole notion of a = =E2=80=9Ctransaction handle=E2=80=9D is an adaptation of UMA2=E2=80=99s = =E2=80=9Cpermission ticket=E2=80=9D. In UMA, this ticket is first issued = to the RS by the AS, and the RS then hands it to the client, which = starts the negotiation for access. I envision something very similar = happening here with GNAP, where a client can get something to bootstrap = the process at the AS. The important thing, to me, is that we don=E2=80=99= t have to jump through a bunch of weird hoops such that the AS-first and = RS-first cases look completely different, as they do in UMA2 and OAuth 2 = respectively today. We=E2=80=99ve got the chance to have a clean and = cohesive protocol here, let=E2=80=99s not miss that opportunity. >=20 > So in sum, the trust model of OAuth 2 is not sufficient to cover = everything, and the model that Denis is proposing is something we should = at least look at as a use case. Where Denis and I seem to disagree is = whether this trust model should be the :only: one that we address with = the protocol. I strongly believe, as I believe much of this group does, = that we can=E2=80=99t discount or ignore (or make things overly = difficult for) the tightly bound AS/RS combos, or any type of static = setup where the RS offloads its trust fully to the AS. But it=E2=80=99s = my belief that we should be able to do so without needlessly throwing = out all of the OAuth 2 use cases. >=20 > We shouldn=E2=80=99t let =E2=80=9COAuth 2 doesn=E2=80=99t do it that = way=E2=80=9D be the limiting factor here. We need to understand the what = and wherefore of things that OAuth 2 is bad at, otherwise we=E2=80=99re = just going to re-invent OAuth 2 and inherit its problems. >=20 > =E2=80=94 Justin >=20 >> On Jun 26, 2020, at 1:39 PM, Dick Hardt > wrote: >>=20 >> Denis, thanks for sharing your thoughts, some clarifications on your = statements inserted: >>=20 >> On Fri, Jun 26, 2020 at 9:42 AM Denis > wrote: >> >> New proposed charter >>=20 >> =20 >>=20 >> Resource servers inform their clients about which access token = formats are acceptable and depending upon the king of operation >> that is requested, which kind of attributes are needed and from which = ASs that my be obtained. >>=20 >> While at times this may be appropriate, at other times disclosing the = attributes the RS requires is not needed by the client. For example, an = enterprise client accessing a resource does not need to know which = groups a user belongs to, but the RS may require that to determine if = the user running the client has access... >>=20 >> A major difference with OAuth 2.0 is that there is no bilateral trust = relationship between an authorization server and a resource server:=20 >> for a given category of attributes, a resource server may trust one = or more authorization servers. Another major difference with OAuth 2.0. >> is that the content of an attributes token is meant to be accessible = to the client. >> This is not how OAuth 2.0 works. See slides 7 and 8 from my original = IETF presentation on what became OAuth 2.0 >>=20 >> https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation = >>=20 >> The AS may not even know who the RS (or PR in the slides) is. >>=20 >> =20 >>=20 >> I got rid of the word "delegation": the client does not delegate = anything to an authorization server. If it would, this would mean that = the authorization server=20 >> would be able to act as the client and could know everything that the = client will do, which comes into contradiction with the user's privacy. >>=20 >>=20 >> The above is not true. >> =20 >> The Resource Owner is delegating access control to the AS in = authorization use cases. >>=20 >> The client is may be delegating user authentication to the AS in = identity claim use cases. >>=20 >> The AS can act as the client in many OAuth deployments, as the access = token is a bearer token. That does not mean the AS knows what the client = is doing.=20 >>=20 >> /Dick >> =20 >> =E1=90=A7 >> --=20 >> Txauth mailing list >> Txauth@ietf.org >> https://www.ietf.org/mailman/listinfo/txauth = >=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=_BAC06676-44A7-44A7-A779-DA9805C83ACD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m also worried about feature creep, but it=E2=80=99s something that = the group can guard against in very practical ways. It=E2=80=99s = dangerous to dismiss someone else=E2=80=99s work as =E2=80=9Conly = theoretical=E2=80=9D, especially because GNAP is going to draw from a = different sent of circumstances that are going to be outside the = experience of the core OAuth community, and that=E2=80=99s a really good = thing. 

But I = believe that we can apply a set of sensible criteria to = things:

 - = Is there an implementation (even a proof of concept)? Running code makes = bad assumptions come out in sharp relief, and we need to test these = assumptions constantly. But also keep in mind that running code can be = changed.
 - Is there an existing, perhaps more = convoluted, solution out there? Pulling disparate systems under a common = structure should be a way of working here. But this only works if it can = come =E2=80=9Cin common=E2=80=9D and we aren=E2=80=99t stretching the = abstractions so much that they=E2=80=99re meaningless.
 - Does it fit in the GNAP model along with other work? = This might mean we have to adjust the model, but such adjustments = shouldn=E2=80=99t be at the expense of all other use cases. Sometimes, = things don=E2=80=99t fit, and that=E2=80=99s ok.

Cohesiveness of the GNAP solution will = come from applying good engineering and questioning assumptions about = our existing and proposed solutions. It=E2=80=99s important that we know = the :why: of things and not just the :what:. The last thing I think we = want is a protocol that is actually a bunch of completely different = protocols with switched behavior. This is one of the biggest complaints = that I see about OAuth 2=E2=80=99s =E2=80=9Cframework=E2=80=9D approach = and I think we have an opportunity to do much better here if= we get the model right. That=E2=80=99s going to take time and = effort, but I believe it=E2=80=99s possible, and I look forward to = building that with everyone here.

Right now, our best focus is going to = be use cases =E2=80=94 what do people want to :do: with GNAP =E2=80=94 = and what those use cases say about our model and assumptions going in to = the solution space. There are a number of valuable points in both Tom = and Denis=E2=80=99s discussion below. Some of it fits, some of it = doesn=E2=80=99t. Some of it might be better for an extension. Some of it = might be counter to what we=E2=80=99re after. 

Discussing all of that = is why we=E2=80=99re all in a standards working group and not just = building a commercial product.

 =E2=80=94 Justin

On Jun 27, 2020, at 4:45 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

+1 - Right on Justin.
Peace = ..tom


On Sat, Jun = 27, 2020 at 1:15 PM Dick Hardt <dick.hardt@gmail.com> wrote:
+1 to 'We shouldn=E2=80=99t let = =E2=80=9COAuth 2 doesn=E2=80=99t do it that way=E2=80=9D be the limiting = factor here.'

Conversely, I worry about scope creep = if we are forced to complicate the protocol to cover use cases that are = only theoretical. (I'm not implying that any of the use cases discussed = in this thread are in that category).

/Dick

On Sat, Jun = 27, 2020 at 12:56 PM Justin Richer <jricher@mit.edu> wrote:
Removing the IESG as = this is really a more internal-to-the-group discussion, as it comes down = to the scope of use cases that we want to address here in GNAP.

While it is definitely = important to understand how and why OAuth 2 does things, we do need to = keep use cases like Denis=E2=80=99s in mind. It=E2=80=99s not unheard of = today for a single OAuth 2 RS to accept tokens from multiple AS=E2=80=99s.= In fact, we=E2=80=99ve even got cases with things like the Solid = project where the RS will take a token from :any: AS so long as it can = verify that it=E2=80=99s approved by the resource owner. While the Solid = platform has its own special layering in place to allow this, our model = should not assume a closely-tied connection between an RS and any single = AS. The question of :how: we solve that is, of course, up to the WG to = figure out over time.

Taking that even further, I think the idea of an AS that=E2=80=99= s personal to the user, to promote privacy and control, is a very good = one. In fact, this is one of the main selling points of UMA2 and its = federated authorization mechanisms. With GNAP, we might be able to = deliver on this promise even more than UMA has been able to, and it=E2=80=99= s my hope that we can have a cohesive protocol that allows both = user-to-self and user-to-another delegation sharing without needing to = use different mechanisms. 

Additionally, the RS-first method is = also something from the UMA2 work that we should be working on, as it = touches on AS discovery, AS/RS communication, and a few other aspects of = the protocol design. It=E2=80=99s not a trivial problem by any stretch, = and there are huge privacy and security implications, but there=E2=80=99s = both need for it and some good prior art to pull from. In fact, XYZ=E2=80=99= s whole notion of a =E2=80=9Ctransaction handle=E2=80=9D is an = adaptation of UMA2=E2=80=99s =E2=80=9Cpermission ticket=E2=80=9D. In = UMA, this ticket is first issued to the RS by the AS, and the RS then = hands it to the client, which starts the negotiation for access. I = envision something very similar happening here with GNAP, where a client = can get something to bootstrap the process at the AS. The important = thing, to me, is that we don=E2=80=99t have to jump through a bunch of = weird hoops such that the AS-first and RS-first cases look completely = different, as they do in UMA2 and OAuth 2 respectively today. We=E2=80=99v= e got the chance to have a clean and cohesive protocol here, let=E2=80=99s= not miss that opportunity.

So in sum, the trust model of OAuth 2 is not sufficient to = cover everything, and the model that Denis is proposing is something we = should at least look at as a use case. Where Denis and I seem to = disagree is whether this trust model should be the :only: one that we = address with the protocol. I strongly believe, as I believe much of this = group does, that we can=E2=80=99t discount or ignore (or make things = overly difficult for) the tightly bound AS/RS combos, or any type of = static setup where the RS offloads its trust fully to the AS. But it=E2=80= =99s my belief that we should be able to do so without needlessly = throwing out all of the OAuth 2 use cases.

We shouldn=E2=80=99t let =E2=80=9COAuth = 2 doesn=E2=80=99t do it that way=E2=80=9D be the limiting factor here. = We need to understand the what and wherefore of things that OAuth 2 is = bad at, otherwise we=E2=80=99re just going to re-invent OAuth 2 and = inherit its problems.

 =E2=80=94 Justin
On Jun = 26, 2020, at 1:39 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Denis, = thanks for sharing your thoughts, some clarifications on your statements = inserted:

On Fri, Jun 26, 2020 at 9:42 AM Denis <denis.ietf@free.fr> wrote:
<snip>

New proposed = charter

<snip> 

Resource servers inform their clients about which access token formats are acceptable and depending upon the king of operation
that is requested, which kind of attributes are needed and from which ASs that my be = obtained.

While at times this may be appropriate, at other times = disclosing the attributes the RS requires is not needed by the client. = For example, an enterprise client accessing a resource does not need to = know which groups a user belongs to, but the RS may require that to = determine if the user running the client has access...

A major difference with OAuth 2.0 is that there is no bilateral trust relationship between an authorization server and a resource server:
for a given category of attributes, a resource server may trust one or more authorization servers. Another major difference with OAuth 2.0.
is that the content of an attributes token is meant to be accessible to the = client.
This is not how OAuth 2.0 works. See slides 7 and 8 from my = original IETF presentation on what became OAuth 2.0

https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presen= tation

The = AS may not even know who the RS (or PR in the slides) is.

<snip> 


I got rid of the word "delegation": the client does not delegate anything to an authorization server. If it would, this would mean that the authorization server
would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy.


The above is not true.
 
The Resource Owner is delegating = access control to the AS in authorization use cases.

The client is may be = delegating user authentication to the AS in identity claim use = cases.

The AS = can act as the client in many OAuth deployments, as the access token is = a bearer token. That does not mean the AS knows what the client is = doing. 

/Dick
 
3D""=E1=90=A7
--
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
=
= --Apple-Mail=_BAC06676-44A7-44A7-A779-DA9805C83ACD-- From nobody Sun Jun 28 19:33:00 2020 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 EB66C3A00C9 for ; Sun, 28 Jun 2020 19:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, 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 vSCXpDLYPagd for ; Sun, 28 Jun 2020 19:32:57 -0700 (PDT) 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 0FB4B3A00C4 for ; Sun, 28 Jun 2020 19:32:57 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id 9so16283736ljc.8 for ; Sun, 28 Jun 2020 19:32:56 -0700 (PDT) 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=odPHMvqmuX65ci95sUsG69TwIdfIYigtt1qV5wz9gzk=; b=UtUTcnsRbRgY2hkpCbFdyVGx/sbFD2buVIej/V4H6HUAOv8dqoBR2yOqceRNl8hRgO 91F10ZDHUEDXjjqtoiT6cvt/SdHbXSJq+nG3vKA6cA+XiZ63BQuiPXz2Hx5rBXZAdN5i DJ+QsBlpOqIXPa/sgLKjkTKWhsYX/qzhlVoJ/0+btmOCYYy1d0hjezhKJumQtHj562ZN TbLW/0m37evLSEgYqcGwIvcTk0mKQy3J+MQ/qCzpiObUIUQ6HBTgatxHltPwaSkkQHKK FEPKS7Q0ZU1Hy/C7Ry6gBxfjlwDLEfdUk8zOhbAxR8tLaA8DpXx6lJS98ggLfKTVaBLy zy+Q== 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=odPHMvqmuX65ci95sUsG69TwIdfIYigtt1qV5wz9gzk=; b=gAR6ann0epkndp5ibMwIUIATJ0YLDx/HBqwXzwTUWuyoYoyReS+ZMVIxJgUFz0qelr yul+dQH5GaUHn3pf/ooZ68OTo0kt74pVO62wSiAbo4bhl9Kp9dVMmpitzmiDRiBunwCT vld2GpXV8//+HhNyytTeesfvNRv3ABGoxvcariBUwHUG0ZgYaw11JPigemuJM7RvBw58 5wAPeO9xodFWS9deUAB0TS+KPIkgyelQPY2f3x3ilfWJDT/Mq3+l6YthdSIX1VAW18zW HtWbJ2ms/t+FK3IUAPF0WHCK7LEbgGNRbT96Lj2s8nDCn0/wJFRsUULTG9PR6XyCIbvw n/5Q== X-Gm-Message-State: AOAM5324aHh2fqvt94aAthauRXXTADGKyPYjWfZJDF3sn8vNlb5jw8it n7dSK2uERuu5yz63qaD9WPtOBmzjQdVFD2D9WcI= X-Google-Smtp-Source: ABdhPJwWiUrqkw6NjvIgMpCkAgQShec1GkC6VExGx5zqZNscetquM43JIkxkUJ5NSno8MdimQvTZ4NNgJDaxLu9Y/DI= X-Received: by 2002:a2e:7f10:: with SMTP id a16mr7196862ljd.69.1593397974917; Sun, 28 Jun 2020 19:32:54 -0700 (PDT) MIME-Version: 1.0 References: <159318778098.29096.6482921706088845432@ietfa.amsl.com> <353AF4E4-4939-4994-960E-54B0AADC6253@mit.edu> <6A9D6B5D-EA90-4DB4-84A5-8C5AE9AF051B@mit.edu> In-Reply-To: <6A9D6B5D-EA90-4DB4-84A5-8C5AE9AF051B@mit.edu> From: Dick Hardt Date: Sun, 28 Jun 2020 19:32:18 -0700 Message-ID: To: Justin Richer Cc: Tom Jones , Denis , txauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000047e7a305a92fe0cb" Archived-At: Subject: Re: [Txauth] WG Review: Grant Negotiation and Authorization Protocol (gnap) 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, 29 Jun 2020 02:33:00 -0000 --00000000000047e7a305a92fe0cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In case it was not clear from my email, I was not dismissing anybody's work as "theoretical". On Sun, Jun 28, 2020 at 10:50 AM Justin Richer wrote: > I=E2=80=99m also worried about feature creep, but it=E2=80=99s something = that the group > can guard against in very practical ways. It=E2=80=99s dangerous to dismi= ss someone > else=E2=80=99s work as =E2=80=9Conly theoretical=E2=80=9D, especially bec= ause GNAP is going to draw > from a different sent of circumstances that are going to be outside the > experience of the core OAuth community, and that=E2=80=99s a really good = thing. > > But I believe that we can apply a set of sensible criteria to things: > > - Is there an implementation (even a proof of concept)? Running code > makes bad assumptions come out in sharp relief, and we need to test these > assumptions constantly. But also keep in mind that running code can be > changed. > - Is there an existing, perhaps more convoluted, solution out there? > Pulling disparate systems under a common structure should be a way of > working here. But this only works if it can come =E2=80=9Cin common=E2=80= =9D and we aren=E2=80=99t > stretching the abstractions so much that they=E2=80=99re meaningless. > - Does it fit in the GNAP model along with other work? This might mean w= e > have to adjust the model, but such adjustments shouldn=E2=80=99t be at th= e expense > of all other use cases. Sometimes, things don=E2=80=99t fit, and that=E2= =80=99s ok. > > Cohesiveness of the GNAP solution will come from applying good engineerin= g > and questioning assumptions about our existing and proposed solutions. It= =E2=80=99s > important that we know the :why: of things and not just the :what:. The > last thing I think we want is a protocol that is actually a bunch of > completely different protocols with switched behavior. This is one of the > biggest complaints that I see about OAuth 2=E2=80=99s =E2=80=9Cframework= =E2=80=9D approach and I > think we have an opportunity to do much better here *if we get the model > right*. That=E2=80=99s going to take time and effort, but I believe it=E2= =80=99s > possible, and I look forward to building that with everyone here. > > Right now, our best focus is going to be use cases =E2=80=94 what do peop= le want > to :do: with GNAP =E2=80=94 and what those use cases say about our model = and > assumptions going in to the solution space. There are a number of valuabl= e > points in both Tom and Denis=E2=80=99s discussion below. Some of it fits,= some of > it doesn=E2=80=99t. Some of it might be better for an extension. Some of = it might > be counter to what we=E2=80=99re after. > > Discussing all of that is why we=E2=80=99re all in a standards working gr= oup and > not just building a commercial product. > > =E2=80=94 Justin > > On Jun 27, 2020, at 4:45 PM, Tom Jones > wrote: > > +1 - Right on Justin. > Peace ..tom > > > On Sat, Jun 27, 2020 at 1:15 PM Dick Hardt wrote: > >> +1 to 'We shouldn=E2=80=99t let =E2=80=9COAuth 2 doesn=E2=80=99t do it t= hat way=E2=80=9D be the limiting >> factor here.' >> >> Conversely, I worry about scope creep if we are forced to complicate the >> protocol to cover use cases that are only theoretical. (I'm not implying >> that any of the use cases discussed in this thread are in that category)= . >> >> /Dick >> >> On Sat, Jun 27, 2020 at 12:56 PM Justin Richer wrote: >> >>> Removing the IESG as this is really a more internal-to-the-group >>> discussion, as it comes down to the scope of use cases that we want to >>> address here in GNAP. >>> >>> While it is definitely important to understand how and why OAuth 2 does >>> things, we do need to keep use cases like Denis=E2=80=99s in mind. It= =E2=80=99s not unheard >>> of today for a single OAuth 2 RS to accept tokens from multiple AS=E2= =80=99s. In >>> fact, we=E2=80=99ve even got cases with things like the Solid project w= here the RS >>> will take a token from :any: AS so long as it can verify that it=E2=80= =99s approved >>> by the resource owner. While the Solid platform has its own special >>> layering in place to allow this, our model should not assume a closely-= tied >>> connection between an RS and any single AS. The question of :how: we so= lve >>> that is, of course, up to the WG to figure out over time. >>> >>> Taking that even further, I think the idea of an AS that=E2=80=99s pers= onal to >>> the user, to promote privacy and control, is a very good one. In fact, = this >>> is one of the main selling points of UMA2 and its federated authorizati= on >>> mechanisms. With GNAP, we might be able to deliver on this promise even >>> more than UMA has been able to, and it=E2=80=99s my hope that we can ha= ve a >>> cohesive protocol that allows both user-to-self and user-to-another >>> delegation sharing without needing to use different mechanisms. >>> >>> Additionally, the RS-first method is also something from the UMA2 work >>> that we should be working on, as it touches on AS discovery, AS/RS >>> communication, and a few other aspects of the protocol design. It=E2=80= =99s not a >>> trivial problem by any stretch, and there are huge privacy and security >>> implications, but there=E2=80=99s both need for it and some good prior = art to pull >>> from. In fact, XYZ=E2=80=99s whole notion of a =E2=80=9Ctransaction han= dle=E2=80=9D is an >>> adaptation of UMA2=E2=80=99s =E2=80=9Cpermission ticket=E2=80=9D. In UM= A, this ticket is first >>> issued to the RS by the AS, and the RS then hands it to the client, whi= ch >>> starts the negotiation for access. I envision something very similar >>> happening here with GNAP, where a client can get something to bootstrap= the >>> process at the AS. The important thing, to me, is that we don=E2=80=99t= have to >>> jump through a bunch of weird hoops such that the AS-first and RS-first >>> cases look completely different, as they do in UMA2 and OAuth 2 >>> respectively today. We=E2=80=99ve got the chance to have a clean and co= hesive >>> protocol here, let=E2=80=99s not miss that opportunity. >>> >>> So in sum, the trust model of OAuth 2 is not sufficient to cover >>> everything, and the model that Denis is proposing is something we shoul= d at >>> least look at as a use case. Where Denis and I seem to disagree is whet= her >>> this trust model should be the :only: one that we address with the >>> protocol. I strongly believe, as I believe much of this group does, tha= t we >>> can=E2=80=99t discount or ignore (or make things overly difficult for) = the tightly >>> bound AS/RS combos, or any type of static setup where the RS offloads i= ts >>> trust fully to the AS. But it=E2=80=99s my belief that we should be abl= e to do so >>> without needlessly throwing out all of the OAuth 2 use cases. >>> >>> We shouldn=E2=80=99t let =E2=80=9COAuth 2 doesn=E2=80=99t do it that wa= y=E2=80=9D be the limiting factor >>> here. We need to understand the what and wherefore of things that OAuth= 2 >>> is bad at, otherwise we=E2=80=99re just going to re-invent OAuth 2 and = inherit its >>> problems. >>> >>> =E2=80=94 Justin >>> >>> On Jun 26, 2020, at 1:39 PM, Dick Hardt wrote: >>> >>> Denis, thanks for sharing your thoughts, some clarifications on your >>> statements inserted: >>> >>> On Fri, Jun 26, 2020 at 9:42 AM Denis wrote: >>> >>> >>>> *New proposed charter* >>>> >>>> >>> >>>> >>>> Resource servers inform their clients about which access token formats >>>> are acceptable and depending upon the king of operation >>>> that is requested, which kind of attributes are needed and from which >>>> ASs that my be obtained. >>>> >>>> While at times this may be appropriate, at other times disclosing the >>> attributes the RS requires is not needed by the client. For example, an >>> enterprise client accessing a resource does not need to know which grou= ps a >>> user belongs to, but the RS may require that to determine if the user >>> running the client has access... >>> >>>> >>>> A major difference with OAuth 2.0 is that there is no bilateral trust >>>> relationship between an authorization server and a resource server: >>>> for a given category of attributes, a resource server may trust one or >>>> more authorization servers. Another major difference with OAuth 2.0. >>>> is that the content of an attributes token is meant to be accessible t= o >>>> the client. >>>> >>>> This is not how OAuth 2.0 works. See slides 7 and 8 from my original >>> IETF presentation on what became OAuth 2.0 >>> >>> https://www.slideshare.net/gueste648b/ietf-77-oauth-wrap-presentation >>> >>> The AS may not even know who the RS (or PR in the slides) is. >>> >>> >>> >>>> >>>> I got rid of the word "delegation": the client does not delegate >>>> anything to an authorization server. If it would, this would mean that= the >>>> authorization server >>>> would be able to act as the client and could know everything that the >>>> client will do, which comes into contradiction with the user's privacy= . >>>> >>> >>> The above is not true. >>> >>> The Resource Owner is delegating access control to the AS in >>> authorization use cases. >>> >>> The client is may be delegating user authentication to the AS in >>> identity claim use cases. >>> >>> The AS can act as the client in many OAuth deployments, as the access >>> token is a bearer token. That does not mean the AS knows what the clien= t is >>> doing. >>> >>> /Dick >>> >>> =E1=90=A7 >>> -- >>> 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 >> > > --00000000000047e7a305a92fe0cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In case it was not clear from my email, I was not dismissi= ng anybody's work as "theoretical".=C2=A0

On Sun, Jun 28, 2020= at 10:50 AM Justin Richer <jricher@m= it.edu> wrote:
I=E2=80=99m also worried ab= out feature creep, but it=E2=80=99s something that the group can guard agai= nst in very practical ways. It=E2=80=99s dangerous to dismiss someone else= =E2=80=99s work as =E2=80=9Conly theoretical=E2=80=9D, especially because G= NAP is going to draw from a different sent of circumstances that are going = to be outside the experience of the core OAuth community, and that=E2=80=99= s a really good thing.=C2=A0

But I believe that we can a= pply a set of sensible criteria to things:

=C2=A0-= Is there an implementation (even a proof of concept)? Running code makes b= ad assumptions come out in sharp relief, and we need to test these assumpti= ons constantly. But also keep in mind that running code can be changed.
=C2=A0- Is there an existing, perhaps more convoluted, solution out = there? Pulling disparate systems under a common structure should be a way o= f working here. But this only works if it can come =E2=80=9Cin common=E2=80= =9D and we aren=E2=80=99t stretching the abstractions so much that they=E2= =80=99re meaningless.
=C2=A0- Does it fit in the GNAP model along= with other work? This might mean we have to adjust the model, but such adj= ustments shouldn=E2=80=99t be at the expense of all other use cases. Someti= mes, things don=E2=80=99t fit, and that=E2=80=99s ok.

<= div>Cohesiveness of the GNAP solution will come from applying good engineer= ing and questioning assumptions about our existing and proposed solutions. = It=E2=80=99s important that we know the :why: of things and not just the :w= hat:. The last thing I think we want is a protocol that is actually a bunch= of completely different protocols with switched behavior. This is one of t= he biggest complaints that I see about OAuth 2=E2=80=99s =E2=80=9Cframework= =E2=80=9D approach and I think we have an opportunity to do much better her= e if we get the model right. That=E2=80=99s going to take time and e= ffort, but I believe it=E2=80=99s possible, and I look forward to building = that with everyone here.

Right now, our best focus= is going to be use cases =E2=80=94 what do people want to :do: with GNAP = =E2=80=94 and what those use cases say about our model and assumptions goin= g in to the solution space. There are a number of valuable points in both T= om and Denis=E2=80=99s discussion below. Some of it fits, some of it doesn= =E2=80=99t. Some of it might be better for an extension. Some of it might b= e counter to what we=E2=80=99re after.=C2=A0

Discu= ssing all of that is why we=E2=80=99re all in a standards working group and= not just building a commercial product.

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

On Jun 27, 2020, a= t 4:45 PM, Tom Jones <thomasclinganjones@gmail.com> wrote:

<= div dir=3D"ltr">+1 - Right on Justin.
Peace ..tom


On Sat, Jun = 27, 2020 at 1:15 PM Dick Hardt <dick.hardt@gmail.com> wrote:
+1 to 'We shouldn=E2=80=99t let =E2=80=9COAuth 2 doesn=E2=80=99t do i= t that way=E2=80=9D be the limiting factor here.'

Conversely, I worry about scope creep if we are forced to complicat= e the protocol to cover use cases that are only theoretical. (I'm not i= mplying that any of the use cases discussed in this thread are in that cate= gory).

/Dick

<= div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jun 27, 2020 at 12:56 PM Justi= n Richer <jricher@m= it.edu> wrote:
Removing the IESG as this is really a more internal-to-the-group= discussion, as it comes down to the scope of use cases that we want to add= ress here in GNAP.

While it is definitely important to u= nderstand how and why OAuth 2 does things, we do need to keep use cases lik= e Denis=E2=80=99s in mind. It=E2=80=99s not unheard of today for a single O= Auth 2 RS to accept tokens from multiple AS=E2=80=99s. In fact, we=E2=80=99= ve even got cases with things like the Solid project where the RS will take= a token from :any: AS so long as it can verify that it=E2=80=99s approved = by the resource owner. While the Solid platform has its own special layerin= g in place to allow this, our model should not assume a closely-tied connec= tion between an RS and any single AS. The question of :how: we solve that i= s, of course, up to the WG to figure out over time.

Taking that even further, I think the idea of an AS that=E2=80=99s person= al to the user, to promote privacy and control, is a very good one. In fact= , this is one of the main selling points of UMA2 and its federated authoriz= ation mechanisms. With GNAP, we might be able to deliver on this promise ev= en more than UMA has been able to, and it=E2=80=99s my hope that we can hav= e a cohesive protocol that allows both user-to-self and user-to-another del= egation sharing without needing to use different mechanisms.=C2=A0

Additionally, the RS-first method is also something from t= he UMA2 work that we should be working on, as it touches on AS discovery, A= S/RS communication, and a few other aspects of the protocol design. It=E2= =80=99s not a trivial problem by any stretch, and there are huge privacy an= d security implications, but there=E2=80=99s both need for it and some good= prior art to pull from. In fact, XYZ=E2=80=99s whole notion of a =E2=80=9C= transaction handle=E2=80=9D is an adaptation of UMA2=E2=80=99s =E2=80=9Cper= mission ticket=E2=80=9D. In UMA, this ticket is first issued to the RS by t= he AS, and the RS then hands it to the client, which starts the negotiation= for access. I envision something very similar happening here with GNAP, wh= ere a client can get something to bootstrap the process at the AS. The impo= rtant thing, to me, is that we don=E2=80=99t have to jump through a bunch o= f weird hoops such that the AS-first and RS-first cases look completely dif= ferent, as they do in UMA2 and OAuth 2 respectively today. We=E2=80=99ve go= t the chance to have a clean and cohesive protocol here, let=E2=80=99s not = miss that opportunity.

So in sum, the trust model = of OAuth 2 is not sufficient to cover everything, and the model that Denis = is proposing is something we should at least look at as a use case. Where D= enis and I seem to disagree is whether this trust model should be the :only= : one that we address with the protocol. I strongly believe, as I believe m= uch of this group does, that we can=E2=80=99t discount or ignore (or make t= hings overly difficult for) the tightly bound AS/RS combos, or any type of = static setup where the RS offloads its trust fully to the AS. But it=E2=80= =99s my belief that we should be able to do so without needlessly throwing = out all of the OAuth 2 use cases.

We shouldn=E2=80= =99t let =E2=80=9COAuth 2 doesn=E2=80=99t do it that way=E2=80=9D be the li= miting factor here. We need to understand the what and wherefore of things = that OAuth 2 is bad at, otherwise we=E2=80=99re just going to re-invent OAu= th 2 and inherit its problems.

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

On Jun 26, 2020, at 1= :39 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

Denis, thanks for sharing your thoughts, some clarifications= on your statements inserted:

On Fri, Jun 26, 2020 at 9:42 AM Denis <denis.ietf@free.fr= > wrote:
<snip>

New propo= sed charter

<snip>=C2=A0
=

Resource servers inform their clients about which access token formats are acceptable and depending upon the king of operation
that is requested, which kind of attributes are needed and from which ASs that my be obtained.
While at times th= is may be appropriate, at other times disclosing the attributes the RS requ= ires is not needed by the client. For example, an enterprise client accessi= ng a resource does not need to know which groups a user belongs to, but the= RS may require that to determine if the user running the client has access= ...

A major difference with OAuth 2.0 is that there is no bilateral trust relationship between an authorization server and a resource server:
for a given category of attributes, a resource server may trust one or more authorization servers. Another major difference with OAuth 2.0.
is that the content of an attributes token is meant to be accessible to the client.
This is not how OAuth 2.0 works. See slides 7 and 8 from= my original IETF presentation on what became OAuth 2.0


The AS may not even = know who the RS (or PR in the slides) is.

<snip= >=C2=A0


I got rid of the word "delegation": the client does n= ot delegate anything to an authorization server. If it would, this would mean that the authorization server
would be able to act as the client and could know everything that the client will do, which comes into contradiction with the user's privacy.


The=C2=A0above is not true.
=C2=A0
The Resource Owner is delegating access control to the AS in authori= zation use cases.

The client is may be delegating = user authentication to the AS in identity claim use cases.

The AS can act as the client in many OAuth deployments, as the acc= ess token is a bearer token. That does not mean the AS knows what the clien= t is doing.=C2=A0

/Dick
=C2=A0
3D==E1=90=A7
--
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

3D""=E1=90=A7