From nobody Wed Feb 9 12:27:53 2022 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 E84963A0A7D for ; Wed, 9 Feb 2022 12:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.896 X-Spam-Level: X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=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 aGZUFLtLoUqM for ; Wed, 9 Feb 2022 12:27:46 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15DE3A0BE3 for ; Wed, 9 Feb 2022 12:27:45 -0800 (PST) Received: from smtpclient.apple (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 219KRhLa023623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 9 Feb 2022 15:27:44 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_2973A845-C636-4FCC-BD8D-A2500453D19A" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Message-Id: <9B662493-2636-41B4-AF00-396D4E09A995@mit.edu> Date: Wed, 9 Feb 2022 15:27:43 -0500 To: GNAP Mailing List X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: Subject: [GNAP] Embedding GNAP X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2022 20:27:52 -0000 --Apple-Mail=_2973A845-C636-4FCC-BD8D-A2500453D19A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dmitri Z=E2=80=99s presentation at the interim has had me thinking about = how GNAP connects with other protocols, including other security and = identity systems. In particular, I think it brings to light two = different ways of looking at GNAP that have been in the system=E2=80=99s = design from the beginning but hasn=E2=80=99t gotten a lot of discussion. = I=E2=80=99m hoping we can start that discussion on this thread. While = it=E2=80=99s VC=E2=80=99s that spawned this discussion most recently, = there were also use cases early on about using GNAP for things like = mid-protocol step-up authentication and interaction. First I want to show the more =E2=80=9Ctraditional=E2=80=9D model that = allows for a full separation of the security and authorization layer = from the API. This should be of zero surprise to anyone who=E2=80=99s = worked with GNAP, OAuth, UMA, or any number of similar systems for many = years, but I=E2=80=99m including it as a baseline for discussion: = https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUgRW1iZWQgR05= BUCBpbiBQcm90b2NvbCAobmF0aXZlKQoKQ0ktPkZvbzogU3RhcnQgdGhlIEZvbwAhCQpGb28tP= kNJOiBXV1ctQXV0aDoASQUKb3B0AAMGQ0ktPkFTOiBncmFudCByZXF1ZXN0CkFTADAGcwBRBWl= udGVyYWN0ICJmb28iACQPY29udGludWUAKwlhY2Nlc3MgdG9rZW4vaWRlbnRpdHkvZXRjCmVuZ= CBvcHQAgSsKRm9vIHAAgU0Idy8ALgwKCg&s=3Ddefault = Second, we can embed a protocol inside of GNAP. GNAP=E2=80=99s = =E2=80=9Cinteraction=E2=80=9D mechanism is inherently more flexible much = of what=E2=80=99s come before, so it=E2=80=99s entirely possible, if = you=E2=80=99re already doing GNAP, to embed a whole new protocol in the = middle as part of the interact/continue-grant process, especially if = it=E2=80=99s dealing with identity and user information. We can even = include the =E2=80=9CFoo=E2=80=9D protocol information in our response = from the AS, and OpenID Connect showed us the power of this by including = the ID Token assertion alongside the access token of an OAuth response. = https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUgRW1iZWQgcHJ= vdG9jb2wgaW4gR05BUAoKQ0ktPkFTOiBncmFudCByZXF1ZXN0CkFTLT5DSTogc3RhcnQgaW50Z= XJhY3QgImZvbyIKb3B0IFRoZSBGb28gUABKBwpDSTwtPkZvbzogRG8gdAAPDyBpbiBDb250ZXh= 0CkZvbwBWBgBNCWZpbmlzaAplbmQgb3B0AIEDD2NvbnRpbnVlAIEKCWFjY2VzcyB0b2tlbi9pZ= GVudGl0eS9mb28vZXRjCg&s=3Ddefault = This is something I think that would be particularly valuable to use = VC-API in, since the context of the ongoing grant request adds = everything that the VC API would need to make its decisions. And = especially with VC-API, we can provide the ultimate VC generated as part = of the response from the AS in the last step, in the subject information = block. This is something I=E2=80=99ve proposed to the VC-API working = group to take up, but there hasn=E2=80=99t been interest there to date. = I do think it makes a lot of sense, though. Finally, and this is where Dmitri=E2=80=99s work is heading, is the idea = that you could embed a portion of GNAP inside of a completely separate = protocol. The result would be specific to whatever protocol you=E2=80=99re= using to wrap things, but it could look something like this: = https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUgRW1iZWQgR05= BUCBpbiBQcm90b2NvbCAob3B0aW1pemVkKQoKQ0ktPkZvby1BUzogRm9vABwKUmVxdWVzdAoAF= wYtPkNJOiBlbWJlZGRlZCBncmFudCByZXNwb25zZQpvcHQAYQZzbmlwcGV0AEkNACYGY29udGl= udWUKQ0k8AGgKaW50ZXJhY3QvABcIL2V0YwAiHGVuZCBvcACBCA5Gb28gcACBVQgAgQsJCg&s=3D= default = What I find interesting about this last model is the concept that the = =E2=80=9CFoo=E2=80=9D API responds with its own wrapped version of the = GNAP response, including information about accessing a GNAP Grant = Continuation Endpoint (including access token). The client can = communicate with whatever endpoints and protocols the Foo-AS needs, but = importantly they=E2=80=99re all wrapped up in otherwise standard GNAP = =E2=80=9Cinteraction=E2=80=9D hooks. And finally, at some point, the = client makes a =E2=80=9Cgrant continuation=E2=80=9D call but instead of = getting back a GNAP response, it gets back the Foo response it asked for = back in step 1. Now, this is weird for a lot of reasons, and it certainly is not GNAP, = not really anyway. So it=E2=80=99s not for this WG to decide what this = would look like for every protocol =E2=80=94 but my question to this = group is twofold: do we want to write guidance about how to do this kind = of embedding? Is the proposed VC-API work a good candidate for this kind = of thing with a concrete protocol? =E2=80=94 Justin= --Apple-Mail=_2973A845-C636-4FCC-BD8D-A2500453D19A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dmitri Z=E2=80=99s presentation at the interim has had me = thinking about how GNAP connects with other protocols, including other = security and identity systems. In particular, I think it brings to light = two different ways of looking at GNAP that have been in the system=E2=80=99= s design from the beginning but hasn=E2=80=99t gotten a lot of = discussion. I=E2=80=99m hoping we can start that discussion on this = thread. While it=E2=80=99s VC=E2=80=99s that spawned this discussion = most recently, there were also use cases early on about using GNAP for = things like mid-protocol step-up authentication and interaction.

First I = want to show the more =E2=80=9Ctraditional=E2=80=9D model that allows = for a full separation of the security and authorization layer from the = API. This should be of zero surprise to anyone who=E2=80=99s worked with = GNAP, OAuth, UMA, or any number of similar systems for many years, but = I=E2=80=99m including it as a baseline for discussion:

3D"https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUgRW1i=

https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUg= RW1iZWQgR05BUCBpbiBQcm90b2NvbCAobmF0aXZlKQoKQ0ktPkZvbzogU3RhcnQgdGhlIEZvbw= AhCQpGb28tPkNJOiBXV1ctQXV0aDoASQUKb3B0AAMGQ0ktPkFTOiBncmFudCByZXF1ZXN0CkFT= ADAGcwBRBWludGVyYWN0ICJmb28iACQPY29udGludWUAKwlhY2Nlc3MgdG9rZW4vaWRlbnRpdH= kvZXRjCmVuZCBvcHQAgSsKRm9vIHAAgU0Idy8ALgwKCg&s=3Ddefault

Second, we can = embed a protocol inside of GNAP. GNAP=E2=80=99s =E2=80=9Cinteraction=E2=80= =9D mechanism is inherently more flexible much of what=E2=80=99s come = before, so it=E2=80=99s entirely possible, if you=E2=80=99re already = doing GNAP, to embed a whole new protocol in the middle as part of the = interact/continue-grant process, especially if it=E2=80=99s dealing with = identity and user information.  We can even include the =E2=80=9CFoo=E2= =80=9D protocol information in our response from the AS, and OpenID = Connect showed us the power of this by including the ID Token assertion = alongside the access token of an OAuth response.

3D"https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUgRW1i=

https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUg= RW1iZWQgcHJvdG9jb2wgaW4gR05BUAoKQ0ktPkFTOiBncmFudCByZXF1ZXN0CkFTLT5DSTogc3= RhcnQgaW50ZXJhY3QgImZvbyIKb3B0IFRoZSBGb28gUABKBwpDSTwtPkZvbzogRG8gdAAPDyBp= biBDb250ZXh0CkZvbwBWBgBNCWZpbmlzaAplbmQgb3B0AIEDD2NvbnRpbnVlAIEKCWFjY2Vzcy= B0b2tlbi9pZGVudGl0eS9mb28vZXRjCg&s=3Ddefault

This is something I = think that would be particularly valuable to use VC-API in, since the = context of the ongoing grant request adds everything that the VC API = would need to make its decisions. And especially with VC-API, we can = provide the ultimate VC generated as part of the response from the AS in = the last step, in the subject information block. This is something = I=E2=80=99ve proposed to the VC-API working group to take up, but there = hasn=E2=80=99t been interest there to date. I do think it makes a lot of = sense, though.

Finally, and this is where Dmitri=E2=80=99s work is heading, = is the idea that you could embed a portion of GNAP inside of a = completely separate protocol. The result would be specific to whatever = protocol you=E2=80=99re using to wrap things, but it could look = something like this:

3D"https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUgRW1i=

https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUg= RW1iZWQgR05BUCBpbiBQcm90b2NvbCAob3B0aW1pemVkKQoKQ0ktPkZvby1BUzogRm9vABwKUm= VxdWVzdAoAFwYtPkNJOiBlbWJlZGRlZCBncmFudCByZXNwb25zZQpvcHQAYQZzbmlwcGV0AEkN= ACYGY29udGludWUKQ0k8AGgKaW50ZXJhY3QvABcIL2V0YwAiHGVuZCBvcACBCA5Gb28gcACBVQ= gAgQsJCg&s=3Ddefault

What I find interesting about this last = model is the concept that the =E2=80=9CFoo=E2=80=9D API responds with = its own wrapped version of the GNAP response, including information = about accessing a GNAP Grant Continuation Endpoint (including access = token). The client can communicate with whatever endpoints and protocols = the Foo-AS needs, but importantly they=E2=80=99re all wrapped up in = otherwise standard GNAP =E2=80=9Cinteraction=E2=80=9D hooks. And = finally, at some point, the client makes a =E2=80=9Cgrant = continuation=E2=80=9D call but instead of getting back a GNAP response, = it gets back the Foo response it asked for back in step 1.

Now, this is weird for a = lot of reasons, and it certainly is not GNAP, not really anyway. So = it=E2=80=99s not for this WG to decide what this would look like for = every protocol =E2=80=94 but my question to this group is twofold: do we = want to write guidance about how to do this kind of embedding? Is the = proposed VC-API work a good candidate for this kind of thing with a = concrete protocol?

 =E2=80=94 Justin
= --Apple-Mail=_2973A845-C636-4FCC-BD8D-A2500453D19A-- From nobody Thu Feb 10 03:09:41 2022 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 2E7D93A0818 for ; Thu, 10 Feb 2022 03:09:39 -0800 (PST) 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 8kEvqQsxXfoZ for ; Thu, 10 Feb 2022 03:09:34 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183D33A080A for ; Thu, 10 Feb 2022 03:09:34 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id d3so3992133ilr.10 for ; Thu, 10 Feb 2022 03:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9ip85iL1EPmbT6dPPV0x97f/85I/hoAKUbq9h95UK0g=; b=jUEwMHP8K6ztEtA1VFg5fUhQe846/7G4G7kqqEm7pD4bMKftJ14ko0LwrWUM/r+bWc CeMvSFqoPT8BGtBCTgIf4c6IHQkaw2l8S+pqiYITl0FO+9sQ483A6SPAbGrTWtCQW95K PDlHgvAlx0O53sxutMBK7n1qXQM3N+ylTvlyXwPJ4su4Ovf6Iyl8g21N4RNyEJtNzzXL HebBnFA8g4vUazdgdiPGXkjbF99wISaX6hY6J4KsQYYspibRXpP34WwX7Ows3Ni/lF7M 8yiQ6UX5NxZjeajLTNOTKg9ywcBsTCXALir2GSeg5GHglXNosRbRpKAgz+exsQPcBwLD pidg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9ip85iL1EPmbT6dPPV0x97f/85I/hoAKUbq9h95UK0g=; b=dM5ZPEVx0D7gOcm1cFfqOY7zEG8pABliMiv0ghtLeDTuAZB24qJGnrq8cy+b2+AHLm 2yz38QbIDNkR6pPIPfD2UYYBfGVM9HW4Vx/AEIlP84r0V+wmOisD9pLscAErKIw5myGV xrZWe57KiAidLeOuL/IZlozW/Tv4WnYgeMeuSIsT6fbVroJC4WXtcYGYKEAVDuaoaOTs 2Wm0f4C2RVb3ddF1Fa6Cx5O0qDqETl+wJZML02TAez2WMP6jr+t3Kc5Ew+ChntYlPi66 l0N2e9kzcghSykPGbCY+mX8xnUd42yhPbGeh82lOgDOYWqZk9glmQz58kUDtS9rItDbK WKMg== X-Gm-Message-State: AOAM532nBgIKXyHTea3NPda/FdIOQUoXdy693HrMmggy+O5sUYRNNUYb l6VGHZWCMjvtfHwWIsRyFQXGDNORsKBiF36KWLl5ErlY X-Google-Smtp-Source: ABdhPJxjVQm6RS1MYoOGypVV0S9G75CTF4cVX7irFQvtImz9J1NCgWHZRIYI1HcPYVxjVOuNu8PddCH0vHsqgI9FAyQ= X-Received: by 2002:a92:c52f:: with SMTP id m15mr2904752ili.160.1644491372117; Thu, 10 Feb 2022 03:09:32 -0800 (PST) MIME-Version: 1.0 References: <9B662493-2636-41B4-AF00-396D4E09A995@mit.edu> In-Reply-To: <9B662493-2636-41B4-AF00-396D4E09A995@mit.edu> From: Fabien Imbault Date: Thu, 10 Feb 2022 12:09:21 +0100 Message-ID: To: Justin Richer Cc: GNAP Mailing List Content-Type: multipart/alternative; boundary="00000000000012448605d7a7fcb3" Archived-At: Subject: Re: [GNAP] Embedding GNAP X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2022 11:09:39 -0000 --00000000000012448605d7a7fcb3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Justin, Thanks to you and Dmitri for bringing that up. That seems really interesting. Option 2 (embed protocol in GNAP) would really be beneficial. Option 3 (embed GNAP in protocol) is more ground breaking and illustrates the power of interactions in GNAP. I can think of a few use cases which would be very ad-hoc today (ex : update the credit card about to expire). I think it would be good to at least test what that would mean (entry point, output). Coding it on a specific use case (VC-API or something else) would likely provide valuable feedback. Cheers Fabien On Wed, Feb 9, 2022 at 9:28 PM Justin Richer wrote: > Dmitri Z=E2=80=99s presentation at the interim has had me thinking about = how GNAP > connects with other protocols, including other security and identity > systems. In particular, I think it brings to light two different ways of > looking at GNAP that have been in the system=E2=80=99s design from the be= ginning > but hasn=E2=80=99t gotten a lot of discussion. I=E2=80=99m hoping we can = start that > discussion on this thread. While it=E2=80=99s VC=E2=80=99s that spawned t= his discussion > most recently, there were also use cases early on about using GNAP for > things like mid-protocol step-up authentication and interaction. > > First I want to show the more =E2=80=9Ctraditional=E2=80=9D model that al= lows for a full > separation of the security and authorization layer from the API. This > should be of zero surprise to anyone who=E2=80=99s worked with GNAP, OAut= h, UMA, or > any number of similar systems for many years, but I=E2=80=99m including i= t as a > baseline for discussion: > > [image: > https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUgRW1iZWQgR0= 5BUCBpbiBQcm90b2NvbCAobmF0aXZlKQoKQ0ktPkZvbzogU3RhcnQgdGhlIEZvbwAhCQpGb28tP= kNJOiBXV1ctQXV0aDoASQUKb3B0AAMGQ0ktPkFTOiBncmFudCByZXF1ZXN0CkFTADAGcwBRBWlu= dGVyYWN0ICJmb28iACQPY29udGludWUAKwlhY2Nlc3MgdG9rZW4vaWRlbnRpdHkvZXRjCmVuZCB= vcHQAgSsKRm9vIHAAgU0Idy8ALgwKCg&s=3Ddefault] > > > https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUgRW1iZWQgR0= 5BUCBpbiBQcm90b2NvbCAobmF0aXZlKQoKQ0ktPkZvbzogU3RhcnQgdGhlIEZvbwAhCQpGb28tP= kNJOiBXV1ctQXV0aDoASQUKb3B0AAMGQ0ktPkFTOiBncmFudCByZXF1ZXN0CkFTADAGcwBRBWlu= dGVyYWN0ICJmb28iACQPY29udGludWUAKwlhY2Nlc3MgdG9rZW4vaWRlbnRpdHkvZXRjCmVuZCB= vcHQAgSsKRm9vIHAAgU0Idy8ALgwKCg&s=3Ddefault > > Second, we can embed a protocol inside of GNAP. GNAP=E2=80=99s =E2=80=9Ci= nteraction=E2=80=9D > mechanism is inherently more flexible much of what=E2=80=99s come before,= so it=E2=80=99s > entirely possible, if you=E2=80=99re already doing GNAP, to embed a whole= new > protocol in the middle as part of the interact/continue-grant process, > especially if it=E2=80=99s dealing with identity and user information. W= e can even > include the =E2=80=9CFoo=E2=80=9D protocol information in our response fr= om the AS, and > OpenID Connect showed us the power of this by including the ID Token > assertion alongside the access token of an OAuth response. > > [image: > https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUgRW1iZWQgcH= JvdG9jb2wgaW4gR05BUAoKQ0ktPkFTOiBncmFudCByZXF1ZXN0CkFTLT5DSTogc3RhcnQgaW50Z= XJhY3QgImZvbyIKb3B0IFRoZSBGb28gUABKBwpDSTwtPkZvbzogRG8gdAAPDyBpbiBDb250ZXh0= CkZvbwBWBgBNCWZpbmlzaAplbmQgb3B0AIEDD2NvbnRpbnVlAIEKCWFjY2VzcyB0b2tlbi9pZGV= udGl0eS9mb28vZXRjCg&s=3Ddefault] > > > https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUgRW1iZWQgcH= JvdG9jb2wgaW4gR05BUAoKQ0ktPkFTOiBncmFudCByZXF1ZXN0CkFTLT5DSTogc3RhcnQgaW50Z= XJhY3QgImZvbyIKb3B0IFRoZSBGb28gUABKBwpDSTwtPkZvbzogRG8gdAAPDyBpbiBDb250ZXh0= CkZvbwBWBgBNCWZpbmlzaAplbmQgb3B0AIEDD2NvbnRpbnVlAIEKCWFjY2VzcyB0b2tlbi9pZGV= udGl0eS9mb28vZXRjCg&s=3Ddefault > > This is something I think that would be particularly valuable to use > VC-API in, since the context of the ongoing grant request adds everything > that the VC API would need to make its decisions. And especially with > VC-API, we can provide the ultimate VC generated as part of the response > from the AS in the last step, in the subject information block. This is > something I=E2=80=99ve proposed to the VC-API working group to take up, b= ut there > hasn=E2=80=99t been interest there to date. I do think it makes a lot of = sense, > though. > > Finally, and this is where Dmitri=E2=80=99s work is heading, is the idea = that you > could embed a portion of GNAP inside of a completely separate protocol. T= he > result would be specific to whatever protocol you=E2=80=99re using to wra= p things, > but it could look something like this: > > [image: > https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUgRW1iZWQgR0= 5BUCBpbiBQcm90b2NvbCAob3B0aW1pemVkKQoKQ0ktPkZvby1BUzogRm9vABwKUmVxdWVzdAoAF= wYtPkNJOiBlbWJlZGRlZCBncmFudCByZXNwb25zZQpvcHQAYQZzbmlwcGV0AEkNACYGY29udGlu= dWUKQ0k8AGgKaW50ZXJhY3QvABcIL2V0YwAiHGVuZCBvcACBCA5Gb28gcACBVQgAgQsJCg&s=3D= default] > > > https://www.websequencediagrams.com/cgi-bin/cdraw?lz=3DdGl0bGUgRW1iZWQgR0= 5BUCBpbiBQcm90b2NvbCAob3B0aW1pemVkKQoKQ0ktPkZvby1BUzogRm9vABwKUmVxdWVzdAoAF= wYtPkNJOiBlbWJlZGRlZCBncmFudCByZXNwb25zZQpvcHQAYQZzbmlwcGV0AEkNACYGY29udGlu= dWUKQ0k8AGgKaW50ZXJhY3QvABcIL2V0YwAiHGVuZCBvcACBCA5Gb28gcACBVQgAgQsJCg&s=3D= default > > What I find interesting about this last model is the concept that the > =E2=80=9CFoo=E2=80=9D API responds with its own wrapped version of the GN= AP response, > including information about accessing a GNAP Grant Continuation Endpoint > (including access token). The client can communicate with whatever > endpoints and protocols the Foo-AS needs, but importantly they=E2=80=99re= all > wrapped up in otherwise standard GNAP =E2=80=9Cinteraction=E2=80=9D hooks= . And finally, at > some point, the client makes a =E2=80=9Cgrant continuation=E2=80=9D call = but instead of > getting back a GNAP response, it gets back the Foo response it asked for > back in step 1. > > Now, this is weird for a lot of reasons, and it certainly is not GNAP, no= t > really anyway. So it=E2=80=99s not for this WG to decide what this would = look like > for every protocol =E2=80=94 but my question to this group is twofold: do= we want > to write guidance about how to do this kind of embedding? Is the proposed > VC-API work a good candidate for this kind of thing with a concrete > protocol? > > =E2=80=94 Justin > -- > TXAuth mailing list > TXAuth@ietf.org > https://www.ietf.org/mailman/listinfo/txauth > --00000000000012448605d7a7fcb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,=C2=A0

Thanks to you and Dmit= ri for bringing that up. That seems really interesting.

Option 2 (embed protocol in GNAP) would really be beneficial.

Option 3 (embed GNAP in protocol) is more ground breaking= and illustrates the power of interactions in GNAP. I can think of a few us= e cases which would be very ad-hoc today (ex : update the credit card about= to expire).

I think it would be good to at least = test what that would mean (entry point, output). Coding it on a specific us= e case (VC-API or something else) would likely provide valuable feedback.= =C2=A0

Cheers
Fabien


On Wed, Feb 9, 2022 at 9:28 PM Justin Richer <jricher@mit.edu> wrote:
Dmitri Z= =E2=80=99s presentation at the interim has had me thinking about how GNAP c= onnects with other protocols, including other security and identity systems= . In particular, I think it brings to light two different ways of looking a= t GNAP that have been in the system=E2=80=99s design from the beginning but= hasn=E2=80=99t gotten a lot of discussion. I=E2=80=99m hoping we can start= that discussion on this thread. While it=E2=80=99s VC=E2=80=99s that spawn= ed this discussion most recently, there were also use cases early on about = using GNAP for things like mid-protocol step-up authentication and interact= ion.

First I want to show the more =E2=80=9Ctraditio= nal=E2=80=9D model that allows for a full separation of the security and au= thorization layer from the API. This should be of zero surprise to anyone w= ho=E2=80=99s worked with GNAP, OAuth, UMA, or any number of similar systems= for many years, but I=E2=80=99m including it as a baseline for discussion:=

3D"https://www.websequencediagrams.com/cgi-bin/cdraw?lz=


Second, we can embed a protocol inside of GNAP= . GNAP=E2=80=99s =E2=80=9Cinteraction=E2=80=9D mechanism is inherently more= flexible much of what=E2=80=99s come before, so it=E2=80=99s entirely poss= ible, if you=E2=80=99re already doing GNAP, to embed a whole new protocol i= n the middle as part of the interact/continue-grant process, especially if = it=E2=80=99s dealing with identity and user information.=C2=A0 We can even = include the =E2=80=9CFoo=E2=80=9D protocol information in our response from= the AS, and OpenID Connect showed us the power of this by including the ID= Token assertion alongside the access token of an OAuth response.

3D"https=


This is something I think that would be pa= rticularly valuable to use VC-API in, since the context of the ongoing gran= t request adds everything that the VC API would need to make its decisions.= And especially with VC-API, we can provide the ultimate VC generated as pa= rt of the response from the AS in the last step, in the subject information= block. This is something I=E2=80=99ve proposed to the VC-API working group= to take up, but there hasn=E2=80=99t been interest there to date. I do thi= nk it makes a lot of sense, though.

Finally, and t= his is where Dmitri=E2=80=99s work is heading, is the idea that you could e= mbed a portion of GNAP inside of a completely separate protocol. The result= would be specific to whatever protocol you=E2=80=99re using to wrap things= , but it could look something like this:

3D"https://www.websequencediagrams.com/cgi-bin/cdraw?lz=


What I find= interesting about this last model is the concept that the =E2=80=9CFoo=E2= =80=9D API responds with its own wrapped version of the GNAP response, incl= uding information about accessing a GNAP Grant Continuation Endpoint (inclu= ding access token). The client can communicate with whatever endpoints and = protocols the Foo-AS needs, but importantly they=E2=80=99re all wrapped up = in otherwise standard GNAP =E2=80=9Cinteraction=E2=80=9D hooks. And finally= , at some point, the client makes a =E2=80=9Cgrant continuation=E2=80=9D ca= ll but instead of getting back a GNAP response, it gets back the Foo respon= se it asked for back in step 1.

Now, this is weird= for a lot of reasons, and it certainly is not GNAP, not really anyway. So = it=E2=80=99s not for this WG to decide what this would look like for every = protocol =E2=80=94 but my question to this group is twofold: do we want to = write guidance about how to do this kind of embedding? Is the proposed VC-A= PI work a good candidate for this kind of thing with a concrete protocol?

=C2=A0=E2=80=94 Justin
--
TXAuth mailing list
TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txauth
--00000000000012448605d7a7fcb3-- From nobody Fri Feb 11 09:16:09 2022 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 B6C833A079F for ; Fri, 11 Feb 2022 09:16:06 -0800 (PST) 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 CWhqxqvECZ8L for ; Fri, 11 Feb 2022 09:16:04 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1B73A079E for ; Fri, 11 Feb 2022 09:16:03 -0800 (PST) Received: from smtpclient.apple (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 21BHG1xB006245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 11 Feb 2022 12:16:02 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_D0EB6C75-17F1-41AE-B5DE-C1ADFCCFCF40" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Message-Id: <9936CC61-65BA-4D4C-B190-99475DA4BE94@mit.edu> Date: Fri, 11 Feb 2022 12:16:01 -0500 To: GNAP Mailing List X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: Subject: [GNAP] GNAP Editors Update X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2022 17:16:07 -0000 --Apple-Mail=_D0EB6C75-17F1-41AE-B5DE-C1ADFCCFCF40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The editors met this week and are working on a number of issues ahead of = IETF113. The issue tracker will have all of the details, including = who=E2=80=99s been assigned to what topic. We=E2=80=99ve tried to add = comments on each of these issues to give an idea of which direction = we=E2=80=99re planning to go to resolve them.=20 There are several issues that have been marked =E2=80=9CPending Close=E2=80= =9D since it seems that either the issue has been resolved by other = work, or it=E2=80=99s no longer relevant due to changes in the spec = since the issue was filed. These will be closed without changes after 1 = week unless there=E2=80=99s significant push from the WG to do = otherwise. #49: AS Validation of RC-presented assertions https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/49 = #77: Dynamic RC instance registration https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/77 = #20: Interaction =E2=80=9CModes=E2=80=9D https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/20 = #43: User information request items https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/43 = #50: User identification items https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/50 = #72: Separation of AS into delegation and interaction https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/72 = Additionally, one additional issue been tagged as =E2=80=9CNeed Text=E2=80= =9D. These are items that need clearer direction and input from the = working group to warrant a change to the specification text before they = can affect anything. As is usually the case, many of these things seem = like they might be good ideas, but it=E2=80=99s not clear that there=E2=80= =99s a driving use case with enough detail to specify things at this = time. These will remain open for now but the editors are not focusing = any effort on addressing them at this time, and they may be marked = Pending Close in the future if nobody steps up. #44: Client attestation and posture https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44 = Finally, there are a number of pull requests that have been marked = =E2=80=9CPending Merge=E2=80=9D. These changes will be merged in one = week unless there=E2=80=99s significant push back or cause to do = otherwise. Please take a look as these are all concrete changes: #385: expand error codes https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/385 = #383: update manage URI section https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/383 = #382: one time use clarification https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/382 = #381: reference for safe URL https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/381 = Thank you everyone for your attention to all these items, please supply = your comments in GitHub on the issues and PRs themselves. =E2=80=94 Justin= --Apple-Mail=_D0EB6C75-17F1-41AE-B5DE-C1ADFCCFCF40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = editors met this week and are working on a number of issues ahead of = IETF113. The issue tracker will have all of the details, including = who=E2=80=99s been assigned to what topic. We=E2=80=99ve tried to add = comments on each of these issues to give an idea of which direction = we=E2=80=99re planning to go to resolve them. 

There are several issues that have been = marked =E2=80=9CPending Close=E2=80=9D since it seems that either the = issue has been resolved by other work, or it=E2=80=99s no longer = relevant due to changes in the spec since the issue was filed. These = will be closed without changes after 1 week unless there=E2=80=99s = significant push from the WG to do otherwise.

#49: AS Validation of RC-presented = assertions
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/49

#77: Dynamic RC instance registration
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/77

#20: = Interaction =E2=80=9CModes=E2=80=9D
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/20

#43: User = information request items
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/43

#50: User = identification items
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/50

#72: = Separation of AS into delegation and interaction
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/72


Additionally, one additional issue been = tagged as =E2=80=9CNeed Text=E2=80=9D. These are items that need clearer = direction and input from the working group to warrant a change to the = specification text before they can affect anything. As is usually the = case, many of these things seem like they might be good ideas, but = it=E2=80=99s not clear that there=E2=80=99s a driving use case with = enough detail to specify things at this time. These will remain open for = now but the editors are not focusing any effort on addressing them at = this time, and they may be marked Pending Close in the future if nobody = steps up.


#44: Client attestation and = posture
https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/44


Finally, there are a number of pull = requests that have been marked =E2=80=9CPending Merge=E2=80=9D. These = changes will be merged in one week unless there=E2=80=99s significant = push back or cause to do otherwise. Please take a look as these are all = concrete changes:

#385: expand error codes
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/385=

#383: update = manage URI section
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/383=

#382: one = time use clarification
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/382=

#381: = reference for safe URL
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/381=



Thank you everyone for your attention to all these items, = please supply your comments in GitHub on the issues and PRs = themselves.

 =E2=80=94 Justin
= --Apple-Mail=_D0EB6C75-17F1-41AE-B5DE-C1ADFCCFCF40-- From nobody Fri Feb 11 13:27:23 2022 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 971B93A0D2A; Fri, 11 Feb 2022 13:27:20 -0800 (PST) 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_PASS=-0.001, UNPARSEABLE_RELAY=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=danielfett.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 vl7SJ240MrUd; Fri, 11 Feb 2022 13:27:15 -0800 (PST) Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 542A43A0B90; Fri, 11 Feb 2022 13:27:14 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id C4589149CD; Fri, 11 Feb 2022 21:27:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1644614832; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=IfrEDCdPLQwhOup1LqgxBvXy7848vivFEKapOqrUnQE=; b=Ltqn0XxJLL0/ZribM28aLV1AAhLLIRZSPAWXnAvzsNt3RO/awG/TR1ciBsQTT4KqwwkEDU T7eN6lahA1tg7rdPLYwQkR6u3YwFkEIBIiDlc/NwKDul94KOBPIiOmbyVBqk5MSyUKw1Pj VsisEop0HCjTijH85OmYGyuty9kl3j8= Content-Type: multipart/alternative; boundary="------------mLSNDxRa810rIQFu927HLsOL" Message-ID: <65435b42-3246-a51f-8bfb-eb55374d09da@danielfett.de> Date: Fri, 11 Feb 2022 22:27:10 +0100 MIME-Version: 1.0 Content-Language: en-US To: openid-specs-ab@lists.openid.net, openid-specs-ekyc-ida@lists.openid.net, "oauth@ietf.org" , txauth@ietf.org, openid-specs-fapi@lists.openid.net From: Daniel Fett ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1644614832; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=IfrEDCdPLQwhOup1LqgxBvXy7848vivFEKapOqrUnQE=; b=Tp1kx48H3qd2u1yOkXmoYNQefywGrswJafrHgoDnCH0BQhJ31k9WS31ngnNVmOY31/wqDU WlFOG3jiiKcfQLqYmjn//3oPaQy1ImKhLen/DKKP+CzaozhB9so/RVLc4XDgI95oJl1kMx Srj8cognQsMFSiCBwhgC7PZS5cQWOlQ= ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1644614832; a=rsa-sha256; cv=none; b=HSWr47Usu41zI5z+vHp9yMzNCfGCD4Rt1eSF8gbSZcbZuNNLuqZ0dd+BKzjQyOEs3wkZZS P4lSc/BCy4vk92yosoZxzSk3jI9niJW39Gthx9SakUzaWkTOX41p+GrlGLwn5Ij9X4qEFI xsMj1dhLJPqSKceMhs6UXdiUgEHmW1E= ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de X-Spamd-Bar: / Archived-At: Subject: [GNAP] OAuth Security Workshop 2022 - Tickets now available X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2022 21:27:21 -0000 This is a multi-part message in MIME format. --------------mLSNDxRa810rIQFu927HLsOL Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi everyone, I'm pleased to announce that the website for the OAuth Security Workshop 2022 is now up: https://oauth.secworkshop.events/osw2022 The three-day event takes place in Trondheim, Norway, from May 4 to May 6, 2022. This workshop will *not* be a hybrid event. We might provide recordings or a live stream, but to ask questions and partake in discussions, on-site participation is required. Please visit the website for  * tickets - a limited amount of early bird tickets is available until no later than March 17  * the Call for Sessions  * venue and schedule information  * hotel deals  * travel information  * sponsoring opportunities If you have any questions, feel free to contact me! -Daniel --------------mLSNDxRa810rIQFu927HLsOL Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi everyone,

I'm pleased to announce that the website for the OAuth Security Workshop 2022 is now up: https://oauth.secworkshop.events/osw2022

The three-day event takes place in Trondheim, Norway, from May 4 to May 6, 2022.

This workshop will *not* be a hybrid event. We might provide recordings or a live stream, but to ask questions and partake in discussions, on-site participation is required.

Please visit the website for

 * tickets - a limited amount of early bird tickets is available until no later than March 17
 * the Call for Sessions
 * venue and schedule information
 * hotel deals
 * travel information
 * sponsoring opportunities

If you have any questions, feel free to contact me!

-Daniel

--------------mLSNDxRa810rIQFu927HLsOL-- From nobody Sat Feb 19 23:56:02 2022 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 E54973A0EA2 for ; Sat, 19 Feb 2022 23:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=mnot.net header.b=F08doune; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=messagingengine.com header.b=foUfx5Yu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWBbQtIJrUZt for ; Sat, 19 Feb 2022 23:55:55 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3923A0E8E for ; Sat, 19 Feb 2022 23:55:55 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 7E62A3200E86 for ; Sun, 20 Feb 2022 02:39:20 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 20 Feb 2022 02:39:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-type:date:from:from:in-reply-to:mime-version:reply-to :sender:subject:subject:to:to; s=fm2; bh=dx7ccoU0fb95M1SkCUeC6c1 cxkN2ObLijpatEJB4hx4=; b=F08dounemO+vaQ7zr8wJzMIxnyD2OCDr2/sHINc HUEkYgOnAjNwqhF3EymZ801Ptqc0BifBOX3O+j60zHEIKMS5It5Ec6e5H/Ta/1Ne SToCQC6zwh3LEJcKGHWkL+NOY1YGJyUo8xQ45zmydT4FcbHquFki/jJl7zvVQxGJ sZN+NmEGKwbi5w31A8xfNMS130cH8qwggFIeNCS8i5zUsOEsjuQVDut9/G3ATRZj pHspREp3MaDukK3JvTtDT/ysvgXPbEx41LW4cFLTD40et3EkmrtMy5EcR2RvitEM UEGOVbGcz+28ZotkBzuJzyqNWNz75McDZyepTEhAOI1nYRQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:from :in-reply-to:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=dx7ccoU0fb95M1SkCUeC6c1cxkN2ObLijpatEJB4hx4=; b=foUfx5Yu gYS967G3+xgR94Qs8c8BqeY6LrSKt8MjF7w8e/UfocGRZtPIn0tGNeSLtiy1BASZ 6QdrmC/Y+u7eNLvI65aw1CbLlMTSVCH7Elo3f/mIpQ0iVzLWdqXzBRkGmVu0ZM2T vmNAJOdrNmMWBW3aMvhl0qzaLQRyUOw2ikIbyZcLcdJxuKBo4NWL+X7OptiTETRn 9CHJoHvmP9bPaD9t84Z0su4q0ErLPExUWroLJ7kecKwzZxWjVTmX88tfBEI+x5hR /MU7NJowziyV2NqLvNoUkuJ5DdP7T0u2ul9IrV1jsyYJoav5uDPLAxTtFiuI/6Z1 ayhZLeKhmprcRg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrkeefgddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 20 Feb 2022 02:39:19 -0500 (EST) Content-Type: multipart/alternative; boundary="===============6596198781057656949==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20220220075555.5E3923A0E8E@ietfa.amsl.com> Date: Sat, 19 Feb 2022 23:55:55 -0800 (PST) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2022 07:56:00 -0000 --===============6596198781057656949== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/gnap-resource-servers (+1/-0/=F0=9F=92=AC4) 1 issues created: - RS Revoking access token (by jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/52=20 1 issues received 4 new comments: - #52 RS Revoking access token (4 by adeinega, jricher) https://github.com/ietf-wg-gnap/gnap-resource-servers/issues/52=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+5/-0/=F0=9F=92=AC17) 5 pull requests submitted: - Clarified user presence on interaction finish methods (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/390=20 - Redefine user code interaction methods (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/389=20 - Strengthened normative requirements for continue timeout (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/388=20 - Fix key proof parameter location (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/387=20 - Use "array of" (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/386=20 7 pull requests received 17 new comments: - #390 Clarified user presence on interaction finish methods (2 by netlif= y, pq2) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/390=20 - #389 Redefine user code interaction methods (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/389=20 - #388 Strengthened normative requirements for continue timeout (1 by net= lify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/388=20 - #387 Fix key proof parameter location (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/387 [Editorial]= =20 - #386 Use "array of" (2 by jricher, netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/386 [Editorial]= =20 - #383 update manage URI section (8 by adeinega, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/383 [Pending Me= rge]=20 - #379 assertions as array (2 by adeinega, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/379=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol * https://github.com/ietf-wg-gnap/gnap-resource-servers --===============6596198781057656949== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (GNAP Weekly GitHub Activity Summary)

Sunday February 20, 2022

Events without label "editorial"

Issues

ietf-wg-gnap/gnap-resource-servers (+1/-0/=F0=9F=92=AC4)

1 issues created:

1 issues received 4 new comments:

Pull requests

ietf-wg-gnap/core-protocol (+5/-0/=F0=9F=92=AC17)

5 pull requests submitted:

7 pull requests received 17 new comments:

Repositories tracked by this digest:
--===============6596198781057656949==-- From nobody Wed Feb 23 16:39:01 2022 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 0BC1F3A08B3 for ; Wed, 23 Feb 2022 16:38:59 -0800 (PST) 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 dLi5XGbNxgKu for ; Wed, 23 Feb 2022 16:38:55 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7043A08A8 for ; Wed, 23 Feb 2022 16:38:54 -0800 (PST) Received: from smtpclient.apple (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 21O0cq8M009823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 23 Feb 2022 19:38:53 -0500 From: Justin Richer Content-Type: multipart/alternative; boundary="Apple-Mail=_FBBE2624-E7AB-44DF-955F-8097254A7C97" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Message-Id: <6E248C6C-16EB-4934-A6FB-6408AB7F525B@mit.edu> Date: Wed, 23 Feb 2022 19:38:51 -0500 To: GNAP Mailing List X-Mailer: Apple Mail (2.3693.60.0.1.1) Archived-At: Subject: [GNAP] Editors Update X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 00:38:59 -0000 --Apple-Mail=_FBBE2624-E7AB-44DF-955F-8097254A7C97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ahead of the IETF113 meeting, the editors have been working hard at = putting together a set of targeted changes for a new revision. There are = currently 13 pull requests tagged for inclusion in one week. Please = review these and comment as you find things that need to be improved. = Some of these are relatively minor syntax changes, some are mostly = editorial, and some add or call out requirements where previously they = had been implied. We know there=E2=80=99s a lot to cover here, but = please take a look when you can. Harmonize URL/URI https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/377 = Assertions as array https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/379 = Data URI for logo https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/380 = Strengthened normative requirements for continue timeout https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/388 = Redefine user code interaction methods https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/389 = Clarified user presence on interaction finish methods https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/390 = Specify the content type for Discovery=E2=80=99s endpoint response = (thanks, Andrii!) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/398 = New 7.1.2 section on key protection https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/399 = Consistent formatting of parameter lists https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/400 = Cleanup issue 43 https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/401 = Rewording https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/402 = Rename overall diagram https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/403 = Plus one tagged editorial: Minor edits (thanks, Yaron!) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/394 = These will stay open for comment for one week from today. The editors = intend to create a new draft based on acceptance of all of these PRs, = ahead of the deadlines for IETF113. Thanks, and we hope to see you there! =E2=80=94 Justin, Aaron, and Fabien --Apple-Mail=_FBBE2624-E7AB-44DF-955F-8097254A7C97 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ahead= of the IETF113 meeting, the editors have been working hard at putting = together a set of targeted changes for a new revision. There are = currently 13 pull requests tagged for inclusion in one week. Please = review these and comment as you find things that need to be improved. = Some of these are relatively minor syntax changes, some are mostly = editorial, and some add or call out requirements where previously they = had been implied. We know there=E2=80=99s a lot to cover here, but = please take a look when you can.

Harmonize URL/URI
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/377=

Assertions as = array
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/379=

Data URI for = logo
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/380=

Strengthened = normative requirements for continue timeout
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/388=

Redefine user = code interaction methods
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/389=

Clarified = user presence on interaction finish methods
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/390=

Specify the = content type for Discovery=E2=80=99s endpoint response (thanks, = Andrii!)
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/398=

New 7.1.2 = section on key protection
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/399=

Consistent = formatting of parameter lists
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/400=

Cleanup issue = 43
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/401=

Rewording
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/402=

Rename = overall diagram
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/403=


Plus one tagged = editorial:

Minor edits (thanks, Yaron!)
https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/394=


These will stay open for comment for = one week from today. The editors intend to create a new draft based on = acceptance of all of these PRs, ahead of the deadlines for = IETF113.

Thanks,= and we hope to see you there!

 =E2=80=94 Justin, Aaron, and = Fabien


= --Apple-Mail=_FBBE2624-E7AB-44DF-955F-8097254A7C97-- From nobody Fri Feb 25 17:38:33 2022 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 A12BD3A12DE; Fri, 25 Feb 2022 17:29:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rdd@cert.org, txauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164583895664.24617.1523649374248909153@ietfa.amsl.com> Date: Fri, 25 Feb 2022 17:29:16 -0800 Archived-At: Subject: [GNAP] gnap - Requested session has been scheduled for IETF 113 X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2022 01:29:26 -0000 Dear Yaron Sheffer, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. gnap Session 1 (2:00 requested) Friday, 25 March 2022, Morning Session I 1000-1200 Room Name: Grand Park Hall 2 size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/113/sessions/gnap.ics Request Information: --------------------------------------------------------- Working Group Name: Grant Negotiation and Authorization Protocol Area Name: Security Area Session Requester: Yaron Sheffer Number of Sessions: 1 Length of Session(s): Number of Attendees: 100 Conflicts to Avoid: Can't meet: Thursday early afternoon, Thursday late afternoon, Friday morning, Friday early afternoon, Friday late afternoon People who must be present: Leif Johansson Roman Danyliw Yaron Sheffer Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Feb 26 10:34:04 2022 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 ABF253A0B38 for ; Sat, 26 Feb 2022 10:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.106 X-Spam-Level: X-Spam-Status: No, score=-7.106 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 3W9oeYqrxx7J for ; Sat, 26 Feb 2022 10:33:58 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 5E33C3A0B3C for ; Sat, 26 Feb 2022 10:32:31 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id v21so9228054wrv.5 for ; Sat, 26 Feb 2022 10:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=/s+AoahfEsTDATRH2vSrjuYNtAD9Ods3k6dDr3O+plA=; b=BXha4BrPWxDIriktHgrjYIIjeEAZJRfTmskHiImX1aNYpG5vo5jiD+79fI44DUoVo8 BjYcpIHjBxiZsen9/P/g1f5jgSf837yoI3GOBA4rE23oGuJlT30jwCnEmI9nL+nvgMRV GnrO6vc7piSZzDur0LU0ErJPDIp/b+Lxq9BqYvsS9BEhEME7uEDan2GWd1bimj0Df6dg vPEPAopCFOSoRfgJ8+OwRLnc3bMG1ngixSmVwV1vQpeTQA9hpzvC7Aj20FkL7p9Wfh8c SxKD1ykIqcR1E2W1lCdQHqkWgjtatTLWBhWCREIr2+i0XuIE4c5OEvBgK5Z9LL1HqBOT xlXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=/s+AoahfEsTDATRH2vSrjuYNtAD9Ods3k6dDr3O+plA=; b=NdUdSeib6K1kGs5evjEN3QsKZS+eViG0Qe/KBm9uehNtzptI4WWryB6M1wmzsaHAxA 4RPv6m8MyQTGxi7pvEiVxfXeXbdC3hASso364TmmgOUVdWis1Jc1iJ8gE5zgFudTkT7M Vj0cCOD2bQRlVm/IPGylWwzPPsFhXN9c8BRvej6DoSuzaqbGu3ZEKxNA0rWLm04jy/Jx j/kWUfQ4A32F2ue7vUIZHFXi04AnlP/Uxyprxzhv70WyihqNcgWOV6cm+o5EamoZbBhZ lvPg9kVZ4o5T7IoyvBOf/XVtmyTLQllkBaX5h0tLGgDuDW7SLhbnh9hZgJe1FUuT5f5J 3HfA== X-Gm-Message-State: AOAM5322B8l61P98xkEfGFiiCUjzpIZ76q32hPCmQYQTH9wJX06MlWtV GTBg5QFBdeXVw3NiBEfLeK8ofTzp56I= X-Google-Smtp-Source: ABdhPJyl9/cmxnHP6dN41MyvpQF23VPjeRwgMTLfLhOrF3w32AXHrYb1xIJGL+e1Vi4Z8AD5oEp8ZA== X-Received: by 2002:adf:ba4b:0:b0:1ed:9dff:4f5e with SMTP id t11-20020adfba4b000000b001ed9dff4f5emr10295091wrg.637.1645900349149; Sat, 26 Feb 2022 10:32:29 -0800 (PST) Received: from [192.168.68.108] (IGLD-84-229-146-220.inter.net.il. [84.229.146.220]) by smtp.gmail.com with ESMTPSA id k10-20020adfe3ca000000b001e3894ee3aasm5486495wrm.98.2022.02.26.10.32.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Feb 2022 10:32:28 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.58.22021501 Date: Sat, 26 Feb 2022 20:32:27 +0200 From: Yaron Sheffer To: Justin Richer , GNAP Mailing List Message-ID: <8B20DA28-3D6B-4567-9B33-379153791CAA@gmail.com> Thread-Topic: [GNAP] Editors Update References: <6E248C6C-16EB-4934-A6FB-6408AB7F525B@mit.edu> In-Reply-To: <6E248C6C-16EB-4934-A6FB-6408AB7F525B@mit.edu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3728752347_353659245" Archived-At: Subject: Re: [GNAP] Editors Update X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2022 18:34:03 -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_3728752347_353659245 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Thanks editors. =20 I would like to encourage the editorial team to stabilize the protocol by d= efining must-implement mechanisms where it makes sense.=20 =20 In my opinion, we should consider a single MTI for: =20 Key formats Key proof of possession (a.k.a.) message signatures. =20 But maybe also for: Start interaction modes Finish interaction modes =20 Eventually the market will decide. But at this stage of the protocol=E2=80=99s de= velopment, we should narrow the field somewhat to enable interoperability be= tween minimal Client and minimal AS implementations. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: TXAuth on behalf of Justin Richer Date: Thursday, February 24, 2022 at 02:39 To: GNAP Mailing List Subject: [GNAP] Editors Update =20 Ahead of the IETF113 meeting, the editors have been working hard at putting= together a set of targeted changes for a new revision. There are currently = 13 pull requests tagged for inclusion in one week. Please review these and c= omment as you find things that need to be improved. Some of these are relati= vely minor syntax changes, some are mostly editorial, and some add or call o= ut requirements where previously they had been implied. We know there=E2=80=99s a = lot to cover here, but please take a look when you can. =20 Harmonize URL/URI https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/377 =20 Assertions as array https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/379 =20 Data URI for logo https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/380 =20 Strengthened normative requirements for continue timeout https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/388 =20 Redefine user code interaction methods https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/389 =20 Clarified user presence on interaction finish methods https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/390 =20 Specify the content type for Discovery=E2=80=99s endpoint response (thanks, Andri= i!) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/398 =20 New 7.1.2 section on key protection https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/399 =20 Consistent formatting of parameter lists https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/400 =20 Cleanup issue 43 https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/401 =20 Rewording https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/402 =20 Rename overall diagram https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/403 =20 =20 Plus one tagged editorial: =20 Minor edits (thanks, Yaron!) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/394 =20 =20 These will stay open for comment for one week from today. The editors inten= d to create a new draft based on acceptance of all of these PRs, ahead of th= e deadlines for IETF113. =20 Thanks, and we hope to see you there! =20 =E2=80=94 Justin, Aaron, and Fabien =20 =20 -- TXAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinf= o/txauth=20 --B_3728752347_353659245 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Thanks editors.

 

I would like to encourage the = editorial team to stabilize the protocol by defining must-implement mechanis= ms where it makes sense.

 =

In my opinion, we should consider a single MTI for:

 

  • Key formats
  • Key proof of possession (a.k.a.) mess= age signatures.

 

=

But maybe also for:

  • Start interaction modes
  • Finish interaction modes<= o:p>

 

Eventually the market will decide. But at this stage of the protocol=E2=80=99s = development, we should narrow the field somewhat to enable interoperability = between minimal Client and minimal AS implementations.

 

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> o= n behalf of Justin Richer <jricher@mit.edu>
Date: Thursday, = February 24, 2022 at 02:39
To: GNAP Mailing List <txauth@ietf.o= rg>
Subject: [GNAP] Editors Update

<= div>

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'>Ahead of the IETF113 meeting, the= editors have been working hard at putting together a set of targeted change= s for a new revision. There are currently 13 pull requests tagged for inclus= ion in one week. Please review these and comment as you find things that nee= d to be improved. Some of these are relatively minor syntax changes, some ar= e mostly editorial, and some add or call out requirements where previously t= hey had been implied. We know there=E2=80=99s a lot to cover here, but please take= a look when you can.

 

Harmonize URL/URI

 =

Data URI for logo=

 

Strengthened normative requirem= ents for continue timeout

&= nbsp;

Redefi= ne user code interaction methods

 

Clarified user presence on interaction finish methods

<= div>

https://github.com/ietf-wg-gnap/gn= ap-core-protocol/pull/390

 

Specify the content type for Discovery=E2=80=99s endpoint r= esponse (thanks, Andrii!)

&= nbsp;

New 7.= 1.2 section on key protection

 

Co= nsistent formatting of parameter lists

 

Cleanup issue 43

&nb= sp;

Rewordin= g

 

Rename overall diagram

 

 

Plus one tagged editorial:

 

Minor edi= ts (thanks, Yaron!)

 <= /o:p>

&= nbsp;

These = will stay open for comment for one week from today. The editors intend to cr= eate a new draft based on acceptance of all of these PRs, ahead of the deadl= ines for IETF113.

 

Thanks, and we hope to see you there!

 

 =E2=80=94 Justin, Aaron, and Fabie= n

=  

=  

-- T= XAuth mailing list TXAuth@ietf.org https://www.ietf.org/mailman/listinfo/txa= uth

--B_3728752347_353659245-- From nobody Sat Feb 26 23:55:53 2022 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 973AA3A0BD1 for ; Sat, 26 Feb 2022 23:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=mnot.net header.b=qQO/jQgK; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=messagingengine.com header.b=ehB0nsIa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSobUEMfIqFi for ; Sat, 26 Feb 2022 23:55:46 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E891D3A0962 for ; Sat, 26 Feb 2022 23:55:45 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 074305C0121 for ; Sun, 27 Feb 2022 02:38:46 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 27 Feb 2022 02:38:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-type:date:from:from:in-reply-to:mime-version:reply-to :sender:subject:subject:to:to; s=fm2; bh=X5UZiMZqD+8Cluy7q5K0h7f clZIKvtj8BiEenlvhxBw=; b=qQO/jQgK3OpQ3+LndQtheK0MkDurRJemTgtbYxj Yz/YJU4gJp58872ceuUFZn+bdH3yFgnyNeubUOTlcoGLVdRN7QCxHY4AYGcAn64f CVTW9xcf2qpP4I8Pd99PgZlN+u5DsTtb2/Bz2GvDOUECEMwW9VIlO/RMpsmR32k9 FM+LlRSzN5pOyp89e+DcHzqIfgGHbO1An190Cagy7ftbI7Lw1sZxk+0t0JmRldvG Wr3W1qUO225TC2OHfKILb1UYKWnwXAlXI8T6EMrmr9ONXH1TjIMHtzexcPFuNhdJ ZclnhDQr8x8ctaEkT5/V5VIvPp3dS1o+Ywp3wcc8TJIAG4w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:from :in-reply-to:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=X5UZiMZqD+8Cluy7q5K0h7fclZIKvtj8BiEenlvhxBw=; b=ehB0nsIa 805Y2s7XEvMm/6g294mUmWWAF+XDPrdf79MEfDOZl0/PCnHHsdyGy4DkAqocWshr 7cy1WEfg+R/EssNEqjhboSDig948/lUAn0ME6BaPuZnqfwcxUzB3IbFUFpy1ThFD 2/l/i7nxA93O50aseyiOoQB8SIF5ioivUcWiQh4YxUEKPKHfikOUAN1KBrK/zgUH /oVSPdfWfqEJiAjvAM0V3pPVkOIyrpWhFibyt/TZX9Y2G0MtqmvLAjLYGEEfyU6q qhFm8MSrCzGVZewDOAjRbWBPt56jbaC4F2ZoMkqXcjLiTBg0F61q4RNV0CQRwUmX I6hlKQliiwsGgw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrleejgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 27 Feb 2022 02:38:45 -0500 (EST) Content-Type: multipart/alternative; boundary="===============5669292144485617814==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: txauth@ietf.org Message-Id: <20220227075545.E891D3A0962@ietfa.amsl.com> Date: Sat, 26 Feb 2022 23:55:45 -0800 (PST) Archived-At: Subject: [GNAP] Weekly github digest (GNAP Weekly GitHub Activity Summary) X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2022 07:55:51 -0000 --===============5669292144485617814== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * ietf-wg-gnap/core-protocol (+13/-8/=F0=9F=92=AC36) 13 issues created: - TLS at the "socket layer" (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/410=20 - RS-first discovery: security aspects (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/409=20 - grant_request_endpoint - URL matching? (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/408=20 - Access rights by reference (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/407=20 - Detached JWS: Created parameter (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/406=20 - Authorization header in attached/detached JWS (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/405=20 - delayed responses from the AS and the HTTP long polling mechanism (by a= deinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/404=20 - Multiple key formats (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/397=20 - Awkward wording around Client Instance Identifiers (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/396=20 - Redundant "extending" sections (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/395=20 - Class_id determined by the AS? (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/393=20 - Name the first sequence (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/392=20 - Terminology: "Grant" (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/391=20 17 issues received 36 new comments: - #410 TLS at the "socket layer" (3 by adeinega, jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/410=20 - #409 RS-first discovery: security aspects (3 by agropper, jricher, yaro= nf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/409=20 - #408 grant_request_endpoint - URL matching? (2 by jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/408=20 - #407 Access rights by reference (2 by jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/407=20 - #406 Detached JWS: Created parameter (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/406=20 - #405 Authorization header in attached/detached JWS (2 by jricher, yaron= f) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/405=20 - #397 Multiple key formats (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/397=20 - #396 Awkward wording around Client Instance Identifiers (2 by fimbault,= jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/396=20 - #395 Redundant "extending" sections (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/395=20 - #393 Class_id determined by the AS? (2 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/393=20 - #392 Name the first sequence (2 by fimbault, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/392=20 - #391 Terminology: "Grant" (5 by fimbault, jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/391=20 - #375 Allow a non-error response for a short redirect URL if other inter= action modes are specified (1 by aaronpk) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/375=20 - #216 Simplify access token hash (3 by jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/216=20 - #79 Error responses (1 by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/79=20 - #43 User information request items (4 by fimbault, jricher, yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/43 [Pending C= lose]=20 - #18 RC identified by Multiple Key Types (1 by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/18=20 8 issues closed: - Authorization header in attached/detached JWS https://github.com/ietf-w= g-gnap/gnap-core-protocol/issues/405=20 - Detached JWS: Created parameter https://github.com/ietf-wg-gnap/gnap-co= re-protocol/issues/406=20 - Allow a non-error response for a short redirect URL if other interactio= n modes are specified https://github.com/ietf-wg-gnap/gnap-core-protocol/is= sues/375=20 - Uniqueness of Token Management URIs https://github.com/ietf-wg-gnap/gna= p-core-protocol/issues/70=20 - Interaction requests as one-time-use https://github.com/ietf-wg-gnap/gn= ap-core-protocol/issues/97=20 - safe URL description https://github.com/ietf-wg-gnap/gnap-core-protocol= /issues/376=20 - Multiple key formats https://github.com/ietf-wg-gnap/gnap-core-protocol= /issues/397=20 - Redundant "extending" sections https://github.com/ietf-wg-gnap/gnap-cor= e-protocol/issues/395=20 Pull requests ------------- * ietf-wg-gnap/core-protocol (+7/-6/=F0=9F=92=AC14) 7 pull requests submitted: - Rename overall diagram (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/403=20 - rewording (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/402=20 - cleanup issue 43 (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/401=20 - Consistent formatting of parameter lists (by jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/400=20 - new 7.1.2 section on key protection (by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/399=20 - Specify the content type for Discovery's endpoint response (by adeinega) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/398=20 - Minor edits (by yaronf) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/394=20 12 pull requests received 14 new comments: - #403 Rename overall diagram (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/403 [Pending Me= rge]=20 - #402 rewording (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/402=20 - #401 cleanup issue 43 (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/401=20 - #400 Consistent formatting of parameter lists (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/400=20 - #399 new 7.1.2 section on key protection (2 by netlify, russhousley) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/399 [Pending Me= rge]=20 - #398 Specify the content type for Discovery's endpoint response (1 by n= etlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/398=20 - #394 Minor edits (1 by netlify) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/394=20 - #389 Redefine user code interaction methods (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/389=20 - #388 Strengthened normative requirements for continue timeout (2 by ade= inega, jricher) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/388 [Pending Me= rge]=20 - #380 data URI for logo (1 by russhousley) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/380 [Pending Me= rge]=20 - #379 assertions as array (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/379=20 - #378 provide more guidance on symmetric keys (1 by fimbault) https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/378=20 6 pull requests merged: - expand error codes https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/385 [Pending Me= rge]=20 - update manage URI section https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/383 [Pending Me= rge]=20 - one time use clarification https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/382 [Pending Me= rge]=20 - reference for safe URL https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/381 [Pending Me= rge]=20 - Fix key proof parameter location https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/387 [Editorial]= =20 - Use "array of" https://github.com/ietf-wg-gnap/gnap-core-protocol/pull/386 [Editorial]= =20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-wg-gnap/core-protocol * https://github.com/ietf-wg-gnap/gnap-resource-servers --===============5669292144485617814== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (GNAP Weekly GitHub Activity Summary)

Sunday February 27, 2022

Events without label "editorial"

Issues

ietf-wg-gnap/core-protocol (+13/-8/=F0=9F=92=AC36)

13 issues created:

17 issues received 36 new comments:

8 issues closed:

Pull requests

ietf-wg-gnap/core-protocol (+7/-6/=F0=9F=92=AC14)

7 pull requests submitted:

12 pull requests received 14 new comments:

6 pull requests merged:

Repositories tracked by this digest:
--===============5669292144485617814==-- From nobody Sun Feb 27 08:34:18 2022 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 59F5F3A129A; Sun, 27 Feb 2022 08:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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, T_SCC_BODY_TEXT_LINE=-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 apd94bgrCUn0; Sun, 27 Feb 2022 08:34:10 -0800 (PST) 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 75A693A1296; Sun, 27 Feb 2022 08:34:07 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id l1-20020a7bcf01000000b0037f881182a8so4486687wmg.2; Sun, 27 Feb 2022 08:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-transfer-encoding; bh=W+ldaJtfbhCxnMfu1POgfzyZVatT6VoEXCoOkkAmyA4=; b=iUt5queMjHGs1aiZp7eUVUIrpbz9nS3NnfF0Jh8k6do7OSAo28JZvEEWGetuBaUfF1 CxIk+MU41fe+NhzGY0oUMb22wceq07v1q1W6UhZQoIWg285b+Etdu1rl5IO6VwMGpahH vT80l+ji5/+yD6i3zyCLwxM0PeQCLlb35dOQ/+u6XmdLKTpMf1c+KBgy745lyF762m9o 33X30TA8MahJf6cUsBvMAARqbdc6JaznKWc9yXKMXbxp9ogRwj5080CA4aykJQuBqYfz v3LJh5Qi/pjXWt/L1q3XV/WKBNnSKaz+/EoyNHiTMHLihVyhKAnZwkp+SBQSwJ9IVezx 4Lvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-transfer-encoding; bh=W+ldaJtfbhCxnMfu1POgfzyZVatT6VoEXCoOkkAmyA4=; b=wDzxI1eeHfC/S1dR2DAXpvjk9jElQnWQG638mEXMENqhxmIo78hjK+CzrDO1ZuNjRO RC7elP3oHn50gYwe0fGChxhNWbAlnr6nnaLjLZfOHTVIIcaSQRZKqWE4iVeSZIRky5fb aY5SO2lCjuuIdydmP8/e5SxxgJ+ZfLOSuF9siW+0MuvxausOAt8iYMpQkr3zgTm8j/s6 1D2ox1rwnX6Zufq5udRejw54W0O0dlWG3JJ9M2V/ZvIorXv9z7vBkuxIpZ0ul8fQR4w+ 428llaJIOJCduU+I7QJ77b6suxzMtynkNDhhdiVoQ8eWgUbwi6ySQy/fpGT8YHOZYhGX 8D9A== X-Gm-Message-State: AOAM531depvdbkeFLLnqdD1SR/A0r3+7FsG9upqqGM5zt3Gkw+DaaQsA TTDd07R391kWaSl15ZF7qk9lohaxDSI= X-Google-Smtp-Source: ABdhPJzcXZnWhD8gOz57AF+a1ax2jnICp16vDMwRCjCCVJL65XlHIDOMRITST3n+lQI3D3Vx9XZSUg== X-Received: by 2002:a05:600c:3d13:b0:37b:b8e5:ed80 with SMTP id bh19-20020a05600c3d1300b0037bb8e5ed80mr10282752wmb.183.1645979645098; Sun, 27 Feb 2022 08:34:05 -0800 (PST) Received: from [192.168.68.108] (IGLD-84-229-146-220.inter.net.il. [84.229.146.220]) by smtp.gmail.com with ESMTPSA id c14-20020a7bc84e000000b0038100c9a593sm15705162wml.45.2022.02.27.08.34.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Feb 2022 08:34:04 -0800 (PST) User-Agent: Microsoft-MacOutlook/16.58.22021501 Date: Sun, 27 Feb 2022 18:34:03 +0200 From: Yaron Sheffer To: GNAP Mailing List CC: Message-ID: Thread-Topic: Subject Identifiers draft - request for volunteers Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: [GNAP] Subject Identifiers draft - request for volunteers X-BeenThere: txauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: GNAP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Feb 2022 16:34:16 -0000 Hi, The GNAP protocol has a dependency on the Subject Identifiers draft [1] fro= m the SecEvent working group. That draft has been around for a long time and= in fact has just been updated by the authors (much appreciated!), but we=E2=80=99= ve had a hard time moving it across the finish line at the SecEvent group. I= am looking for one or more volunteers to join as co-authors, preferably peo= ple who are *not* authors on the GNAP protocol. The Subject ID draft should go into an abbreviated second WG last call, and= then assuming everything goes well, into IETF last call and IESG review. Th= e main task of the new author(s) would be to address IESG comments in a time= ly manner and move the draft to publication. If you are new to the IETF, this is a great opportunity to familiarize your= self with its publication process. Please get back to me or Leif for any additional details. Thanks, Yaron [1] https://datatracker.ietf.org/doc/draft-ietf-secevent-subject-identifier= s/